Microsoft Core Infrastructure Technologies

Why WINS will be here for some time (or not)

by Robsilver on July 22, 2010

I was delighted in 2000 when I attended an MCSE upgrade course from NT4 – 2000. “And the best news is, you won’t need to use WINS in your new environment!”

Microsoft made a resolution to do away with NetBIOS Name Resolution and to move to dramatically more scalable naming using DNS.

It’s now 2010 [as of the writing of this article] and I am still thrilled with enthusiastic expectations of this prospect while simultaneously pleased I didn’t hold my breath. In this article, I will give you all the reasons you should continue using WINS. I will end with a resolution to easily get rid of it forever.

Firstly, the acronym WINS stands for Windows Internet Name Space. Here’s a clue – the Internet does NOT use this namespace. It uses hierarchical DNS FQDNs (Fully Qualified Domain Names [aka host names]) such as http://blog.robsilver.org. WINS resolves NetBIOS Names to IP Addresses (like a phone book is used to find the telephone number of the nearest trustworthy second hand car dealer).

NetBIOS (Network Basic Input/Output System) Names are single names without context (like Server as opposed to Server.ABCInc.com). NetBIOS is an API (Application Programming Interface) and not a protocol in and of itself and generally runs over TCP/IP (NetBIOS over TCP/IP [NBT]) at the session layer. It has been run over different protocols historically such as IBM’s NetBEUI (NetBIOS Extended User Interface – [an often misunderstood protocol and confused with NetBIOS itself amongst networking professionals today] later adopted by Microsoft), Microsoft’s MS-Net and Novel’s NetBIOS over IPX/SPX (NBX).

I am often asked, “Why do we need WINS today?” Well, you only need WINS if one of the following is true:

