Disable the Windows Firewall on client computers in an SBS 2008 domain

There are 3 GPO’s that affect the firewall on client machines in an SBS 2008 domain.
Open the group policy management console on the SBS and edit each of the 3 following GPO’s, or the ones that match the types of client PC’s you have. They can be found under My Business | Computers | SBS Computers or under Group Policy Objects:
Windows SBS Client – Windows Vista Policy
Windows SBS Client – Windows XP Policy
Windows SBS Client

The item to edit is:
Computer Configuration | Policies | Administrative Templates | Network | Network Connections | Windows Firewall | Domain Profile | Protect All Network connections
By default this is set to enabled. Setting to disabled will turn it off, setting to not configured allows administrators to enable or disable the firewall on the PC.

Note this only affects computers while connected to your domain. If you want to affect them while outside of your domain (not recommended) you also need to edit:
Computer Configuration | Policies | Administrative Templates | Network | Network Connections | Windows Firewall | Standard Profile | Protect All Network connections

There is another GPO: Computer Configuration | Policies | Administrative Templates | Network | Network Connections | Prohibit use of Internet Connection Firewall on your DNS domain network”, which can override the above. The default is set to not configured, but if has been changed to enabled or disabled it will force enabling or disabling of the firewall and administrators have no control. This should be left as “not configured”

Remember it can take up to 90 minutes for the policy to be applied to the workstations. You can force this almost immediately by running at a command line, on the workstation:
gpupdate /force

Restrict Windows VPN Client Access by Source IP


A frequent question is how to limit access to a VPN/RRAS server to users connecting from a specific IP.

The following outlines using  RRAS  “Inbound Filters” on server 2003. Similar steps can be taken using Inbound filters with NPS on Server 2008 and newer.

Please note:

  • Using Inbound/Outbound Filters within RRAS should not be used in place of a proper firewall solution.
  • As soon as filter rules are enabled, all other traffic is blocked by default and filters need to be configured for each service both incoming and outgoing
  • You should have console access when editing RRAS features and filters as it is very easy to lock yourself out of remote access regardless of what service you are using, RDP, VPN, TeamViewer, LogMeIn, etc.
  • More granular control is possible with a proper perimeter VPN device/router


It is assumed the VPN has already been configured and working properly. As this stems from a previous specific question,  it addresses a single NIC RRAS configuration, however the same process is followed for 2 NIC RRAS servers. Should you need assistance with configuring the basic VPN within RRAS see:



To configure the Inbound and Outbound filters, open the RRAS console, expand the server name, expand “IP Routing”, click on “General”, in the right hand widow select the WAN/public network adapter, right click on it and choose properties.  Under the “General” tab click “Inbound  Filters”. The rules are very basic, there are only 3 required for the PPTP VPN; incoming PPTP and GRE and matching outgoing rules, or an ‘allow any’ outgoing rule. Keep in mind you need to create rules for any other service used such as DNS, HTTP, HTTPS, RDP, etc. Not doing so will result in failed services.




To create a new rule select “New” and complete the filter configurations as follows.

Starting with a default rule allowing all outgoing traffic so that specific rules do not need to be created for each service. The following allows all protocols ‘out’ from the local subnet By not checking the “Destination network” check box it will default to “Any” destination or remote address.





Next you will need incoming rules for PPTP and GRE. The purpose of this article is to allow access from only one public IP by VPN clients, therefore in the example  below we have allowed access only from The destination network is set to the entire local network segment but could be limited to a particular server if you so desire. The protocol is TCP, and under the source/remote port ‘0’ is entered which defaults to any, and the destination port is 1723.



GRE is protocol 47, not port 47 so the configuration is a little different than other services and does not require a port number.



Once you have created your rules you need to check the box “Drop all packets except those that meet the criteria bellow” as in the screenshot below:



These rules will only allow VPN access from the remote IP. In order for any client, internal or external, to use other services that require external access, or replies from external services, you will have to add rules for additional ports/services whether TCP, UDP, or both. Below is a chart showing the VPN access above and additional examples for HTTP , HTTPS, DNS (requires both TCP and sometimes UDP), and RDP connections. The “Source network” for these need to be set as “Any” to allow replies from any remote site.  Also carefully note the source and destination port configurations in the different example types.



