Windows Networking & Remote Access

Determine if the Terminal Server console session is in use, from a command line

2008-06-12T11:58:00Z

A couple of times lately I have been asked how to determine form a command line, if the console session is currently in use on a Windows 2003 server. One option is as as follows:

From a connected TS/RDP session you can run set sessionname This will return “console” or “RDP-Tcp#X” where X is the session numberHowever it only shows “console” if the user is at the physical console, not if they have remotely connected to the console session using mstsc /console  A better option is to use the query command: query session This will return a list similar to:

SESSIONNAME   USERNAME    ID     STATE     TYPE          DEVICE
rdp-tcp#7 Bob     0 Active rdpwd
rdp-tcp     65536 Listen rdpwd
rdp-tcp#2 Sue     1 Active rdpwd
rdp-tcp#2 Tom    2 Active rdpwd
console     4 Conn wdcon

In this list, "Conn" indicates someone is remotely connected to the console session, and ID "0" is the user using the console session.If Bob were at the physical console it would look like the following: SESSIONNAME   USERNAME    ID     STATE     TYPE          DEVICEconsole       Bob     0 Active   wdcon
rdp-tcp     65536 Listen rdpwd
rdp-tcp#2 Sue     1 Active rdpwd
rdp-tcp#2 Tom    2 Active rdpwd Note: the query command only returns the console session information if run as an admin. Other session information is available to users.

Should you want to run the command on a remote server, you can use Sysinternal’s/Microsoft’s free PSexec command line utility. If logged in as a domain admin the basic syntax would be:PSexec \ServerName query session Detailed use and syntax of PSexec can be found:

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Remote support made easy

2008-05-11T12:02:00Z

There are dozens of utilities available that allow you to support remote clients including Remote Desktop, Remote Assistance, VNC, Dameware, GoToMyPC, LogMeIn, and WebEx, only to name a few. Some of these are free, some are expensive, some offer encryption, and some require router modifications at either the host or client site. I recently signed up for the new Citrix GoToAssist Express Beta Test which seems to offer all of the good features and more, of the aforementioned, and with none of the aggravations.

Though this service will not be free, it is well worth trying out, and consider adopting in the future. It is extremely easy to use by both the support technician and client, and offers secure access with good performance. It is ideally suited in my opinion for supporting non-enterprise clients for which you do not have preconfigured access to the remote site.

The session is started by selecting "start a support session" from a task bar icon. You are provided with a support session number and the option to automatically generate an e-mail to send to the client, or just read it to them over the phone. The client then connects to the www.fastsupport.com web site, enters their session ID, which then initiates running a tiny app (less than 200K). The client then has to approve your request to connect, and at any time they have the ability to end the session. I was impressed with how well all the features worked, and the performance.

Some of the features included, that I felt were important:

Client ability to control connections (clientvsecurity)
Very good performance
No router reconfiguration (port forwarding) at either site
It is a shared session, ideal for training purposes
Either the client or the support technicians sessions can be shared, and flipping back and forth between them is very easy
Drawing tools allow pointing out features and options to clients
Chat session available during the connection
Bi-directional file transfers
Diagnostic tools which can be run from the support screen to gather information about the client PC. This includes 10 pages of information such as hardware, software, and status information, which can also be saved to a local file for reviewing

A notes section to allow you to create notes to be saved with the session information
The ability to re-boot the PC remotely, not only to the same session, but also to reboot to safe mode and automatically re-connect the session while in safe mode - "very cool"
There is an option to configure the client machine to allow unattended support sessions, i.e connecting without the client preset. Installation of this feature, again requires approval by the client. Like Remote Desktop, these sessions lock the screen on the client PC. One nice feature is the client can refuse the connection, if they are in the middle of a project.

LMHosts and Hosts files

2008-05-11T01:01:00Z

There are two files in the %systemroot%\system32\drivers\etc directory that can be used for name resolution. The Hosts file, used for DNS name resolution, and the LMHosts.sam file used for NetBIOS name resolution. In an age where DNS dominates your network both locally and throughout the Internet, these two files are seldom ever used, but they can be very useful in a few situations. Both are simple text files that match names to IP addresses, and are very easy to create and implement. Most people are familiar with these files, but are often frustrated when they do not work as expected. This is usually due to the fact that they have some very simple, but specific requirements, for them to work at all.

LMHosts (NetBIOS names):

The primary use today for an LMHosts file, is for name resolution over a VPN. If DNS is configured on the host and client machines there should be no need of static text files for resolving names, but it does work well, and many folks uses them as a dependable simple solution. The catch is there are a few gotcha's you need to be aware of:

The LMHosts file in it's default form, is named lmhosts.sam The .sam represents sample. If you are planning on using this file it needs to be saved without a file extension - lmhosts. Be careful if using a text editor like NotePad as it will add a .txt file extension to the name. The safest method is to save the file using quotes, "lmhosts" to assure no extensions are added.
Text following a # in the LMHosts file is a comment and can be ignored or deleted.
A typical entry would look like:

