I have a friend who runs a company that has gradually grown over the years, and with it their network has grown also. He started out with MS-DOS machines and gradually added various Windows servers and desktops until today he has several dozen computers running half a dozen or so Windows operating systems–and still one computer running MS-DOS 6.22 that hosts a business-critical application he is afraid of migrating to Windows.
This may sound like every system administrator’s horror story, but this kind of situation is all too common in business environments today. Basically, it’s a result of a number of factors including limited budget for upgrading hardware and software, and lack of foresight and planning. You can argue with such people all day long that upgrading their entire network to a single unified platform such as Windows Server 2003 in the back end and Windows XP on the desktop will bring them considerable savings on their Total Cost of Ownership (TCO), and they reply that they’re keeping overhead low because of squeezed profit margins and can’t afford such an overhaul no matter how desirable in the long run.
So while revolution would be the logical way to proceed in a situation like this, slow and gradual evolution is more likely, and as a result administrators need to keep on hand a wide variety of tools for managing the different versions of Windows running on their network. The trick is knowing which tool is needed to get each job done, and that’s what this article is all about.
The Tools Maze
The Windows 2000 Server/Advanced Server product CDs contain a Windows Installer file named adminpak.msi in the /I386 directory. Windows Server 2003 product CDs contain a similarly named file in the same folder. Both of these .msi files install a full set of GUI and command-line tools for Windows administration, but which should you use in a mixed Windows 2000/2003 environment?
The answer is the adminpak.msi file from the Windows Server 2003 product CD. This new set of administration tools (Build 3790) can be used to administer both Windows 2000 and Windows Server 2003 machines on your network. However, this new tools pack has several limitations:
1. Windows Server 2003 administration tools can’t be installed on an administrator workstation running Windows 2000 Professional, so if you want to run these tools from a workstation (as opposed to a server) you must install them on a Windows XP Professional machine that has Service Pack 1 or later installed on it. Of course, you can also install these tools on a Windows Server 2003 member server and do all your administrative work such a server running on your desktop, but that’s a bit pricy from a cost standpoint.
2. Windows Server 2003 administration tools use LDAP signing to secure communications between running instances of these tools and the servers they administer. This feature affects how a number of admin tools work including the four Active Directory consoles, ADSI Edit, the Ds*.exe command-line tools (like dsadd and dsmod), and the Group Policy Management Console. Because of this, if you still have Windows 2000 domain controllers running on your network then they need at least Service Pack 3 of you want to administer them using the Windows Server 2003 admin tools.
3. Some Windows Server 2003 administration tools have been removed from the Windows Server 2003 version of adminpak.msi. This includes Routing and Remote Access, Internet Information Services (IIS) Manager, and Internet Authentication Service. That’s unfortunate, for it means that if you have remote access servers or web servers you need to administer, you can’t administer them from a Windows XP administrator workstation with adminpak.msi Build 3790 installed. Your main alternatives in this case are: (a) go to the server room and log on to the local console of the server you want to administer, or (b) enable Remote Desktop (or install Terminal Services in Remote Administration Mode on a Windows 2000 server) and open Remote Desktop Connection on your XP machine to establish a remote admin session with the server you want to administer.
4. Some Windows Server 2003 administration tools simply can’t be used to administer certain aspects of Windows 2000 servers. For example, the Certification Authority console won’t work with Windows 2000 certificate authorities (CAs), and the Iis*.vbs admin scripts (such as Iisweb.vbs and Iisback.vbs) only work with IIS 6 machines and not with IIS 5.
5. Some Windows Server 2003 administration tools won’t work from a workstation at all and need to be run from the local console of the server you want to administer. A prime example here is using Ntdsutil.exe to perform an authoritative restore from the command-line, though there is a workaround–copy a DLL named Ntdsbsrv.dll from a Windows Server 2003 domain controller to your Windows XP admin workstation.
6. Some Windows Server 2003-specific functionality of the Windows Server 2003 admin tools only work (naturally) with Windows Server 2003 servers, not Windows 2000 servers. For instance, the Active Directory and Trusts console won’t display advanced forest and domain functionality or advanced types of trusts supported by Windows Server 2003 when you connect to Windows 2000 domain controllers; the Connect to console option when you add a new connection to the Remote Desktops console doesn’t work when you are connecting to a Windows 2000 server running Terminal Services in Remote Administration Mode; the Saved Queries feature in Active Directory Users and Computers (not supported in Windows 2000); the Object Picker that lets you simultaneously modify the same property for multiple objects in Active Directory Users and Computers (also not supported in Windows 2000); and so on.
7. Finally, some aspects of certain Windows Server 2003 admin tools won’t work from XP machines even when you are administering Windows Server 2003 servers! As an example, take a look at the properties of the Administrator account when viewed using Active Directory Users and Computers, first when running this tool on a Windows Server 2003 machine in the domain, and second when running it on a Windows XP machine in the domain:
Figure 1: Properties of Administrator account when viewed from a Windows Server 2003 machine using Active Directory Users and Computers.
Figure 2: Properties of Administrator account when viewed from a Windows XP machine using Active Directory Users and Computers.
Notice anything different? The Dial-in tab is missing when you view the properties of a user account from an XP machine! That means you can’t configure callback on a dial-up connection from a Windows XP admin workstation, you have to do it either from the console of the server or by using Remote Desktop Connection (which requires Remote Desktop to be enabled on the server). Of course, you can manage most remote access settings using remote access policies instead of the Dial-in tab by using the Routing and Remote Access console–but that console isn’t available on XP machines either!
There are other quirks as well when running Adminpak.mis Build 3790 from XP machines. For example, you can’t use the dhcp context of the netsh command to configure Windows Server 2003 DHCP servers remotely from your XP admin desktop–if you try and run any netsh dhcp server command, you get an error.
Conclusion
Microsoft says on the download page for downloading Build 3790 of adminpak.msi that “This is the final version (build 3790) of the adminpak.msi file”. Considering the flaws and limitations of running these tools on Windows XP administrator desktops, it’s discouraging that they’re not spending more time to refine these tools to make them work better. But just because Microsoft says something is final doesn’t mean it will remain this way–maybe when Windows Server 2003 Service Pack 1 is released there will be a new version of these tools that overcomes the limitations of the present version.
In the meantime however, what should administrators of a mixed Windows 2000/2003/XP network do to ensure they have the right tools for the job? Some suggestions are:
- Don’t bother keeping a Windows 2000 Professional workstation around the office with the Windows 2000 version of adminpak.msi installed for managing your Windows 2000 servers. That’s because the Windows Server 2003 administration tools basically do a well-enough job managing downlevel Windows 2000 servers (as long as you can remember which Windows Server 2003 features are not supported on Windows 2000).
- you have a lot of web servers or remote access servers running Windows Server 2003 to manage, consider using a Windows Server 2003 member server as your administrator workstation instead of an XP machine. That way you can connect to these machines using the Routing and Remote Access and Internet Information Services (IIS) Manager consoles instead of having to use Remote Desktop Connection.
- If you have few web servers or remote access servers running Windows Server 2003, enable Remote Desktop on these servers and manage them remotely using Remote Desktop Connection from your Windows XP administrator workstation.
And try to get an office within walking distance of the server room if any other incompatibilities crop up that make it difficult to manage your servers from your XP desktop. After all, exercise is something system administrators are usually short on!