Don’t for get to “Apply”/save your filters on exiting.


Assign a Windows VPN Client a Static IP

On occasion there is a need to assign a VPN client a static IP. In active directory under the Dial-in tab of a user’s profile there is an option to “Assign a Static IP Address”, but this only applies to true dial-in clients.





There is a way to achieve this using Remote Access Policies though it is a little crude.  Remote Access Policies cannot identify a VPN client by MAC address or even user name, therefore it is necessary to use groups. The “crude” part is if you have multiple VPN clients requiring a unique static IP, you need to create a separate group in active Directory for each user, a very inefficient option. The steps below assume RRAS has already been configured and enabled for VPN access.


Windows Server 2008:

  • Create a new group in Active Directory such as VPNuser1 and add your user to that group
  • Open the RRAS console, right click on Remote Access Logging & Policies and choose launch NPS

  • In the Network Policy Server console click on Network Policies, action, and new

  • Name the policy, select Remote Access Server (VPN-Dial up) in the drop down list, and then Next
  • Under conditions click Add, select User Groups, and Add
  • Click the  Add Groups ‘button’ and locate your group using the Object Type (Groups), Locations (your domain or workgroup server), Advanced, and Find Now ‘buttons’  [On occasion you may get an error about not finding the server. Just ignore and continue so long as it adds the group]

  • In the  Specify Access Permissions window select Access granted and Next

  • Accept all defaults in the following  two windows; Configure Authentication Methods,  Configure Constraints
  • Under Configure Settings choose  IP Settings, then Assign a static IPv4 address, and insert your chosen static IP. This must of course be part of your LAN subnet.

  • Under the Completing New Network Policy click Finish



Windows Server 2003:

  • Create a new group in Active Directory such as VPNuser1 and add your user to that group
  • In the RRAS console, right click on Remote Access Policies and choose New Remote Access Policy

  • Name the policy, and in the next window under Access Method select VPN

  • Under User or Group Access select Group, then click Add, and locate your group using the Object Type (Groups), Locations (your domain or workgroup server), Advanced, and Find Now ‘buttons’
  • Leave all defaults in the remaining windows and save.
  • Right click on the new policy and choose Properties.
  • Click the Edit Profile ‘button’
  • Under the IP tab select Assign a static IP address and enter the address and then exit selecting the OK/Apply buttons as you close the various windows.



Microsoft announces "Windows Server 2008 Foundation"


Microsoft unveiled an interesting new product this week called “Windows Server 2008 Foundation”. This is an entry level server which will only be sold by equipment manufactures such as HP and Dell, as a pre-packaged  hardware and software solution. Though it has several limitations, it should prove to be an ideal product for small businesses with less than 15 users.


The server is basically Server 2008 with a few limitations as listed below. It can function as a stand alone Domain Controller, or join an existing server as a member server or Active Directory Integrated Domain Controller. It can also allow remote access through RRAS/VPN as well as function as a Terminal Server, but will require TS CAL’s if doing so.


The server will likely prove to be a very affordable solution to small businesses requiring a single server for file and print services, access to a Line Of Business application such as QuickBooks, and possibly Terminal Services. It will also be useful to businesses with an existing domain that wish to add a terminal server or remote office domain controller with file and print services, keeping in mind the licensing limit of 15 users applies to the entire domain.



  • 15 users
  • 1 physical process (multiple cores are acceptable)
  • 8GB of RAM
  • 64 bit only
  • No virtualization (O/S must be installed on physical hardware and Hyper-V role has been removed)
  • Limited to 7 languages so far
  • Software is not available for purchase independently, it must be purchased from an OEM pre-installed on the hardware



Microsoft Overview:


Microsoft press release:




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

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:

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: 


console                 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:


Remote support made easy

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

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:      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:   DCNAME   #PRE   #DOM:YOUR-DOMAIN   “YOUR-DOMAIN    x1b”   #PRE

There must be exactly 20 characters, including spaces, between the quotes in “YOUR-DOMAIN    x1b”, and the spaces need to be between the domain name and the x1b. 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:       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. :         G         #Google      F         #my firewall      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:      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

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.


  1. IP address

  2. LMHOSTS files  (HOST Files)

  3. WINS (Windows Internet Name Service)

  4. 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 \\\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: \\\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:


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


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 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.