Ease Windows Server 2003 Administration
Take advantage of Microsoft Management Console snap-ins to create a better administration tool.
by Danielle Ruest and Nelson Ruest
August 2003 Issue
For This Solution: Windows Server 2003
Q
We just migrated to Windows Server 2003, and I need to administer the new network. I took some training courses and know that several new administration tools are available. Can you recommend some that are easy to use?
—Mike, Denver, Colo.
A
Danielle: You're right—there are many new tools for administering Windows Server 2003. We like to take the KISS approach—Keep It Simple, but Structured—which takes your network's size into account and is threefold. First, if you have a small network and are new to Windows Server 2003, you might prefer to use the graphical user interface (GUI). The GUI's advantage is that it's harder to make mistakes, because you tend to work mostly with wizards. Wizards incorporate best practices directly and are good tools for learning what makes an OS tick. The disadvantage of the GUI is that it often forces you to work on only one server at a time.
The GUI also enables you to use both the Manage Your Server and Configure Your Server consoles. Manage Your Server runs automatically at system startup (unless you disable it) and gives you immediate access to single-purpose consoles applicable to the server role installed on each physical server (see Figure 1). This is one of the best ways to start working with Windows Server 2003. Configure Your Server is activated when you choose to add or modify a role on your server.
Second, you can administer Windows Server 2003 through the command line, using the Windows character-based command console. Windows Server 2003 boasts more than 60 new command-line tools (over Windows 2000). The advantage of this approach is that it's easy to create batch (BAT) or command (CMD) files that include commands you can apply to several servers at once. This approach is usually better for medium-sized shops running 50 servers or more. Its disadvantage is that it's easy to make mistakes, because everything in command mode is syntax-based, and misspelled commands can produce unpredictable results. If you decide to begin working with the command line, make sure you test each command thoroughly before putting it in a command file.
Third, you can use scripts. Like previous versions of Windows, Windows Server 2003 includes the Windows Scripting Host (WSH), a scripting environment that can run scripts in either graphical mode (using the wscript.exe command) or character mode (using cscript.exe). WSH supports scripts that affect general server environments through Windows Management Instrumentation (WMI) or affect Active Directory (AD) behavior through the Active Directory Services Interface (ADSI). Once again, it's easy to make mistakes in scripts, because they rely heavily on proper syntax. Microsoft's TechNet Scripting Center is a good place to learn more about scripting (see Resources)
Nelson: Danielle's right. You should target the right tool for your environment. My first recommendation is to create a testing environment for change management. The testing environment ensures that changes don't affect your production servers, whether you're testing the effects of a change through a graphical console or trying out a new command file. One of the best ways to do this is to use virtual machines. Virtual machines take up about 4 GB of disk space and can require as little as 96 MB of RAM. If your system has enough capacity, you can create several copies of the same machine. You can also discard the changes you make from one session to the next easily by using nonpersistent disks. You can even test cluster technologies by simulating cluster hardware. The two main virtual machine products are Microsoft Virtual PC and VMware Workstation 4 (see Resources). If you have an enterprise or select agreement with Microsoft, you might choose Virtual PC; otherwise, one is as good as the other. A great advantage of virtual-machine technology is that you can even carry several virtual machines running Windows Server 2003 on your laptop.
My second recommendation is to customize your administration environment. I use a single Microsoft Management Console (MMC). I call it my Global MMC, because it includes every tool I need to use in graphical mode. Windows Server 2003 provides a useful console through the Computer Management console (you can find it in Administrative Tools). You can also access this console by right-clicking on the My Computer icon to select Manage from the context menu.
However, although the Computer Management console is a good general-purpose console, it's not an all-encompassing tool. I like to modify this MMC to create the Global MMC, which includes all the Computer Management console's features, as well as these snap-ins: .NET Framework 1.1 Configuration, the three AD snap-ins (Users and Computers, Sites and Services, and Domains and Trusts), Authorization Manager, Certification Authority (you must specify the server to manage), Component Services, Distributed File System, Group Policy Management (requires installation of the Group Policy Management Console [GPMC]), Performance Logs and Alerts, Remote Desktops, Resultant Set of Policy, Security Configuration and Analysis, Security Templates, Terminal Services Configuration, and Wireless Monitor.
Keep in mind that you must have the associated products installed on your network to include all the snap-ins I've mentioned. You must also install the GPMC before you can integrate it into your Global MMC. You can obtain it by searching for GPMC at www.microsoft.com/download. A hot fix for the GPMC is required on Windows XP Professional machines, but it's included in the GPMC installation. You also need Service Pack 1 and the .NET Framework, and you must install the Windows Server 2003 Administration Toolkit before you create the Global MMC. You can find it in the Support folder on the Windows Server 2003 installation CD.
Follow these steps to create the Global MMC:
- Launch the Computer Management console in editing mode by using Start | Run to execute this command:
mmc /a %SystemRoot%\system32\compmgmt.msc
- Select File | Save As to save the console as Global MMC.msc in your My Documents folder.
- Select File | Add/Remove Snap-in to open the dialog box, making sure you choose Computer Management under "Snap-ins added to," then click on the Add button.
- Double-click on each of the snap-ins I listed previously, then click on Close.
- Click on OK to return to the console.
- Under File | Options, name the console Global MMC, set it to User mode - full access, uncheck "Do not save changes to this console," then click on OK.
- Use File | Save to save your changes.
You'll discover several uses for this console, but you'll use it primarily to manage your network of servers. It includes the Remote Desktops snap-in, so you can use it to create connections to each of your servers and keep them all within easy reach. You can also copy this console to each of your servers to give yourself immediate access to a familiar tool when you connect to them through the Remote Desktop. The Global MMC is the Swiss Army Knife of consoles (see Figure 2).
The next thing you need to do is secure this console thoroughly, because it's powerful. As you probably learned in your courses, Mike, you should always use two accounts: a user account for productivity work and an administrative account for server-based operations. To secure the console fully, you must store it in your My Documents folder (by default, you should be the only one to have access) and then use the Run As command to create a shortcut to this console.
Follow these steps to create a Run As shortcut:
- Move to the folder where you stored the console. Right-click on Global MMC.msc and select Create Shortcut.
- Right-click on the shortcut you've created and select Properties.
- Click on the Shortcut tab's Advanced button.
- Select "Run with different credentials" in the Advanced dialog box, then click on OK to close the dialog box.
- Click on OK to close the Properties dialog box.
The shortcut is ready, and you can move it to the Quick Launch Area. When you use the shortcut, it displays the Run As dialog box automatically. You can then choose to run it with your current credentials or you can select The following user and enter administrative credentials. Your console is now secure.
Q
We're running NT now and want to move to Windows Server 2003, but our administrators are really scared of Active Directory (AD). How can I convince them that it isn't as bad as it seems?
—Marie-Andrée, Quebec, Quebec
A
Danielle: It's true that AD can seem daunting, given the high volume of information published about it. But you have an advantage already, because you can migrate directly to Windows Server 2003. AD creates a virtual space that enables you to manage users, computers, servers, groups, and security settings from a single point. This is a major change from Windows NT, but AD does simplify many tasks. You need to switch tools constantly in NT to manage any one of the objects I've mentioned—User Manager for users and groups, Server Manager for servers, System Policy Editor for policies, and much more. AD lets you simplify most management tasks by using the Active Directory Users and Computers console for most of them.
You can install AD in its default configuration at first, and—because it's a virtual environment—change and modify it as you learn more about it. These changes aren't without impact (all changes are replicated to all domain controllers in the same domain), but you can minimize the impact if you're careful. The AD forest you create depends on your organization's size and configuration.
Nelson: The best place to start is with definitions and vocabulary. The domain concept in AD tends to confused newcomers. A domain in NT is a security boundary that delimits the security scope within an organization. This isn't the case in Windows 2000 and Windows Server 2003, where the AD domain is a security-policy boundary and a replication boundary. It controls the replication scope for the data it holds.
The forest is the security boundary. The forest is the largest single partition for any given database structure. Every person and every device that participates in the forest shares a given set of attributes and object types. However, information sharing in AD isn't limited to a single forest. Windows Server 2003 introduces the concept of "forest trusts," which allow forests to extend the transitive trust nature of one AD database with another, and vice versa.
If you compare the AD forest to Windows NT, you can see easily that although NT also includes an identity-management database—the domain—its scope is seriously limited compared to AD. NT can store the user or computer name along with passwords and a few rules that affect all objects. The basic Windows Server 2003 AD database includes more than 200 object types and more than 1,000 attributes by default. Whether or not you use them all depends on your organization's size.
Danielle and Nelson: If you want to move to AD without scaring everybody, Marie-Andrée, follow these tips: First, use the KISS rule we outlined earlier—Keep It Simple, but Structured. Second, think small. Try adding a new child domain instead of adding another forest, or try adding a new organizational unit instead of adding a new domain. This will help you contain your AD's scope. Keep in mind that you need at least one forest, at least one domain, organizational units for administration and delegation, and sites to contain replication. Third, draw your new AD structure on paper. Meet with your coworkers and outline together what your AD should look like. You can download a free chapter from our latest book from www.reso-net.com/WindowsServer to help you in this process. You can also find an AD design-job aid if you sign in to access this companion Web site. Once you all agree on the AD drawing, you can even transfer it to Visio and upload it directly into AD from there. Finally, use virtual machines to test your designs—and test, test, test. This is the only way to make sure you get it right.
Got More Questions?
Contact Nelson and Danielle by e-mail at .
About the Authors
Danielle Ruest and Nelson Ruest are the authors of Windows Server 2003, Best Practices for Enterprise Deployments (Osborne McGraw-Hill, 2003) and Preparing for .NET Enterprise Technologies (Addison-Wesley, 2001). Both work for Resolutions Enterprises, a small Canadian consulting firm that provides architectural and project-management services. Nelson is a MCSE and MCT, and a frequent guest speaker at Comdex and other conferences.
|