192.168.100.101 COMPUTERNAME #PRE #my notes

When making a new entry you must hit enter at the end of the line, which adds a "carriage return"
Use the Tab key between items in each line rather than spaces (recommended but not necessary), but there must be a space.
Though it is not needed, adding the #PRE parameter or extension will load the entry into the local NetBIOS name cache when the computer boots. This allows for a slightly faster resolving of the name, before it has been added to the cache.
Most entries such as #PRE, #DOM, DOMAIN names and such are case sensitive. Always use uppercase to be safe.
It is a good idea to add the domain name as well. This requires two lines, and uses extremely critical formatting. A sample would be:

192.168.100.10 DCNAME #PRE #DOM:YOUR-DOMAIN
192.168.100.10 "YOUR-DOMAIN \0x1b" #PRE

There must be exactly 20 characters, including spaces, between the quotes in "YOUR-DOMAIN \0x1b", and the spaces need to be between the domain name and the \0x1b. The domain name used is the NetBIOS name, not the FQDN. If your domain name exceeds 15 characters, you must truncate it at the 15th character, it will still work.

If you find this last step tedious, the University Of Sait Louis has a little Java script that will create these two lines for you: http://bflinux.slu.edu/LSI/tools/lmhosts.html

Hosts (DNS names):

The Hosts file today seems to be more used for blocking unwanted web sites. This is done by simply entering the website address and substituting the IP address with the localhost IP address such as:

127.0.0.1 www.unwantedsite.com #advertising site

There are subscription services that will actually update your Hosts file, according to a schedule, with a list of known unwanted sites.

Another handy use of the Hosts file is to create abbreviations for your own use. For example quick access to a website like Google can be achieved adding an abbreviation like 'G", or your firewall with 'F", or I frequently uses it for accessing client sites with remote desktop using 3 letter acronyms such as ACL for Acme Corp Ltd. :

64.233.187.99 G #Google

192.168.100.254 F #my firewall

123.123.123.123 ACL #Acme Corp Ltd

Most of the rules that apply to the LMHosts file, apply to the Hosts file as well:

The Hosts file already has no file extension, so there is no need to change it like the LMHosts file. Just be careful when editing you don't accidentally add one such as .txt when using NotePad or a similar editor.
Text following a # in the Hosts file is a comment, and can be ignored or deleted
A typical entry would look like:

123.123.123.123 ftp.acme.com #company FTP site

When making a new entry you must hit enter at the end of the line, which adds a "carriage return"
Use the Tab key between items in each line rather than spaces (recommended but not necessary), but there must be a space.

Keep in mind when editing these files you can run into conflicts, or ineffective changes if you do not reboot or purge the local name caches. To clear the NetBIOS cache ( and PREload), at a command line enter (R is case sensitive):

nbtstat -R

To clear the DNS cache, at a command line enter:

ipconfig /flushdns

For the record, the Hosts file can also be used for IPv6 addressing. Vista for example includes the IPV6 localhost entry, by default:

::1 localhost

VPN client name resolution

2008-05-11T00:39:00Z

The most common problem reported with a VPN client is " I cannot browse the remote network". Most often if one thinks about the need to browse over a VPN connection, you quickly realize it is seldom necessary at all. You are using a VPN to access a known remote resource to which the location is well documented. It can easily be accessed using the IP address or computer name.

Within the confines of a LAN, NetBIOS name broadcasts are the primary method for registering and resolving of names, for browsing purposes. Because broadcast packets are not routable, they are not forwarded over the VPN, and thus browsing is not possible. With the exception of a few routers offering services to forward NetBIOS information over the VPN tunnel, the only possibility for browsing the remote network is using two WINS servers as outlined in option 3 below.

There are numerous ways to access a remote machine as listed below. All will work, however for the simplest and most reliable solution use the IP address. If you want to access a remote network using names, by choice, or because the resource is on a device with a dynamic IP, I would recommend you jump to the last option, and use DNS.

IP address
LMHOSTS files (HOST Files)
WINS (Windows Internet Name Service)
DNS (Domain Name Service)

1) Most often the resource is located on a server with a static IP and therefore it can easily be accessed using a combination of the machine IP and the share name, such as \\192.168.123.123\SharName This is very simple, reliable, and does not rely on other services or applications. Should you need to map a drive, that too can be easily done at a command line or in a script using Net Use Z: \\192.168.123.123\ShareName

2) Assuming again the remote device is using a static IP, dependable name resolution to allow access such as \\ServerName\ShareName can be done with the LMHosts file. Located in %systemroot%\syetem32\drivers\etc folder, the LMHosts file is a list stored on the local computer basically mapping NetBIOS (computer) names to IP addresses. Though this works extremely well, it requires maintaining an updated name/IP list. There is also the Hosts file which is similar, but it is intended for DNS Fully Qualified Domain Names, rather than NetBIOS names. The LMHosts file, is a simple text file, but it has very specific configuration rules. See the following Microsoft documents for details:

