Ease Windows Server 2003 Administration (Continued)

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:

1. Move to the folder where you stored the console. Right-click on Global MMC.msc and select Create Shortcut.
2. Right-click on the shortcut you've created and select Properties.
3. Click on the Shortcut tab's Advanced button.
4. Select "Run with different credentials" in the Advanced dialog box, then click on OK to close the dialog box.
5. 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.