Based on my experience as a systems consultant for enterprise environments, many of those 1 million Windows 2000 servers are:
- Rogue workgroup file and print boxes or member servers in existing Windows NT 4.0 domains.
- Acting as non-domain-connected workgroup IIS 5.0 Web servers.
- Acting as Windows 2000 Terminal Servers replacing aging Citrix Winframe or Metaframe or Microsoft Terminal Server machines.
While Windows 2000 Server provides a huge improvement in stability and functionality over previous versions of the product, the reception to its Active Directory has been less than lukewarm. Why hasn't it been embraced?
Reason 1: No PDC functionality
Microsoft shot itself in the head by not giving Windows 2000 Server the
ability to act as a drop-in replacement for an existing NT 4.0 Primary
Domain Controller (PDC) or Backup Domain Controller (BDC). For many
environments, the NT 4.0 master domain/resource domain model is fine, and
they don't need or want a sophisticated directory service.
As it stands, you can run Windows 2000 as a member server, as a rogue workgroup machine, or as an AD domain controller. You can have a "mixed-mode" AD domain where NT 4.0 servers authenticate to a Windows 2000 domain controller, but to accomplish this you have to perform an upgrade install on your existing PDCs and BDCs. Optimally, you should be able to drop a new Windows 2000 box into your domain and have it assume the role of a BDC (or a workgroup or member server), which could then be promoted to PDC. Then, when the environment is ready, you should be able to promote the PDC to an Active Directory domain controller, allowing for mixed-mode use.
Reason 2: History repeats itself
Remember Novell's initial release of NetWare 4 bundled with NDS way back in
1994? Because of NDS's complexity, it took a long time for NDS to get mind
share in NetWare 3.12 shops.
Microsoft's bundling of the first version of AD with its operating system forces an upgrade to AD if you want any kind of centralized security authentication, so it's clear the company hasn't learned from Novell's bundling mistakes. It would have made sense for AD 1.0 to be an add-on product to Windows 2000, probably in the form of Exchange 2000; except that Exchange 2000 came out quite a few months after Windows 2000. You can't deploy or upgrade from Exchange 5.x to Exchange 2000 without Active Directory, so it makes sense that AD's early adopters are often Exchange shops, which already understand AD's replication and site architecture.
Reason 3: A firm hand on the namespace
One of the key factors in a successful AD deployment is designing the Active
Directory DNS namespace. Unlike NT 4.0, which uses WINS, Windows 2000 uses
DNS to resolve names on the network.
Unfortunately, you can't just use any old DNS. Active Directory requires that the DNS support dynamic updates via RFC 2136; and guess what, the only DNS that does that out of the box is included in Windows 2000. Those environments that already have Internet domains and DNS servers on their networks now have to replace their existing DNS servers with Windows 2000 boxes or create a new internal domain to host the AD. For example, if your company is called WidgetCo, and all your internal servers are TCP/IP hosts on widgetco.com, you either need to create a sub-domain called ad.widgetco.com or you need to create something like widgetco.net, as one of my associates had to do at a large Manhattan-based international law firm.
It's possible to make Unix DNS servers like BIND (Berkeley Internet Name Daemon) support Windows 2000 dynamic DNS, but it's a little tricky. Microsoft TechNet's white paper on Windows 2000 DNS provides information on getting your non-MS DNS to comply with RFC 2136. Chances are you'll need to upgrade your Unix server to the latest version of BIND, version 8.2, to make it work. Creating an entirely new domain may be less of a headache.
4. The predominance of IT fiefdoms
Most large companies are collections of fiefdoms that each has its own IT
standards. In a worst-case scenario, AD may be implemented by each IT
fiefdom separately and on its own time frame. The problem with this is that
once you start an AD, the first domain becomes the parent domain and all
successive domains are child domains. You either have to live with the
hierarchy that someone else started or you have to wipe the entire thing out
and start from scratch. Microsoft still hasn't given us a way to graft two
ADs together, although these tools are reportedly coming in
Windows 2002 Server.
5. Deficient built-in tools
AD is a failure because it lacks good tools for administering it on a large
scale. Key features, such as easy drag-and-drop of objects and
organizational units, and trouble-free pruning and grafting, are only
available through third-party utilities.
The problems with the built-in tools are exacerbated by the Microsoft Management Console (MMC). With its scores of plug-in modules, the MMC is a bear to deal with. If the MMC designers thought like NT administrators, they would use tabular views instead of endless levels of layered dialog boxes.
What Microsoft needs to do is provide an uber-management tool like SystemTools.com's Hyena or Dorian Software Creation's UltraAdmin. These products let you drill down to manage the directory, objects, and services.
Those are the top five flaws I think are holding AD back. Let me know what your issues are, or, if you've implemented AD, whether the gain is worth the pain.
Jason Perlow is a computer industry freelance writer covering Windows 2000 and Linux. He runs the New Jersey-based systems integration firm Argonaut Systems and can be reached at perlow@hotmail.com. COMMENTARY--Microsoft's Active Directory (AD) is a powerful tool for an enterprise computing environment, but there haven't been many enterprise environments lining up to adopt it. According to February 2001 data from the Giga Information Group, Windows 2000 server licenses exceeded the 1 million copy mark, but only 10 to 15 percent have deployed AD in any way. Many of the AD deployments have been relegated to lab testing or small, virgin Windows 2000 environments.
Based on my experience as a systems consultant for enterprise environments, many of those 1 million Windows 2000 servers are:
- Rogue workgroup file and print boxes or member servers in existing Windows NT 4.0 domains.
- Acting as non-domain-connected workgroup IIS 5.0 Web servers.
- Acting as Windows 2000 Terminal Servers replacing aging Citrix Winframe or Metaframe or Microsoft Terminal Server machines.
While Windows 2000 Server provides a huge improvement in stability and functionality over previous versions of the product, the reception to its Active Directory has been less than lukewarm. Why hasn't it been embraced?
Reason 1: No PDC functionality
Microsoft shot itself in the head by not giving Windows 2000 Server the
ability to act as a drop-in replacement for an existing NT 4.0 Primary
Domain Controller (PDC) or Backup Domain Controller (BDC). For many
environments, the NT 4.0 master domain/resource domain model is fine, and
they don't need or want a sophisticated directory service.
As it stands, you can run Windows 2000 as a member server, as a rogue workgroup machine, or as an AD domain controller. You can have a "mixed-mode" AD domain where NT 4.0 servers authenticate to a Windows 2000 domain controller, but to accomplish this you have to perform an upgrade install on your existing PDCs and BDCs. Optimally, you should be able to drop a new Windows 2000 box into your domain and have it assume the role of a BDC (or a workgroup or member server), which could then be promoted to PDC. Then, when the environment is ready, you should be able to promote the PDC to an Active Directory domain controller, allowing for mixed-mode use.
Reason 2: History repeats itself
Remember Novell's initial release of NetWare 4 bundled with NDS way back in
1994? Because of NDS's complexity, it took a long time for NDS to get mind
share in NetWare 3.12 shops.
Microsoft's bundling of the first version of AD with its operating system forces an upgrade to AD if you want any kind of centralized security authentication, so it's clear the company hasn't learned from Novell's bundling mistakes. It would have made sense for AD 1.0 to be an add-on product to Windows 2000, probably in the form of Exchange 2000; except that Exchange 2000 came out quite a few months after Windows 2000. You can't deploy or upgrade from Exchange 5.x to Exchange 2000 without Active Directory, so it makes sense that AD's early adopters are often Exchange shops, which already understand AD's replication and site architecture.
Reason 3: A firm hand on the namespace
One of the key factors in a successful AD deployment is designing the Active
Directory DNS namespace. Unlike NT 4.0, which uses WINS, Windows 2000 uses
DNS to resolve names on the network.
Unfortunately, you can't just use any old DNS. Active Directory requires that the DNS support dynamic updates via RFC 2136; and guess what, the only DNS that does that out of the box is included in Windows 2000. Those environments that already have Internet domains and DNS servers on their networks now have to replace their existing DNS servers with Windows 2000 boxes or create a new internal domain to host the AD. For example, if your company is called WidgetCo, and all your internal servers are TCP/IP hosts on widgetco.com, you either need to create a sub-domain called ad.widgetco.com or you need to create something like widgetco.net, as one of my associates had to do at a large Manhattan-based international law firm.
It's possible to make Unix DNS servers like BIND (Berkeley Internet Name Daemon) support Windows 2000 dynamic DNS, but it's a little tricky. Microsoft TechNet's white paper on Windows 2000 DNS provides information on getting your non-MS DNS to comply with RFC 2136. Chances are you'll need to upgrade your Unix server to the latest version of BIND, version 8.2, to make it work. Creating an entirely new domain may be less of a headache.
4. The predominance of IT fiefdoms
Most large companies are collections of fiefdoms that each has its own IT
standards. In a worst-case scenario, AD may be implemented by each IT
fiefdom separately and on its own time frame. The problem with this is that
once you start an AD, the first domain becomes the parent domain and all
successive domains are child domains. You either have to live with the
hierarchy that someone else started or you have to wipe the entire thing out
and start from scratch. Microsoft still hasn't given us a way to graft two
ADs together, although these tools are reportedly coming in
Windows 2002 Server.
5. Deficient built-in tools
AD is a failure because it lacks good tools for administering it on a large
scale. Key features, such as easy drag-and-drop of objects and
organizational units, and trouble-free pruning and grafting, are only
available through third-party utilities.
The problems with the built-in tools are exacerbated by the Microsoft Management Console (MMC). With its scores of plug-in modules, the MMC is a bear to deal with. If the MMC designers thought like NT administrators, they would use tabular views instead of endless levels of layered dialog boxes.
What Microsoft needs to do is provide an uber-management tool like SystemTools.com's Hyena or Dorian Software Creation's UltraAdmin. These products let you drill down to manage the directory, objects, and services.
Those are the top five flaws I think are holding AD back. Let me know what your issues are, or, if you've implemented AD, whether the gain is worth the pain.
Jason Perlow is a computer industry freelance writer covering Windows 2000 and Linux. He runs the New Jersey-based systems integration firm Argonaut Systems and can be reached at perlow@hotmail.com.