This blog site, follow article under "LMHosts and Hosts files"
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnfd_lmh_qxqq.mspx?mfr=true
http://support.microsoft.com/kb/q180094/

3) If you have A WINS server located at the RRAS server site, it can be used for dynamic NetBIOS name resolution (i.e. it does not rely on static IP's). In order to do so the VPN client needs two options configured.

The client must be assigned the WINS server IP address. This can be done manually on the client, or assigned through DHCP by the RRAS server. If using DHCP, the RRAS server will not supply the WINS address from the DHCP scope options. The WINS server IP must be assigned to the RRAS server's network adapter, and it will then be inherited by the VPN client when it connects.
On the VPN client's network adapter , under TCP/IP properties, advanced, WINS, you also need to enable NetBIOS over TCP/IP.

WINS is also your only option for browsing the remote network. In order for this to work, you will need replicating WINS servers configured at both ends of the VPN tunnel. Browsing is still not 100% reliable using the two WINS server option.

4) All Windows 2000 and 2003 active directory environments have DNS configured. Thus, for name resolution of devices with dynamic IP's, it is generally the best bet. Again there are two requirements for using DNS:

Like WINS, the client must be assigned the DNS server IP address. This can be done manually on the client, or assigned through DHCP by the RRAS server. Once again if using DHCP, the RRAS server will not supply the DNS address from the DHCP scope options. The DNS server IP must be assigned to the RRAS server's network adapter, and it will then be inherited by the VPN client when it connects.
On the VPN client's network adapter, under TCP/IP properties, advanced, DNS, you also need to add the domain DNS suffix, such as MyDomain.local in the "DNS suffix for this connection" box.

Hopefully at least one of these options will assist you with name resolution using your VPN client.

RRAS DHCP options

2008-05-09T19:34:00Z

I am frequently asked about assigning IP's to Windows VPN clients though RRAS (Routing and Remote Access Service). Most often this is done using DHCP, but there are several ways to handle DHCP within RRAS, and included are a couple of features that may seem a little unusual or unexpected.

The first option, just to get it out of the way as it is not often implemented, is to assign static IP's to the VPN client. This is done through the user's profile in Active Directory on the Dial-In page, under “Assign a Static IP”. Should this be grayed out, it is due to the domain functional level being "Windows 2000 mixed". Look into the repercussions of raising the DFL before doing so. For the record, it is not possible to use DHCP reservations to assign static IP's to VPN clients.

DHCP within RRAS is handled in numerous ways: through a DHCP relay agent, using RRAS itself with or without a static address pool, or within the NAT configuration.

To use the DHCP relay, the DHCP server must reside on a different device than the RRAS server. It can be a router or any other Windows server. Installing the DHCP relay option is very straightforward. Right click on "general" under IP routing in the RRAS console, choose new routing protocol, and DHCP relay agent. Once the relay agent is created, right click on it, choose new interface, generally choose the LAN server adapter, and the defaults. Optionally you can assign the IP of the DHCP server by right clicking on the DHCP relay agent again, choose properties, and add the DHCP server's IP.

RRAS itself can assign DHCP addresses. This is set under the IP tab found by right clicking on the server name and choosing properties. DHCP is selected by default. With this option enabled, RRAS will select an IP from within the local DHCP service scope's address pool. Alternatively you can select static address pool and define a range of addresses from which RRAS can draw an IP for the VPN client. If DHCP is not enabled on the server, RRAS will assign an APIPA address in the 169.254.0.0/16 subnet which will still allow client to connect to the server, but routing will need to be configured to reach the LAN.

A final option is to use the DHCP allocator within the RRAS NAT configuration, but this does not apply to VPN clients, so I will not elaborate at this time.

One of the "unexpected" features of RRAS and DHCP occurs when the RRAS service is configured and started. Assuming the DHCP server is available, it reserves blocks of 10 IP's for the VPN clients, with the first IP being assigned to the RRAS server itself. If enough VPN clients connect simultaneously to exceed the 10 reservations, another block of 10 IP's is added. It is often disconcerting to see 10 addresses assigned in the DHCP address lease list, when there are no current connections. The RRAS leases can be distinguished by the RAS label in the "Unique ID" column. Should your available DHCP leases be limited, you can reduce the default block size of reserved IP’s by editing or adding the following registry key: HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\ RemoteAccess\Parameters\IP Change the DWord: InitialAddressPoolSize from the default value of 10 to your desired limit.

Another thing to point out is RRAS will not assign VPN clients additional connection information such as DNS or WINS address addressing, from the DHCP scope options. In order for these to be automatically added to the VPN client's virtual adapter's properties, they must be added to the RRAS server's own network adapter's configuration. They are then inherited by the VPN client.