Multiple Subnets – Broadcast NetBIOS name resolution won’t work here. In a single subnet, broadcast NetBIOS Name resolution will work [caveat – most admins will tell you to reduce broadcasts – once again, you will need WINS]. Unless you feel like using LMHosts files on each computer on the network.
Exchange 2000/2003 (if you can do without the following features) (http://support.microsoft.com/kb/837391)
- Setup
- ExMerge
- Password reset through OWA
- Mixed 2000/2003 environment
Outlook earlier than 2003
Network Browsing using Network Neighbourhood
Use of the Browser Service
NetBIOS over TCP/IP enabled on any NICs
NetBIOS names referenced anywhere such as \\Server1\Share instead of \\Servers.domain.local\share. This includes
- Logon Scripts
- Applications
- Mapped Network Drives
Et al

DNS Suffixes

One feature which aides in the removal of the dependency of WINS is DNS Suffixes. For example, when looking for \\server1, your PC will add a suffix/(or ordered list of suffixes) to the single-label name and query through the list of suffixes against a DNS server (e.g. Server1.mydomain.com). GPO can be used for the deployment of the list of suffixes used on clients.

However, there is no guarantee that the single-label name is unique to each zone which may result is you accessing the wrong \\server1. Also, the DNS queries through the list of suffixes will timeout after 12 seconds. Therefore, the use of DNS Suffixes in large, multi-zone environments is limited.

Validating the current use of WINS

If you have a WINS Server and are considering removing it (based on passing all of the above checks), first do a quick reality check to verify the current utilization of NetBIOS Name Resolution on your network. Shutting the server down and then waiting for problems is not the best approach in this case. As an alternative, I recommend the following steps:

Enable WINS performance monitor counters to note the frequency of NetBIOS Name Queries taking place.
Get your hands on Wireshark and install it on the WINS server to capture the traffic destined to port 137. Alternately, have the network team mirror the port to the server so that you can run the network capture on any other PC like your laptop. You will see the exact names which are trying to be resolved and this may give some indication of which applications/scripts/users still require NetBIOS Name Resolution.
Additionally, while still using Wireshark on any computer on the subnet, have a look at the number of NetBIOS Name Resolution broadcasts. If you aren’t using WINS, there will likely be 100’s or 1,000’s per minute depending on how many machines you have on the network (an indication that you should be using WINS).

Realistic Scenarios for the Consideration of WINS (Current)

In my humble opinion, there are 2 potential scenarios when considering the deployment of WINS:

1. Deploy it, because you need it (3 days).

2. Assess whether or not you need it before deploying WINS (15 days). This includes:

Applications
Scripts
Wireshark
Research
Interviews
Meetings
Debates on the validity of WINS such as your networking team telling you that they don’t use NetBIOS/NetBEUI/NBT(NetBT)/NBF/MS-Net/LanMan etc. Remember, these are all networking protocols not dissimilar to TCP/IP; being the most widely used and fully supportive of the NetBIOS API (with the exception of Microsoft’s implementation of the TCP/IP v6 stack).
Compile all of the results and make a decision (99/100 the result will be you need it)
Inevitably, revert to step 1

3. Implement a GlobalNames Zone

I favour never to go beyond Scenario 1 given the cyclical nature of Scenario 2. Once WINS is setup appropriately and replicating with at least one additional replication partner, it very seldom fails and necessitates minimal deployment or operational time.

NEW – GlobalNames Zone (GNZ)

This matter wouldn’t be complete without a momentary look at a new feature – GlobalNames Zones (GNZ). This is used in large organizations who do not implement WINS or DNS Suffix’s for name resolution of single-label names and is available in Windows Server 2008/2008 R2.

If you still really want to get rid of WINS, GNZ could work for you. However, it isn’t dynamic in registration as WINS is and requires high administrative overhead if you have changing IP Addresses. It’s typical use is for well known, single-label named servers such as commonly accessed portals (e.g. http://helpdesk).

GNZ is great is you are planning on either retiring WINS or implementing IPv6 while still providing name resolution to single-label names.

The setup of GNZ is fairly straight forward:

1. Enable GNZ support on your DNS Servers

2. Create a zone called GlobalNames as either a primary, secondary (if you already have a centralised primary) or Active Directory Integrated

3. Create your records

This negates most of this post on the requirement for WINS and I am glad you took the time to read all the way here.

Summary

One day, this post will be obsolete. But for now, WINS is alive and well and a necessary evil on most networks who haven’t yet implemented GNZs.

{ 1 comment }

Designing High Availability DHCP Services in a Routed Environment

by Robsilver on July 22, 2010

Nobody wants to be burdened with the task of manually entering IP Addresses on each device in an organization (although I have seen this at quite a few SME customers). This is an inefficient use of technical resource time where the technician would be better off updating his facebook profile for the same benefit to the end user.

Dynamic Host Configuration Protocol is a bit of a misnomer today as the term is a mile wide. The etymology of the first word in the acronym is French dynamique, from Greek dynamikos “powerful”, from dynamis “power”, from dynasthai “to be able”. “Can it powerfully configure my host to…?”. I would suggest a rename of the term to something like Automatically Get The Right IP (Silver-TRIP) but that doesn’t ring well. Any suggestions welcome here.

“People Ready” is a concept Microsoft coined a few years back with the launch of the Infrastructure Optimization model exactly 20 years to the day after Microsoft became a listed company (http://www.microsoft.com/presspass/press/2006/mar06/03-16PeopleReadyPR.mspx). The idea behind this term is; arrive at work, plug in your laptop and start working immediately with all of the resources you require in order to be as efficient and productive as possible (coffee in the pot etc). High Availability of the DHCP Service is critical to achieving this goal in order to prevent unnecessary downtime and lost user productivity. Once DHCP has been designed and implemented within your constraints in accordance to the requirements of the organization, you should rarely have to visit DHCP again. It should just work [insert standard disclaimer here].

The technology used for the Powerful issuing of IP Addresses can be based on the Microsoft DHCP Service, 3^rd party DHCP software or Networking Hardware such as Cisco. I prefer the Microsoft implementation with the ability to integrate into your existing Microsoft Core Infrastructure through features such as having the DHCP Server powerfully update the DNS Servers with your new IP Address and PTR record.

Design Considerations

Design considerations you should consider for your environment include the following:

Network Design and IP Addressing in use

Most organizations use RFC 1918 private addressing, and unless you own an internet range of addresses, use these addresses. In fact, even if you do own a sufficient range of Public Addresses, it may be a significant security risk assigning your clients with a public IP Address directly routable from the Internet. Through the use of RFC 1918 addresses, you can Masquerade the internal devices from the internet with a NAT device on your perimeter firewall/router. These RFC 1918 addresses include 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. You can go wild and subnet these addresses as you see fit at no cost.

Number of hosts on each Layer 2 broadcast domain/VLAN (i.e. layer 3 subnet)

If you have 254 hosts on your Layer 2 broadcast domain, what subnet mask should you use? The obvious answer is /24 (255.255.255.0). You would be correct if you didn’t have any care for DHCP High Availability options, specifically the use of Split Scopes which we will look at later. /23 is MORE correct when using Split Scopes because you will need more addresses than devices with this HA Strategy.

Sites, Links and Subnets

Do you want a DHCP server at each site or on each subnet? This isn’t very efficient and the more DHCP servers you have, the more of a headache it becomes to manage. However, if you have frequent WAN outages, you may run into situations where clients cannot obtain an IP Address.

Options

Once you have all of this information, here are the design options available to you for High Availability of DHCP on a Routed Network:

High Availability

High Availability (HA) refers to the Reliability, Availability and Serviceability, or “Fault Tolerance/Resilience” of a solution or service. A good IT Admin isn’t permanently running around fighting fires. Implementation of technology specific HA solutions ensure automated/semi-automated solutions in the event of failure. The following broad options exist for this for DHCP:

Standby Servers – You could pre-create standby servers using the same scope of addresses and manually enable these scopes when there is an issue. WARNING: You need to ensure that you configure the DHCP servers to detect IP conflicts or you will have chaos the minute you need to enable these scopes.
DHCP Cluster – With Server [2003/2008/2008 R2] Enterprise and shared storage (SAN) you can cluster the DHCP service and use a single pool of IP Addresses. This is very convenient but is ineffective for risks such as WAN Failures or DHCP shared database corruption.
Split Scopes – You could have 2 DHCP Servers with a 50/50 – 80/20 share of the available IP Addresses. This is a very good solution where you have multiple Data Centres and need Data Centre redundancy for DHCP. Make sure you have enough spare IP Addresses to support this option.

Routed Networks

Considerations for routed networks need to be considered. When a Client initially requests an IP Address from a DHCP Server, it sends out a UDP Broadcast on port 67 to the broadcast domain (VLAN, layer 2 network). Routers are designed to ensure that broadcasts remain within the broadcast domains they connect, operating at layer 3. By default, a client on one broadcast domain will not be able to send a broadcast which spans beyond a router. This is a good thing in general as it significantly reduces network traffic and prevents broadcast loops.

However, this is limiting to DHCP and requires a DHCP Server on every broadcast domain in order to service the DHCP clients. Here are the options to overcome this restriction:

1 DHCP server per VLAN – Don’t do it!!
Software DHCP Relay Agents per VLAN – Don’t do it!!
Multihomed DHCP Servers – Don’t do it!!
Enable IP Helper Addresses on the RFC 1542 compliant Routers to forward broadcasts for UDP Port 67 to the IP Address of the DHCP Server which has all of the necessary Scopes.

{ 0 comments }

Transact SQL Basics – Basic Select Statement

by Robsilver 19 July 2010 Active Directory

SELECT *
FROM Users WHERE Clue > 0
—————

0 records returned

[want the rest...?]

Demystifying Time in a Forest

by Robsilver 23 April 2010 Active Directory

Here’s a quick to do list to get your forest’s time in sync with an external trusted time source.

[want the rest...?]

How to Increase Traffic to your Blog For Free

by Robsilver 17 April 2010 Misc

There are no magic potions to increasing web traffic to your blog. There are only good frameworks and proven recipes. You may find loads of offers to significantly increase traffic to your site for a few dollars. Don’t fall for this trap. It takes a bit of hard work initially to get the right people repeatedly coming back to your site.

[want the rest...?]