Of course, if you organize things properly, you make your management chores that much easier. In this article, I'll show you some of the components of AD and how you can organize and move them around.

Objects and containers

When you install a domain controller, Windows 2000 creates a default set of objects in AD along with the Active Directory structure. These objects include a handful of containers:

• Users - This is where all new users and groups are created by default.
• Computers - This is where all new computers are added to the domain.
• Builtin - This container holds the built-in security groups that are created when you create the domain.
• Domain Controllers - This is where domain controllers appear.

In addition, Windows 2000 creates a System container that stores AD systems and services information. The System container appears only if you choose Advanced Features from the View menu in the Active Directory Users And Computers console.

You also can create several other types of objects in AD:

• User
• Contact
• Computer
• Organizational Unit
• Group
• Shared Folder
• Shared Printer

When you create new users through the Active Directory Users And Computers console, those users are placed in the current container. For example, right-click the Users folder and choose New | User, and the resulting user will be placed in the general Users container. Right-click an organizational unit (OU) and create a new user, and the user is placed in that OU. Using OUs to structure users can be extremely useful for simplifying administration. For example, you can apply group policy at the OU level, giving you an easy means of applying policies that differ from site or domain policies to groups of users.

Moving objects

In a perfect world, you would set up your domain structure, populate AD, and be done with it. Everything would be where it needs to be, and you wouldn't have to worry about moving things around. Unfortunately, that just doesn't happen. You might need to restructure the domain, move domains to other trees or forests, move users from one OU to another, move OUs to other domains, and so on. Windows 2000 gives you a handful of tools to use to move objects to suit specific objects.

You can easily move a user from one container to another, such as from one OU to another within the domain or even to a different domain. The Active Directory Users And Computers console doesn't let you drag users to move them, but you can right-click a user and choose Move to open a Move dialog box. This dialog box enables you to select a container within the domain or another domain. Just select the desired location and click OK to move the user.

You can use the same method to move groups, computers, shared folders, printers, and other objects. Each object has a unique Global Unique Identifier (GUID), which doesn't change during the move, so moving objects generally has no effect on their behavior.

In some cases, however, there are implications for moving objects. If you move a user who is a member of the global group Support in the Software domain to the Hardware domain, that user's account takes on a new Security ID (SID) in the Hardware domain, the user's new home. Resources that were previously available to the user through that group membership are no longer available because of the SID change.

There are several ways to remedy the situation, including adding the new SID to the resource access control lists (ACLs), moving the group, and creating a parallel group in the new domain, among others. The implications for moving users and groups between domains is beyond the scope of this article, but keep in mind that moving security principals between domains often has consequences that must be handled in order for the affected users to continue using their resources.

Making things easier with MoveTree

If you need to move several objects, you might prefer to use the MoveTree utility, a Windows 2000 Resource Kit tool. MoveTree lets you move users, groups, and OUs from one Windows 2000 domain to another in the same forest. You can use MoveTree to move objects between child domains as well as between two domain trees in a forest. The source domain can be either a Mixed mode or Native mode domain, but the target domain must be Native mode. MoveTree copies the objects to the Lost And Found container in the source domain and then moves them to the destination domain. It does not move local or domain global groups, but it does retain group membership for accounts during the move.

MoveTree isn't a complete solution for moving users and groups between domains, however, because it does nothing to move the user's resources - profile, scripts, data, and so on - to the new domain. For that reason, you'll need to move these items separately, either manually or through a script.

In addition, moving security principals between domains typically has consequences for group policy application. Windows 2000 maintains the group policy links, which means that group policy for the relocated users is applied from the source domain, rather than from the target domain. This usually has performance considerations, because the policies are naturally applied across the network. Therefore, you should re-create the group policies in the target domain and link them to the affected users, and then remove the links to the group policies in the source domain.

Conclusion

Windows 2000's Active Directory presents a whole new ball game for Windows NT administrators. To be successful in implementing AD, you must know what objects you can work with and how to organize and move objects around. In this article, I've introduced you to AD containers and objects and explained how to move objects around.

Although it is possible to run Windows 2000 on your network as it is, you'll probably want to make a number of changes to the physical and the virtual network to get maximum benefit from the new operating system. In this article, I'll outline a few of the changes you may want to make, but this is by no means an exhaustive list.

In Windows 2000, clients rely on site information to identify the closest Active Directory server. Because sites correspond to IP subnets, you should place Active Directory servers on each subnet. You should also make sure that all systems on the same logical subnet are connected via LAN hardware. Some routing technologies, such as Proxy Address Resolution Protocol (ARP), can allow systems to be on the same logical subnet but different physical network segments. This setup will trick clients into thinking systems are closer than they really are, so it's best to stick to standard routing techniques.

Consider creating a new Windows 2000 domain and then bringing in your existing domains once everything looks correct. Just make sure you do not switch the new Windows 2000 domain to Native mode until the last Windows NT backup domain controller (BDC) has been upgraded.

Make sure you have planned your Active Directory structure before you start migrating your network. You'll be given the option of creating a new tree or joining an existing tree. Obviously, if you're the first domain in the network to be migrated, you'll want to create a new tree. If you're merging multiple domains into a single Active Directory domain, however, you'll want to join as a child of the existing tree.

Always migrate the Windows NT 3.51 or 4.0 Primary Domain Controller (PDC) to Windows 2000 Server Active Directory first so that users and groups from your current domain are automatically transferred into Active Directory. Before doing this, make sure you force synchronization between the PDC and all BDCs in the domain so the BDCs are completely updated with any recent changes.

Note!

If you want to ensure that you have a rollback should things go wrong, consider adding a new BDC to the domain and taking it offline before the upgrade.

Let the upgrade begin

When you begin the setup, the program will detect that a domain controller is being upgraded and will prompt you to install the Active Directory. This process will also give you the choice of creating the first tree in a new forest, creating a new tree in an existing forest, creating a replica of an existing domain, or installing a child domain.

As part of the Active Directory installation process, the contents of the Windows NT account database and the SAM are copied into the Active Directory. These objects form the security principals (user accounts, local and global groups, and computer accounts).

Existing clients will interface with the new Windows 2000 domain controller exactly as if it were still a PDC. As long as you have both Active Directory servers and legacy BDCs in operation simultaneously, your domain will function as a mixed mode domain. Mixed mode domains can't take full advantage of the new Active Directory features because Active Directory must ensure backward compatibility. For example, you can't use nested groups in mixed mode domains. However, most of the functionality of Windows 2000 is now available:

• The ex-PDC will appear as a Windows 2000 DC to other Windows 2000 systems and as a Windows NT PDC to older systems.
• You'll be able to use this system to create new security principals and to replicate these changes to Windows NT BDCs.
• Windows 9x and NT clients can use this system as a potential logon server.
• If this is the only Windows 2000 Server on the network and it goes offline for any reason, you'll be able to promote a Windows NT BDC to PDC.

Once you're sure that the mixed mode domain is functioning correctly, you can migrate your BDCs. When all domain controllers have been migrated, you can switch the domain to native mode, reboot the domain controllers, and take full advantage of the new features. Member servers and workstations running earlier versions of Windows will be completely supported and require no changes to interact with Active Directory servers. You'll realize more benefits by upgrading the member servers as well, but always start by upgrading domain controllers.

Windows NT Workstation clients should be upgraded to Windows 2000 Professional to take advantage of the new features of Active Directory. Microsoft will offer a service pack that will make Windows 95 and Windows 98 clients Active Directory–aware and allow them to participate in Kerberos security.

When you've finished the upgrade and have access to advanced Windows 2000 management tools and features, you may want to restructure your domain(s). Needless to say, restructuring isn't a trivial task and should not be approached lightly. It will require a great deal of planning.

Existing trusts

If this is the first tree, any trusts that existed before the PDC was upgraded will still exist but they will be limited to the explicit one-way Windows NT-style trusts.

If there are several trees/domains, transitive trusts will be enabled to any resource in any domain that is:

• A native mode domain.
• A mixed mode domain where all DCs have been upgraded.
• A mixed mode domain where the domain controller servicing the Kerberos or NTLM authentication request has been upgraded.

Limit administrator access

Many companies have split domains into user domains and resource domains. The reason may be because of the SAM size limitation of 40 MB in Windows NT or because local administration on resources in the domain is desired. In the latter case, explicit one-way trusts to account domains in the organization would have been created to restrict administration to resource domain administrators. If such domains are simply upgraded, a two-way transitive trust will be created between the child resource domain and the parent domain, eventually resulting in all domains trusting all other domains, thus losing the restrictions originally put in place.

To overcome this limitation, consider upgrading using Windows 2000 delegation features. That way you can fine-tune the access rights of domain administrators to the relevant domains (or trees). Remember also to ensure that the domain administrators do not have administrator access to the domain controllers through local accounts.

BDCs cannot be upgraded

As stated earlier, the end result of your domain upgrade should be a Native mode domain. This may not be possible if, for some reason, a BDC cannot be upgraded. For example, you may have an application that must run on a BDC but doesn't work under Windows 2000. You should be aware of any such problems before you begin the upgrade and take the necessary action. It may be that you can move the errant application to a member server; perhaps you can get the application upgraded to work under Windows 2000 or move the application on to a BDC in a different domain.

The point of no return

Once you've upgraded all your BDCs and switched to Native mode, you can't get back to Windows NT. The switch to Native mode is easy to do, but it's impossible to reverse because a number of things happen during the switchover:

• Netlogon replication ceases as Active Directory multimaster replication between DCs comes into force.
• No new Windows NT domain controllers can be added to the domain.
• The former PDC is no longer the master of the domain because all domain controllers can perform directory updates.
• Windows 2000 group types, such as universal and domain local groups and group nesting, are enabled.

Conclusion

The addition of Active Directory to Windows 2000 Server is the most significant reason to upgrade your servers. Active Directory combines Windows NT domains with Internet domains and makes them scalable from average company size to large enterprise capability. While the most significant benefit is the reduced cost of ownership, users will directly benefit from the advanced search capabilities of the Global Catalog.

Active Directory is both standards-based and flexible. It is based on the LDAP standard, which has already been adopted by Cisco for use on network hardware and UNIX systems. Any administrator who needs more functionality than is provided out of the box will appreciate the flexibility of Active Directory.

Microsoft wants it to be as easy as possible to migrate to Active Directory. To that end, it has provided wizards to transfer DNS responsibilities to Microsoft DNS dynamic update protocol servers. These wizards automatically import users and groups from legacy Windows NT domains. Finally, Microsoft has made every aspect of Active Directory setup intuitive and GUI-oriented, and Active Directory handles most complexities automatically.

In its simplest form, auditing is nothing more than creating a record of events. These events can be performed by users or by the servers themselves. An example of such an event might be a user logging in to the network. If you wanted to audit logins, you could actually create a record of every time that each user logged in to the network. All of the events you monitor are documented in Windows 2000's security log.

Okay, so auditing provides a method for documenting system and user events, but how can you make the security log useful? After all, if you audit every user and every system event, it's possible that the server will log hundreds of events every minute. I've lost count of the number of times that I've seen administrators log every single event in the name of good security. In such situations, the security log can quickly fill up, meaning that no more events will be logged until the log has been cleared out.

Excessive logging can also cause performance problems for the server since logging consumes disk and processor time. Another downside to logging every event is that the logs cease to be meaningful. If you suspect that a security breach may have occurred, locating a record of it can be like looking for the proverbial needle in a haystack.

As you can imagine, a better process is to audit only meaningful events rather than every single event in the entire system. After all, who cares if Fred in Accounting created a new spreadsheet this morning? Instead, you should look for and create logs of things that could potentially damage your network or its data, such as someone being granted administrative privileges or files being deleted from an important directory. In the sections that follow, I'll show you some guidelines you can follow to create an effective audit policy.

Success or failure

Before you audit anything, you should understand a little bit about how the auditing process works. When you audit an event, you can audit it by success, failure, or both. For example, suppose that you wanted to audit logins to the network. Depending on the size of your network, success audits may be overkill because they would create a security log entry every time that someone logged in. As alluded to above, this would create log files that grow quickly and become cumbersome to work with.

A more effective technique might be to use a failure audit for network logins. A failure audit would create a security log entry only if a user tried to log in and was unsuccessful. You could then review the audit log to see who had trouble logging in to the network. If a user's name appears only once in the security log, then you could probably assume that the user simply typed their password incorrectly. If you discover that a particular user has tried to log in unsuccessfully a number of times—especially after business hours—then you may want to investigate the invalid login as a possible hack attempt.

If you make such a discovery, you can take steps to counteract the hack attempt. These steps might include things like creating a policy that disables user accounts after three bad login attempts within a few minutes. If the hack attempts continue, you might look at what time the attempts are made each night and try to catch the hacker red-handed.

Enabling auditing

Now that you have a basic idea of what auditing is and how it works, it's time to begin building an audit policy. I'll start by showing you how to audit an event. Once I've done so, I'll explain which events that I recommend auditing.

As I mentioned earlier, auditing is configured through the use of an audit policy. You can set an audit policy to be applied to domain controllers, member servers, stand-alone servers, or workstations. If you apply a non-local audit policy to a domain controller, all other domain controllers within the domain will share that audit policy. I strongly recommend auditing all domain controllers because they are so crucial to your organization's security. It's also not a bad idea to audit member servers or stand-alone servers too if they contain any sensitive or confidential data. I don't recommend auditing Windows 2000 Professional workstations, unless you have a very specific reason for doing so. It's simply too time-consuming and inconvenient to constantly review the audit logs on every single workstation.

Before you begin to build an audit policy, I should point out that to do so, you must have the Manage Auditing And Security Log user right. The Administrator account has this right by default, but if you want a nonadministrator to manage the auditing, you'll have to grant them the appropriate permissions. In actuality, having a nonadministrator to do the auditing isn't a bad idea. You can remove the Manage Auditing And Security Log user right from the administrator's group to ensure that only one person has rights to the audit log. This is one way to keep administrators honest, since they won't be able to clear the security log after a misdeed.

The process of enabling auditing is similar for domain controllers and non-domain controllers. The biggest difference is that you use a different tool to get the job done. To set up an audit policy for your domain controllers, open the Active Directory Users And Computers console and navigate through the tree to Domain Controllers. Right-click Domain Controllers and select the Properties command from the resulting context menu. When you do, you'll see the Domain Controllers properties sheet. Now, go to the Group Policy tab, select the group policy that you want to audit, click Edit, and Windows will load the Group Policy console. Navigate through the group policy console to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy, as shown in Figure A. You're now at a point where the basic auditing technique is the same for both domain controllers and non-domain controllers.

Figure A

Navigate to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy.

To set up auditing for a non-domain controller, open the Local Security Policy console and navigate through the tree structure to Security Settings | Local Policies | Audit Policy. You can see an example of this screen in Figure B.

Figure B

To set up auditing for a nondomain controller, open the Local Security Policy console and navigate to Security Settings | Local Policies | Audit Policy.

From this point, the technique is the same whether you're on a domain controller or not. Let's audit an event. For demonstration purposes, we'll audit failed login attempts. As you can see in Figures A and B, Windows lists several different types of events that can be audited. One of these events is Audit Account Logon Events.

To audit a logon failure, right-click Audit Logon Events and select the Security command from the resulting context menu. When you do, you'll see a dialog box that will allow you to audit the events. The dialog box will vary slightly depending on whether or not you're auditing a domain controller.

If you're auditing a domain controller, you must select the Define These Policy Settings In The Template check box before you'll be able to audit an event. This check box doesn't exist when auditing nondomain controllers. At any rate, you'll now be able to audit an event success, failure, or both. For the purpose of auditing login failures, select the Failure check box, as shown in Figure C, and click OK.

Figure C

You can audit the success or failure of an event by simply selecting a check box.

Once you've set up the audit policy, you must apply it. To do so, you must either type a command at the command prompt, reboot your server, or wait until the next propagation cycle, which is usually every eight hours. If you decide that typing the command is the easiest method, open a command prompt window, type secedit /refreshpolicy machine_policy and press [Enter].

What needs to be audited?

Now that you know how auditing works, the first question that you should ask yourself is what really needs to be audited? As I mentioned, I always recommend auditing domain controllers, and if the situation applies, member servers and stand-alone servers. But what should you audit on those servers? I recommend that you audit the following items:

• Logon failures
• Policy changes
• Privilege use
• Account management
• Any directories that are confidential or sensitive (a file-level audit)
  

Before I get into file-level auditing, there are a couple of helpful hints that I should point out. First, it's a good idea to audit just about everything that members of the Administrator's group do. The reason for this is that a hacker will typically try to gain administrative access before attacking your system. Therefore, such an attack would likely show up as an administrative action.

Another tip is that when auditing users, you should audit the Everyone group instead of the Users group. The reason for this is that the Users group includes only authenticated users. It doesn't cover anonymous users who may have slipped through your Internet firewall. The Everyone group, on the other hand, covers all users whether or not they are authenticated.

File-level auditing

Before you can audit a file, directory, or other object, you must enable Object Access auditing by using the method that I demonstrated earlier. Once you've enabled object auditing, go into Windows Explorer and navigate to the object that you want to audit. Right-click the object and select the Properties command from the resulting context menu.

When you see the object's properties sheet, navigate to the Security tab and click the Advanced button. You'll now see the Access Control Settings For dialog box. Next, select the Auditing tab, click the Add button, and select the users or groups that you want to audit. Click OK to continue. You'll now see a long list of auditable actions related to the object. You can perform a success and/or failure audit on any of these objects by selecting the appropriate check boxes. Click OK to enable the auditing.

Review the security logs

One of the most important things that you need to know about auditing is that the simple act of auditing won't alert you to a security breach or an attempted break-in. It's up to you to read and understand what the security log entries mean. I recommend reading the security log the first thing in the morning, right after you change the backup tape. By doing so, you'll get into a routine, and you'll always be aware of your network's security.

Auditing at the file level

File level auditing is performed on NTFS partitions. For example, you could monitor changes to files within a specific directory. Generally, this type of auditing is only used if the contents of a particular directory are extremely sensitive or if you suspect a security breach, i.e., someone tampering with the files.

You can implement auditing on the entire partition if necessary, but doing so is usually overkill and results in extremely large audit logs. You can also audit an individual file as opposed to an entire folder if your needs tend to be more specific. However, auditing on a folder-by-folder basis is the generally accepted method of file level auditing. As I demonstrate the process of auditing a folder, keep in mind that the process is pretty much the same for auditing an entire partition or a single file. The biggest difference is that you’re selecting a folder instead of a file or a drive letter.

To implement file level auditing, go to an NTFS partition and select the folder to audit. You can audit a folder by right-clicking the folder and selecting the Properties command from the context menu to view the folder’s properties sheet. Then, select the Security tab and click Advanced. At that point, you’ll see the Access Control Settings For properties sheet. Select the Auditing tab.

By default, the Auditing tab is empty. However, you can add entries to the Auditing tab by clicking the Add button. When you do, Windows searches the domain and displays a list of all users, computers, and security groups. Then, select the objects you want to audit and click OK. It’s best to audit on a group basis unless you’re trying to track the actions of a specific user or computer. I should also point out that you aren’t limited to auditing the default domain. You can also select objects to audit from other domains or from Active Directory (AD) as a whole. Once you’ve chosen which objects you want to audit, click OK.

Next, you’ll see the Auditing Entry For folder name dialog box, where folder name represents the name of the folder you’re auditing. As you can see in Figure A, you can control several settings from this dialog box.

Figure A

The Auditing Entry For folder name dialog box controls the behavior of the audit.

At the top of this dialog box, you’ll see a list of the objects you’ve chosen to audit. Directly beneath that, you’ll see the Apply Onto drop-down list. This list controls which folders are affected by the audit. For example, by default, the audit applies to the folder, subfolders, and the files within the audited folders. However, there are many other settings you can use to customize this behavior. For example, you could audit this folder only, files only, this folder and files only, this folder and subfolders only, etc.

At the bottom of the dialog box, there's a check box labeled Apply These Auditing Entries To Objects And/Or Containers Within This Container Only. This check box basically acts as a shortcut to selecting items from the Apply Onto drop-down list.

The heart and soul of the dialog box is the Access pane, which lists all of the different events you can audit. Auditing works by building a log based on the success or on the failure of various events. Therefore, the Access pane lists all of the various events available for you to audit with Successful and Failed check boxes.

For example, if you wanted to know whether or not someone deleted a file from a folder, you’d select the Successful check box next to Delete. However, if you wanted to know if someone tried to delete a file from the folder, you’d select the Failed check box next to Delete. Of course, you could always use both check boxes.

Auditing printers

Just as you can audit entire partitions, you can audit the activity of a printer. To do so, right-click the printer’s icon and select the Properties command from the context menu to view the properties sheet. Select the Security tab and then click the Advanced button. You’ll now see the Access Control Settings For properties sheet. Click the Auditing tab to audit printers.

Click the Add button, and you’ll see a list of all of the users and groups that you can audit. Select which users and groups you'd like to audit and click OK. When you do, you’ll see a screen similar to the one shown in Figure B.

Figure B

You can audit printers as well as files and folders.

From there, you can perform a success or a failure audit on events such as printing, managing documents, managing printers, changing permissions, or taking ownership. Keep in mind that if you’re planning to audit a printer directly connected to a computer, you should implement the audit policy at that computer, not from a machine that simply maps to the printer from across the network.

You may be wondering why anyone would ever want to audit a printer. One reason is that some color laser or thermal printers require very expensive ink and paper. Therefore, some companies audit printer use to make sure no one wastes expensive office supplies on non-business-related printing projects.

More importantly, many companies print checks in-house. If you’re printing checks, or if you have other forms loaded into the printer, you’ll definitely want to audit the printer’s use.

Auditing the registry

You’d probably only want to audit the registry if you knew that a particular virus that had been floating around modified a registry key or if you wanted to find out whether or not users had been installing software. Of course you could also audit the registry to track changes that a hacker might make. In any of these instances, you need to know exactly which registry key to audit.

There are two different registry editors included with Windows 2000; however, you may only implement auditing through the REGEDT32 registry editor. To audit a registry key, enter the REGEDT32 command at the Run prompt to launch the Registry Editor.

When the Registry Editor loads, select the registry key you want to audit. Next, select the Permissions command from the Security menu. When you do, you’ll see the Permissions For properties sheet. Click the Advanced button to view the Access Control Settings For properties sheet. Select the Auditing tab and click the Add button to view the list of users and groups you can audit. Make your selection and click OK. When you do, you’ll see the screen shown in Figure C.

Figure C

You can enable auditing on individual registry keys.

From this screen, you can audit events such as Query Value, Set Value, Delete, and many others.

Auditing Active Directory

AD is the heart and soul of Windows 2000, because it contains vast quantities of information about users, groups, computers, and a variety of security settings. By tampering with AD, a hacker could do just about anything to your network. Therefore, it’s important to audit AD so you will be alerted when any changes are made.

Auditing of AD is performed through a group policy. To audit AD, open the group policy for your domain. To do so, enter the MMC command at the Run prompt. When the Microsoft Management Console loads, select the Add/Remove Snap-In command from the Console menu to view the Add/Remove Snap-In properties sheet. Click the Stand Alone tab’s Add button to display a list of all available snap-ins. Select the group policy snap-in from the list and click Add. When you do, Windows will display a dialog box asking which group policy object you want to load. Unless you have some other group policy you’d prefer to audit, click the Browse button and then select the Default Domain Policy from the list of available group policy objects. Then, click OK, Finish, Close, and OK. Doing so will display the group policy snap-in.

Now, select the top level of the Default Domain Policy, right-click it, and select the Properties command to view the Default Domain Policy properties sheet. Select the Security tab and click the Advanced button to reveal the Access Control Settings For Default Domain Policy properties sheet. This operation may take a few minutes to complete.

When you see the properties sheet, select the auditing tab. On that tab, you’ll see that some level of auditing has already been established to monitor the Everyone group. You can add additional auditing by clicking the Add button, or you can view or modify the existing auditing parameters by selecting the existing auditing entry and clicking the View/Edit button. You’ll see a properties sheet much like the one shown in Figure D.

Figure D

You can audit Active Directory access.

As you can see in the figure, auditing AD is like performing other types of audits in that you track the success or failure of various system events. What makes this auditing different is that the properties sheet consists of two tabs, the Object tab and the Properties tab. Both tabs contain auditing options. The difference between the two tabs is that the Object tab contains standard events such as reading, writing, or deleting. The Properties tab contains more specific events that pertain to an individual attribute of an object rather than to an entire object or an entire tree of objects.

In this article, I’ll show you how Performance Monitor can track your server’s performance under many different loads, which will help make sure your server is adequately servicing your users—no matter how many of them there are at any given time.

Firing up Performance Monitor

Unfortunately, Performance Monitor isn’t completely accurate because the act of measuring a component’s performance itself negatively affects the server’s performance, much like the computer version of the Heisenberg Uncertainty Principle. That said, Performance Monitor is accurate enough that you can make solid judgments based on its results. For more information about Windows 2000’s Performance Monitor, see the article “Working with Microsoft Windows 2000's Performance Monitor.”

Open Performance Monitor by selecting the Programs | Administrative Tools | Performance commands from the Start menu. When you do, the Performance console will open. Performance Monitor works by measuring various counters. To look at a counter, click the Plus icon above the graph. Doing so displays the Add Counters dialog box. This dialog box is divided into several sections, each of which allows you to specify what you want to track and how you want to track it.

You must begin the process by selecting which computer you want to monitor in the Select Counters From Computer dialog box. Next, select Performance Object, which is a general category of counters such as processor, memory, and paging file. After that, you must select the appropriate counter from the Select Counters From List box, each of which will vary depending on the Performance Object you want to track.

Depending on the counter you select, you may occasionally have to select Instance. Instance is used when more than one object exists for the counter. For example, if you were measuring hard disk performance but your system had more than one hard disk, you’d have to use the Instance section to select which hard disk you want to measure.

When you’ve selected the appropriate counter, click the Add button. You’re then free to select more counters. When you’ve finished, click Close to begin the measuring process.

Unless you need to compare two or more counters against each other, I recommend measuring one counter at a time. Working with multiple counters simultaneously can get confusing. Also, working with multiple counters can place a heavier tracking load on your system, which could obfuscate the results.

Set a strategy to find the peak

Performance Monitor allows you to track hardware- and software-related counters. Because you want to discover how your server’s hardware is handling the load placed on it, you’ll want to focus on the hardware-related counters. Remember, your hardware will perform differently under different situations. For example, if relatively few people are connected to your server, the server will probably perform fairly well. However, if your server is supporting a lot of users, then one of the hardware components may not be able to keep up with the demand.

Remember, you’re not looking for one critical value. You’re only looking for the point at which a given counter is at its highest. For example, in your network, typical processor usage may hover around 5 percent, but when the server gets busy, it may have a sustained level of 25 percent. If you only look for a critical value of 90 percent, you’ll miss the actual peak of your processor usage. Therefore, look at the values over time and compare them with previous values to find at which point the server is busiest. Some of the hardware Performance Objects and counters you should watch include:

• Processor | % Processor Time: This counter tracks the percentage of time that the processor is actually doing something, specifically executing a nonidle thread.
• PhysicalDisk | % Disk Time: This counter tracks when the server’s hard drive is busy processing read or write requests.
• PhysicalDisk | % Disk Read Time: This counter is similar to the % Disk Time counter, except that it only tracks the amount of time spent on disk reads, which can be important if you’re measuring something like a Web server, where the number of disk writes are few.
• Server | Files Open: As the name indicates, this counter tells you the number of open files on the server.
• Server | Logon/sec: This counter tracks the number of times users log on and off your server.
• Server | Server Sessions: This counter will tell you the current number of people logged on to your server.

Even though hardware counters offer the most useful information, software counters can help you locate the peaks as well. Some of the software counters you can use, especially on a server using IIS, are:

• Web Services | Anonymous Users / Sec: This counter measures the rate at which users are making anonymous connections using the IIS.
• Web Services | Non Anonymous Users / Sec: The reverse of the previous counter, this one measures the rate of logged-on connections.
• Web Services | Current Anonymous Users: This counter measures the number of users who currently have an anonymous connection to IIS.
• Web Services | Current Non Anonymous Users: This counter measures the number of users who have currently logged on to IIS.
• Web Services | Maximum Anonymous Users: This counter keeps a running total since startup and measures the total number of anonymous users who have ever connected.
• Web Services | Maximum Non Anonymous Users: This is the same as the previous counter, except this one measures logged-on users.
• FTP Services | Current Anonymous Users: This is the same as the corresponding Web Services counter, except that it measures FTP services instead.
• FTP Services | Current Non Anonymous Users: This is the same as the corresponding Web Services counter, except that it measures FTP services instead.
• FTP Services | Maximum Anonymous Users: This is the same as the corresponding Web Services counter, except that it measures FTP services instead.
• FTP Services | Maximum Non Anonymous users: This is the same as the corresponding Web Services counter, except that it measures FTP services instead.

If you just take a quick, one-time measurement, you’ll get a number that’s accurate for that particular period of time. However, this number would be drastically different if you took another measurement during peak high-volume or peak low-volume periods. The easiest way to determine what type of user load your server is under and how it reacts is to take measurements at regularly scheduled intervals to determine when the server is under the most strain.

When you figure out the peak usage time, you should gear the rest of your performance monitoring to take place during that time frame. That way, you’ll know how your server is holding up against its toughest day-to-day conditions.

There are two different methods that you can use to determine periods of peak activity. I prefer to use the regularly scheduled interval method that I explained earlier. You can also use Performance Monitor to build a log file and then collect data over a longer period.

The reason that I prefer to use the interval method is that it tends to be more accurate. When you build a log file for an extended time frame, often you’ll see average values for long periods of time, as opposed to real values for a particular moment. In the end, the averages can overwhelm any short-term peaks and valleys in the results, which can make high-usage times more difficult to detect.

Therefore, although the regularly scheduled interval method may require more hands-on time, it does provide you with more detailed and useful results. My strategy is to load the necessary counters and look at the values they generate every half hour to an hour.

Conclusion

When nobody is using your server, it probably runs great. But the real question is, how good is it when users are hitting it hard? Performance Monitor can help you find periods of peak usage and help you judge how your server is performing under these loads. If your server is struggling with long periods of high usage, then it’s time to investigate getting a new server.

To start Performance Monitor, go to Start | Programs | Administrative Tools | Performance Monitor. Windows 2000 uses the Microsoft Management Console (MMC) to administer Performance Monitor, as shown in Figure A, so the screen has a different look than it does in Windows NT.

Figure A (Click here to view the image)
Windows 2000's Performance Monitor runs under the Microsoft Management Console.

You should configure the performance logs and alerts to report data for the counters at regular intervals. The logs should be retained over an extended period of time. A database can use this data to perform queries.

To get a good snapshot of your server's performance, you should take the following actions:

• Disable any screensaver program that is running on the server.
• Stop any services that are not essential.
• Increase the size of the paging file to the total amount of RAM plus 100 MB.

Performance Monitor itself can create unnecessary overhead. You should not run Performance Monitor in Graph view all of the time. Monitoring too many counters at once or sampling at intervals less than three seconds apart can degrade system performance. It's also a good idea to log your information to a disk other than the one you're monitoring.

Performance objects and counters

Windows 2000 gathers performance data from components in your computer. A performance object is usually named for the component that generates the data. Some of the objects you will typically monitor are cache, memory, paging file, process, processor, server, and system. Some software applications, such as SQL Server, add additional objects that can be monitored.

While in the Performance Monitor application, click the plus sign (+) in the right-hand pane to add a performance counter. When you do, you'll see the screen shown in Figure B.

Figure B

You can easily add performance counters.

Each object has multiple counters that represent data on specific aspects of a system. For information about a specific counter, click Explain in the Add Counters dialog box. While Performance Monitor has many different counters that you can monitor, you should monitor the activity of the following components first:

Memory:

• Available bytes
• Cache bytes
• Pages/sec
• Page Reads/sec

Processor:

• % Processor Time (all instances)
• Interrupts/sec

Disk:

• Physical Disk\Avg. Disk Queue Length (all instances)
• Physical Disk\Disk Reads/sec
• Physical Disk\Disk Writes/sec

Network:

• Network Segment\% Net Utilization
• Network Interface\Bytes Total/sec
• Network Interface\Packets/sec
• Server\Bytes Total/sec

Other:

• Paging File\% Usage Object (all instances)
• Cache\Data Map Hits %
• Server\System\Processor Queue Length (all instances)

After you've selected your counters and start tracking events, you can watch Performance Monitor track the counters and draw a graph representing them. A graph of performance data may look like Figure C.

Figure C (Click here to view the image.)
Performance Monitor displays a graph of the activity.

Establishing a baseline

A baseline is a performance level that you determine to be acceptable. You should monitor your server over a period of time during normal work conditions to begin creating your baseline. Once you gather the data, you can analyze it to determine where there might be problems or bottlenecks. Microsoft has outlined some recommended baselines for different counters. The ones below will give you a good start for creating a baseline that meets your needs.

• Disk—Physical Disk\% Disk Time: 90%
• Disk—Physical Disk\Disk Reads/sec, Physical Disk\Disk Writes/sec: Depends on manufacturer's specifications (Check the specified transfer rate for your disks to verify that this rate doesn't exceed the specifications. In general, Ultra Wide SCSI disks can handle 50 I/O operations per second.)
• Disk—Physical Disk\Current Disk Queue Length: Number of spindles plus 2 (This is an instantaneous counter; observe its value over several intervals. For an average over time, use Physical Disk\Avg. Disk Queue Length.)
• Memory—Memory\Available Bytes: Less than 4 MB (Research memory usage and add memory if needed.)
• Memory—Memory\Pages/sec: 20 (Research the paging activity.)
• Network—Network Segment\% Net Utilization: Depends on the type of network (You must determine the threshold based on the type of network you are running. For Ethernet networks, 30% is the recommended threshold.)
• Paging File—Paging File\% Usage Object: 99% (Review this value in conjunction with Available Bytes and Pages/sec to understand paging activity on your computer.)
• Processor—Processor\% Processor Time: 85% (Find the process that is using a high percentage of processor time. Upgrade to a faster processor or install an additional processor.)
• Processor—Processor\Interrupts/sec: Depends on the processor (A dramatic increase in this counter value without a corresponding increase in system activity indicates a hardware problem. Identify the network adapter that's causing the interrupts.)
• Server—Server\Bytes Total/sec: If the sum of Bytes Total/sec for all servers is roughly equal to the maximum transfer rates of your network, you may need to segment the network.
• Server—Server\Pool Paged Peak: Amount of physical RAM (This value is an indicator of the maximum paging file size and the amount of physical memory.)
• Server—Server Work Queues\Queue Length: 4 (If the value reaches this threshold, there may be a processor bottleneck. This is an instantaneous counter; observe its value over several intervals.)
• Multiple Processors—System\Processor Queue Length: 2 (This is also an instantaneous counter; observe its value over several intervals.)

Addressing performance problems identified by Performance Monitor

Performance Monitor can help you identify performance problems and allow you to analyze the data. If your servers' resources are insufficient, you may need to upgrade components such as RAM, hard disks, paging files, etc. It may also be necessary to balance workloads among resources. Some programs monopolize a resource and won't allow other programs to use it. Those programs may need to be reconfigured or rewritten. The premier problem that your server will experience is a lack of memory.

It's important that you approach any performance problem systematically. Make only one change at a time. If you make too many changes at once, it may be impossible to accurately assess the impact of each change. Many performance problems generate errors that you can display using Event Viewer.

After you make a change, you should resume monitoring and compare the before and after data to determine if the change made an impact on the problem. If you think that performance problems may be due to network components, you can compare the performance of applications run over the network with the performance of locally run applications.

The type of performance problems you are having determines the type of corrective action you should take. Let's look at some problems and common performance tweaks you can make.

• You can correct disk problems by installing additional drives or upgrading to faster drives.
• Use Windows 2000 Distributed File System (DFS) to balance the workload.
• Run disk defragmenters to optimize your disk space.
• Overcome memory problems by increasing physical memory, increasing the page file size, or creating multiple paging files.
• Add or upgrade processors to improve performance.
• Remove protocols that are not used and be sure to place the protocol used most frequently at the top of the binding list.
• Use a 32-bit adapter instead of a 16-bit adapter for a significant increase in network performance.

Troubleshooting Performance Monitor

In this section, I'll discuss some of the common problems you may experience and some solutions and explanations.

If you set up a counter but receive no data, you should check to see if the counter's associated DLL file has been deleted. Performance Monitor will not detect if the counter has been deleted once it is in use, but it will continue to report the counter data as zeros.

A counter may also report zeros if you do not have the appropriate permissions with which to monitor the computer. You'll get an error message when you attempt to set up the counter, but if you ignore the message, it will allow you to proceed.

You may notice gaps in your line graphs if the processing activity on a system becomes too heavy. The graphing will resume when adequate resources are available. The graph is also limited to 100 samples, so all values recorded in a log may not appear in the Graph view.

If Task Manager shows that a process is running but is still not reporting data, you can use the Exctrlst.exe utility on the Windows 2000 Resource Kit companion CD to verify that the counter DLL is enabled.

To monitor a 16-bit application, you must monitor the application via the NTVDM process. Only 32-bit processes appear in the Instances list. If you plan to use Microsoft Excel to analyze the log files, you will have to stop the performance logs and alerts because Excel requires exclusive access to the log files.

Conclusion

The look and feel of Windows 2000 Performance Monitor separates it from the Windows NT Performance Monitor. Both programs use a set of objects and counters to help measure the performance of your computer. You can still find the Windows NT 4.0 version of Performance Monitor (Perfomon4.exe) on the Windows 2000 Resource Kit, but in most cases you'll want to use the MMC version of Performance Monitor native to Windows 2000. In this article, I've pointed out the differences between the two versions and shown you the advantages of using the MMC version.

Before I get started, it's important to point out that there are an infinite variety of hardware problems. No single method is going to pinpoint every one of these problems. Therefore, the purpose of this article is to teach you about methods you can use for diagnosing some of the more common types of hardware problems.

Because no one method or tool will diagnose every hardware problem, it's important to know what troubleshooting and diagnostic tools are available to you. Only by using a wide range of tools and techniques can you hope to correct the extremely diverse variety of problems that can occur.

The log files

When it comes to tracking down a hardware problem, the best place to start is with the log files. The log files will often tell you exactly what's wrong with the system. If you've come from a Windows NT background, it may sound very strange to start the process by looking at the log files. After all, in Windows NT, if there was a hardware problem, many times the system wouldn't boot, and therefore, you couldn't look at the log files. If the system did manage to boot, the hardware problem probably wasn't too severe to begin with and was easy to diagnose on your own.

However, let's think about this logic in the context of Windows 2000. Windows 2000 offers a couple of ways to boot the system and access the log files during all but the worst hardware failures. Even though you may have to boot the system into a crippled state such as Safe Mode, you can still access the log files.

Now, what about the idea that if the system is bootable, the log files won't be much help? Personally, I've often found that nonhardware problems can many times emulate a hardware failure. For example, you might have a service or a device driver file that becomes corrupted. Naturally, the hardware device won't work if the device driver has been corrupted, but you may never spot such a problem without reviewing the log files.

So which log files should you look at when failures occur? If you can boot the system into Safe Mode or into Normal Mode, I recommend checking the system log to see if any warnings or errors have been reported. Unfortunately, if you have to resort to using the Recovery Console, using the system log isn't an option.

If the system won't boot into Normal Mode, the next thing you should check is the boot log. To do so, boot the system, and when you see the screen that asks which operating system you want to boot, press the [F8] key. When you do, you'll see a more extensive boot menu. From this menu, select the Boot Logging option. This option will attempt the boot process but will add entries to the log file each step of the way. This means you'll have a log of everything that happened up to the point of failure. Since the log is a text file, you can view it through Safe Mode or through the Recovery Console with no problem. The file's name is NTbtlog.txt, and the file is located in your Windows directory.

The Safe Mode method

So far, I've mentioned Safe Mode quite a bit. The Windows 2000 Safe Mode is very similar to the Safe Mode option in Windows 9x. The idea behind Safe Mode is that Windows will load with a minimal set of drivers and services. Therefore, if the failure isn't occurring on a device that's absolutely critical to the system, Windows 2000 will be able to load because it won't be loading drivers and services related to the damaged device.

To access Safe Mode, boot the system and press the [F8] key when you see the menu that asks which operating system you want to load. When you do, you'll see a more extensive boot menu. Simply select the Safe Mode option, and Windows will boot into Safe Mode.

Once you've managed to boot Windows into Safe Mode, you're well on your way to correcting the problem. If you've ever tried to repair a hardware problem in Windows NT, you know how difficult it can be to fix a problem from outside the operating system. Booting into Safe Mode provides you with access to the GUI interface. This means you'll have tools available to you that you wouldn't have access to from outside the GUI.

So now the big question is once you're in Safe Mode, what do you do? With any luck, you'll have a clue as to what the problem is and you can go ahead and fix it. However, if you don't know what the problem is, I recommend going into Device Manager and disabling every device that isn't critical to the system. Remember that this is exactly what Windows did, and it was able to boot into Safe Mode. This means that if you were able to access Safe Mode, all of the critical drivers are working. Therefore, disable everything that isn't critical and try booting the system into Normal Mode. If the system boots into Normal Mode, you can be sure that one or more of the devices you disabled was causing your problem.

The next step of the process is to determine which device was to blame. To do so, reenable one device and reboot the system. If the system boots, then the device you enabled was okay. If the system fails to boot, go back into Safe Mode, disable that device, and enable a different device. The idea is to enable one device at a time, rebooting between each device, until you've determined which device or devices are causing the problem. Once you have that information, you can begin taking steps to correct the problem.

The Recovery Console

The Recovery Console is new to Windows 2000. As you may recall, one of the biggest concerns with correcting problems on a Windows NT system was that if the system wouldn't boot and if the hard drive was formatted in the NTFS format, there was no way of accessing the hard disk to repair the problem (short of using a hacker tool). It didn't take Microsoft long to realize that this was a drawback, so it included something called the Recovery Console in Windows 2000. The Recovery Console is a command-prompt environment that grants the administrator full read and write access to all the partitions on your system. It also offers other capabilities, such as the ability to enable or disable services from a command-prompt environment. The Recovery Console isn't as powerful a tool as Winternals Software's ERD Commander 2000, but it will get the job done in a pinch.

Unfortunately, the Recovery Console isn't installed by default. The reason Microsoft doesn't automatically install the Recovery Console with Windows is that it consumes over 70 MB of hard-disk space. If you have the disk space to spare, I recommend installing the Recovery Console on your servers before a crash occurs. However, if a crash has already happened or if you can't spare the disk space, you can access the Recovery Console through the Windows 2000 boot disks.

The Blue Screen of Death

Most of the time when Windows 2000 won't boot, the boot process will begin but then abruptly end at the Blue Screen of Death. When you get a Blue Screen of Death, it's often tempting to ignore the hieroglyphics on this screen and move on to the process of trying to boot the system into Safe Mode. As you may recall, when I discussed Safe Mode earlier, I said that you could go through Device Manager and start disabling devices. As you saw, the process of disabling all the devices and reenabling them one by one is tedious. You may not really want to go through this process, but you may not have a clue as to the cause of the problem. However, the Blue Screen of Death may contain the answers you need.

The section at the top of the Blue Screen of Death is known as the bug check section. You can see a sample of this section here bellow:

   *** Stop: 0x0000001E (0xF24A447A, 0X00000001, 0X0000000)
   KMODE_EXCEPTION_NOT_HANDLED
   *** Address F24A447A base at f24A0000, DateStamp 35825ef8d - wdmaud.sys

All of the information in the bug check section means something. The first thing you'll want to look at is the message portion of the section. In this particular case, the message section reads: KMODE_EXCEPTION_NOT_HANDLED

The other section that's important to look at is the bottom line. Many times (but not always), this line provides the memory address and the file that caused the error. You can use this information to determine the cause of the problem. For example, if the filename in the Blue Screen error is TCPIP.sys, then this is a good indication that the problem may lie with your network card or the Windows 2000 network drivers. Rather than disabling every device in the Windows 2000 Device Manager, you can simply disable the network card to see if that solves the problem. If that doesn't take care of things, you might try reinstalling the individual networking components.

Performance Monitor

One final tool that's very useful for tracking down hardware problems is Performance Monitor. Performance Monitor allows you to see exactly how individual hardware components are working. You can use Performance Monitor to tell whether a component is failing or if it's just overwhelmed with work. For example, if your network connection wasn't working correctly, you could use Performance Monitor to see if any traffic was flowing through the network card, if the card was generating network errors, or if the card was generating an excessive number or retries.

Conclusion

In this article, I've explained that although Windows 2000 provides you with a wide variety of diagnostic tools, no one tool is able to diagnose every hardware problem. I've also explained some techniques you can use to diagnose hardware problems and get your machine back online.

The Security Configuration and Analysis Snap-in is part of Windows 2000’s Security Configuration Tool Set. The Security Configuration and Analysis Snap-in compares the current security settings on your server against ones specified by security templates. Microsoft includes a set of basic security templates with Windows 2000. These templates include:

• Basicdc.inf: Default domain controller security
• Basicsv.inf: Default server security
• Basicwk.inf: Default workstation security
• Compatws.inf: Compatible workstation or server security (This setting doesn’t apply to servers. It just allows you to customize security for Windows 2000 Professional workstations to allow users flexibility when running applications.)
• Hisecdc.inf: Highly secure domain controller
• Hisecws.inf: Highly secure workstation or server
• Notssid.inf: A security template that removes unnecessary Terminal Server SIDs from a server’s file system and registry
• Ocfiless.inf: Security templates for optional components on servers, such as Terminal Server
• Ocfilessw.inf: Security templates for optional components on workstations
• Securedc.inf: Secure domain controller settings
• Securews.inf: Secure workstation or server security
• Setup Security: The default security settings applied during installation of Windows 2000

As you can see, except for the oddball templates like Notssid.inf and Oc*.inf, the templates are broken down into three major categories: Basic, Hisec, and Secure. Most templates are further divided into ws, sv, and dc subcategories. These subcategories contain security settings specific to workstations, servers, or domain controllers, respectively. In situations where there are only ws or dc choices, stand-alone servers can use the ws templates.

Basic templates provide minimal security and are good for reversing other security templates that you apply. If you overly secure your server, you can use the basic server or DC templates to undo all of those settings and revert your server to a lower security level. Basic settings apply to all areas of server security except for user rights.

Secure templates, Securews.inf and Securedc.inf, increase basic security for your server. These templates modify everything except for file, folder, and registry key security. These are not modified because file system and registry permissions are configured securely by default. If you apply secure settings to your server, you can force your server to use the NTLM authentication protocol, blocking access from workstations that only use LAN Manager requests, such as OS/2 or Windows 9x workstations. Workstations will only be allowed to log on if they run Windows NT with Service Pack 4 or later.

Secure templates increase security by blocking users from untrusted domains from accessing information about the network. Finally, the secure templates also enable Server Message Block (SMB) signing, which causes servers to reject SMB requests from unsigned clients and prevents hackers from spoofing SMB requests.

The highly secure templates, Hisecws.inf and Hisecdc.inf, define maximum-security settings for your Windows 2000 network. Servers configured with a highly secure template can only communicate with other Windows 2000 computers. That’s because servers using the high security templates refuse requests from both LAN Manager and NTLM workstations, which includes requests from older operating systems, as well as SMB clients like Linux and OS/2.

Secure templates enable server-side SMB packet signing, but servers running high security templates require it. Servers using the high security templates require 128-bit encryption and signing for domain-to-member and domain-to-domain trust relationships.

After you configure your server to run high security, your server will reject requests from Lightweight Directory Access Protocol (LDAP) clients that attempt to access Active Directory unless the client and server have negotiated data signing in advance. That means that your LDAP clients must be using Transport Layer Security\Secure Sockets Layer (TLS/SSL) in order to make the connection.

High security templates limit the use of cached logon data. This includes such things as user ID and passwords stored by Winlogon and Stored User Names and Passwords. While this forces users to type information more often, it prevents hackers from locating this information in the caches and using it later.

Another thing high security templates do is remove all members from the Power Users group. Microsoft does this because it assumes that if you’re running in a high-security environment, you’re only using Windows 2000 certified applications. These applications have security built in and integrate better with Active Directory, eliminating the need for the Power Users group. Members of the Power Users group are assumed to be savvier when it comes to running applications, so by eliminating programs that can cause problems, you can then remove an otherwise useless group.

Creating the Security Configuration and Analysis MMC

You won’t find the Security Configuration and Analysis Snap-in on your server’s Administrative Tools menu. You’ll need to start by creating a custom Microsoft Management Console (MMC) to run it. To do so, click Start | Run. When the Run dialog box appears, type mmc /a in the Open field and click OK. You’ll then see an empty MMC window appear.

Next, select Add/Remove Snap-in from the Console menu. When the Add/Remove Snap-in window appears, click Add. This will display the Add Standalone Snap-in dialog box. Scroll through the Available Standalone Snap-ins list box until you see Security Configuration And Analysis. Select this snap-in and click Add. Then, click Close to close the Add Standalone Snap-in dialog box. Click OK to close the Add/Remove Snap-in Window.

You’ll now notice the Security Configuration And Analysis choice in the Console Root tree in the left pane of the MMC. Before you start to use the Security Configuration and Analysis Snap-In, you should save the MMC you just created. This will save you the effort of having to jump through all of the previous instructions in the future.

To save the MMC, select Save As from the Console menu. When the Save As window appears, type Security Analysis on the Filename field and click Save. In the future, you’ll then be able to start the Security Configuration and Analysis Snap-in by clicking Start | Programs | Administrative Tools | Security Analysis.

Analyzing your security

Now that you’ve got the snap-in loaded, you can use it to analyze your system’s security. Start by opening a database that contains your server’s security information. To do so, right-click Security Configuration And Analysis in the left pane and select Open Database. When the Open Database window appears, you’ll see a list of the security databases on your server. If you don’t see one, don’t panic. That just means you haven’t created one yet.

To create a database, type the name of the database in the Filename field and click Open. To make it easier to find in the future, you may want to give the database the same name as your server.

Next, you’ll see the Import Template menu. In the Template list box, you’ll see a list of security templates. You’ll select one of these templates as the baseline to compare your server’s current security configuration against. Select a template and click Open.

After the template loads, you can analyze your server by right-clicking Security Configuration and Analysis and selecting Analyze Computer Now. When you do, you’ll see the Perform Analysis dialog box. This box asks you to enter a filename to store logging information during the analysis. Security Configuration and Analysis will give you a default log name equal to the name of the database you entered above with a .LOG extension. Click OK to accept the name of the log.

You’ll then see the Analyze System Security screen. This will quickly compare your server’s security with settings in the template you’ve chosen. The amount of time this takes will vary depending on the speed of your server, but it shouldn’t take long.

When it completes, you’ll see the list of policies appear in the right pane of the Security Configuration and Analysis MMC. You can now click on each entry to see how your server’s security compares with the baseline template you’ve chosen.

If you double-check a policy in the right pane, you’ll see all of the settings and how they compare, as shown in Figure A. The right pane is broken into three columns: Policy, Database Setting, and Computer Setting. The Database Setting column shows the setting recommended by the template while the Computer Setting column shows the current settings on the server.

Figure A (Click here to view the image.)
The Security Configuration and Analysis MMC checks your security against a predefined template.

As you can see on this example, some Policy icons appear with little red Xs while others appear with little checkmarks. Policies with red Xs conflict with those specified in the template. Checked policies meet or exceed those in the template. If the icon doesn’t have a check or X, then the policy doesn’t have a corresponding setting in the template and wasn’t analyzed.

It may take some time, but you should go through all of the sections in the Security Configuration and Analysis MMC and double-check to see how your server rated against the defaults. At this point, you have a choice. You can either use the analysis provided by the Security Configuration and Analysis MMC as information only or you can change your server’s settings to match those suggested by the MMC. If you just want to use the tool for information purposes, make notes of the differences and quit the Security Configuration and Analysis MMC.

Beefing up your security

You can use the Security Configuration and Analysis MMC’s suggestions to adjust the security of your server, as well as just perform analysis. To do so, start by going through the suggestions made by the analysis one by one. If the suggested change looks OK, you don’t have to do anything. Just check the next suggestion. If you don’t agree with a comparison that the template makes with your server, you can fix it by double-clicking the policy in question.

This will cause a Settings dialog box to appear. If you completely disagree with the suggested change and don’t want it to apply to your server, deselect the Define This Policy In The Database check box and click OK. This will cause the Database Setting column to change from whatever the suggested value was to Not Defined.

If you want to accept the change but don’t want to use the precise value, you can change it. When you double-click the policy and cause the Settings window to appear, just change the value of the setting from the default and click OK. This will cause the new setting to appear in the Database setting column.

If you’ve made significant changes to the template, you may want to save your template for future use or use on other servers. To do so, right-click Security Configuration And Analysis and select Export Template. Give your new template a name and click Save.

After you’ve double-checked the suggested changes, you can apply them to the local machine by right-clicking Security Configuration And Analysis and selecting Configure Computer Now. You’ll then see a Configure System dialog box appear. Here you’ll enter the name of the log file you want to use to record any errors that may occur when the reconfiguration occurs. Click OK to start the reconfiguration.

The Configure System screen will then quickly appear. It looks much like the Analyze System screen you saw earlier as it checks off its progress. When the configuration completes, you should reanalyze your system to make sure that all of the settings applied correctly. When everything checks out, you can close the Security Configuration and Analysis MMC.

Using the Security Configuration and Analysis MMC sets the policy locally, but it won’t change the settings specified by Active Directory. You can apply the settings networkwide by creating a group policy that applies to all servers and workstations on your network. This will allow you to centrally locate the setting in Active Directory. When servers connect to Active Directory, they’ll pick up the security settings. To do so, you’ll edit the Security Settings for a group policy using the Group Policy Editor. Navigate to Security Settings in the Group Policy Editor, right-click it, and select Import Policy. Then select the policy you created above. Finally, make sure that the group policy applies to all of your servers.

Conclusion

Windows 2000 has so many security settings that it’s hard to keep them all straight. Fortunately, the Security Configuration and Analysis MMC can help you compare your system against baselines and adjust settings accordingly. Using it on all of the servers and workstations on your network can help enforce security networkwide.

Group policies aren’t stand-alone entities. They are made up of a collection of group policy objects (GPOs). Each GPO has the potential to contain hundreds of settings. As you combine the GPOs you create, you develop a group policy that affects your users.

While this may sound simple, most GPOs overlap each other, and there are rules that govern which settings apply when contradictory settings overlap. What further complicates group policies is that some GPOs are directed at the user, some are directed at the computer, and still others are directed at both. Remember that even though you create a user-based GPO, it doesn’t affect every user in the Active Directory tree. You must explicitly associate the GPO with the user for the user to be affected. When you have more than just a couple of GPOs, it can be a real trick to sort them out and figure out which ones apply to which users and computers, as well as what the final outcome of the collective group policy will be. However, the Group Policy Verification tool and the Group Policy Results tool - both parts of the Windows 2000 Server Resource Kit - can help simplify such tasks.

Group Policy Results tool

The Group Policy Results tool displays information about the results of the group policies that have been applied to a logged in user, the computer, or both. The tool is extremely easy to use, and in fact, can be run without any parameters whatsoever.

The tool starts by displaying information such as the OS, the build number, and the mode in which the Terminal Services are running. Next, the tool displays user information such as the login name, Active Directory (AD) location, site name, security privileges, and group memberships. After that, the tool displays some computer-specific information such as the computer’s name, AD location, the domain and type, and the site to which the computer belongs.

Finally, the tool displays a lot of information about the group policy, such as the last time that the policy was applied and the domain controller that applied it. You may also receive information regarding various registry settings, redirected folders, disk quotas, IPSec settings, and information regarding scripts. You can read a sample output here.

This tool is extremely helpful in that it tells you exactly which group policy objects apply to different areas. For example, if you were having trouble with IPSec not working correctly, you could look at the sample output and see that in this particular case, IP security is being regulated by the Default Domain Policy. You could then investigate the Default Domain Policy to make sure you’ve configured it correctly.

There are several options you can use with this tool. Following the GPRESULT command with the /V switch runs the utility in Verbose mode. The /S switch runs the utility in Super Verbose mode. The /C switch tells the utility to display only computer-related information, while the /U switch tells the utility to display only user-related information.

The output from Super Verbose mode would be too long to include in this article, but here you can see an excerpt from the Verbose mode output showing only the group policy-related information, which includes a lot of details.

The Group Policy Verification tool

The other tool to look at how group policies have been applied is the Group Policy Verification tool. This tool allows administrators to check GPO integrity and monitor group policy replication. It reads and compares GPOs on each domain controller within the domain, and by doing so, can tell you if the latest group policy changes have been replicated to the other domain controllers.

This tool can also display detailed information about individual GPOs. In fact, you can even get information, such as functionality versions and extension GUIDs, that you can’t view through the group policy snap-in. This tool can even browse a particular domain controller, search for specified information, and check group policies in another domain.

To view basic information about the group policies within your domain, simply enter the GPOTOOL command from within a command-prompt window. Then, you’ll see a report, such as this one.

As you can see in the report above, the first policy the tool examined generated an error. If this happens to you, you can usually view more information on the error by entering the GPOTOOL command followed by the /VERBOSE switch. In fact, there are several different switches that you can use with this tool, as well, including:

• /GPO:GPO[,GPO…] - This switch allows you to specify a preferred policy, a partial GUID, or a friendly name. If you don’t use this switch, the tool will process all of the policies in the domain.
• /DOMAIN:name - This switch allows you to specify the DNS name for the domain hosting the group policies you want to look at. If you don’t specify a domain name, the tool assumes you want to look at the current domain.
• /DC:DC[,DC…] - This switch allows you to tell the tool which domain controllers you want to look at. If you don’t specify any domain controllers, the tool will look at all of the domain controllers within the specified or current domain.
• /CHECKACL - This switch tells the tool to check the Access Control List on the SYSVOL. By default, the tool skips this step so it can complete tasks faster.

Conclusion

When you start using group policies on your network, you may quickly find out that you’re inadvertently creating policies that conflict with each other. The outcomes of applying group policies may not be what you expected or intended. In such a case, you need to track the results of your applied group policies. Although it can be tough to figure out which GPOs form a user’s individual group policy, the Windows 2000 Server Resource Kit contains tools that make the job easier. Both the Group Policy Results tool and the Group Policy Verification tool can help you gain control over group policies deployed on your network.

The importance of change control and security

Before you start learning about group policies, you need to first understand why you need to learn about group policies and what they provide your organization. As mentioned, group policies target two primary, intertwined issues: change control and security. Change control refers to the ability to control changes to the operating system—whether major or minor—that can have an impact on system stability, functionality, and security. For example, group policies enable you to extend change control over the following:

• Hardware configuration
• Client environment configuration (desktop settings and working environment, logon settings, and so on)
• Operating system options (optional applications and features)
• Applications
• Security settings and policies
• Connectivity and access to network resources

All of these items hold consequences for both workstations and servers—change control is not an issue just for servers. In fact, properly maintained and secured severs can be less susceptible to change given that they are often secured (or should be) behind locked doors. Because they are not isolated from the network, however, servers are just as vulnerable through the network.

Let's take a look at some examples where change control could have saved the day to illustrate how important the issue is for both workstations and servers.

Scenario 1

A bookkeeper who considers herself a power user is constantly tweaking her system. The fax machine is located in another office, and she wants fax capability through her fax modem. So, she enables the fax service and in the process, accidentally changes other settings that prevent her modem from working properly with her key reporting application. Her reporting application program—unfortunately poorly designed—crashes and takes the last month's data with it.

Although the bookkeeper has faithfully backed up each day, an unrelated and unexpected problem with the tape backup system prevents her from restoring the data. Customers are lost, sales are lost, and fines are imposed because of late reporting...all because the user wasn't prevented from making a simple change to the system.

Scenario 2

A junior network administrator is working on Saturday to perform some routine maintenance that includes archiving several folders on the primary server, which hosts the company's Web site and mail, to tape. While the backup is in process, the administrator gets bored and starts exploring the server. He launches the IIS console and without realizing it, stops an auxiliary site that provides support services. Moving on to the Exchange Server console, the administrator does a little more damage, disabling mail for a handful of users—but more importantly, he stops the store, effectively shutting down the mail server.

Clients can't download patches or check the status of support issues until Monday when the services are restored. The support staff is flooded with mail from hot customers who couldn't connect or even send a support request because the mail server was down. The company loses one junior administrator, and their status drops a few notches in the eyes of their customers.

Scenario 3

Over the weekend, the company president of a small publishing company installs some shareware that he downloaded from the Internet onto his notebook. The shareware contains a Trojan horse virus that disables his anti-virus software to prevent its detection.

Monday morning he connects his system to his docking station, and the virus spreads to the network, rapidly infecting all systems and servers and effectively shutting the business down for three days while they bring in outside help to repair the problems. The production staff loses three days, can't complete their projects, and misses several publication deadlines, resulting in lost ad revenue and lost customers.

The moral to these stories

Each of these problems stems from personnel who are poorly trained, careless, or don't follow established procedures. There is still the possibility for accidents, even with the most conscientious and careful users and administrators. Compounding the potential problems, most users don't understand the possible implications of the changes they make. As if that isn't enough, not all organizations develop change control policies, much less enforce them.

Imposing change control would have prevented all of these potentially catastrophic problems. The old adage that an ounce of prevention is worth a pound of cure was never truer. And, these examples illustrate that no one should be above company policies or outside the change control envelope, regardless of their position in the organization.

Understanding your users

To apply change control effectively, you first need to understand your users and the types of tasks they need to perform. With that understanding in mind, you can accommodate their application and operating system needs while still imposing adequate security to protect their systems and the network.

First, classify the users based on the types of tasks they need to perform and the applications they use to accomplish those tasks.

• Knowledge workers: These users are typically more skilled than other users in their respective job areas and might be engineers, accountants, designers, developers, and so on. The fact that they are skilled in a particular area doesn't necessarily equate to computer skill, however. These users typically work from a single computer and work with it most of the day.
• Support staff: These users support the efforts of the business in a task-oriented way. They include data entry clerks, order takers, receptionists, assistants, shipping clerks, and so on. While some work from the same computer all day, others might work with one or more computers. Again, skill level in their area of job responsibility doesn't equate to computer experience or skill level. These users run the gamut from novice to advanced users.
• Technical: These are your system administrators and support staff. They typically work from several systems a day, but each probably has his or her own system, whether workstation or notebook. While they have a much higher computer skill level, they also have a higher risk factor because they typically have more latitude and knowledge to make changes.
• Management: The company president, vice president, and other such executive staff fall into this category. They often work from notebook systems because they are more often on the go, presenting additional risk for introducing applications and changes to the network.

In addition to classifying users by their job area, you should also take a look at the types of systems they use. These include:

• Fixed workstations. These users work from the same workstation all the time and do not need to take their work with them.
• Remote workstations. These users connect to the office network through a dial-up or VPN connection but don't need a notebook because they work from home or the remote office all the time.
• Notebooks and docking stations. These users work both in and out of the office and need to take their systems with them.
• Multiuser workstations. These users move from one workstation to another as needed and often don't have their own user account, but instead use a guest account or whatever account is used to log on to the particular workstation.
• Mobile computers. These users work with a notebook computer without a docking station and typically connect to the network via a dial-up connection or remote office.

Why is an understanding of how each user works and the types of systems they use important to applying change control? Classifying users by their job area will help you begin to develop change policies based on job function, security levels, applications required, and so on, and translate job classifications into domain security groups. Getting a handle on the big picture will help you develop and implement policies that allow users enough latitude to do their jobs effectively and efficiently without exposing their systems and the network to compromise.

If you're working strictly in a workgroup environment without domain security, you can still use this knowledge to plan local security policies for each computer. In addition, understanding the types of systems each user or group uses will help you identify potential security risks associated with specific types of systems.

For example, if most of your workstations are diskless Terminal Services clients without Internet connectivity, you don't have to worry much about users introducing unauthorized applications through download. Systems with modems or direct Internet access, or remote systems over which you have little control, are a different story.

In addition to understanding users' responsibilities and the systems they use, you also need to become familiar with the applications they use. This doesn't mean you need to become an expert at using the application and become capable of answering any question about it (although your users no doubt expect that from you). Instead, you need to understand their applications in the context of how changes that the users are allowed to make can impact those applications, what changes they need to be able to make because of the applications, and how to recover their applications and data if they manage to drive through some loophole you've overlooked.

Finally, make sure you develop an adequate recovery strategy to accommodate problems when they do occur. Perhaps the best way to do this is to plan for the scenario that group policies don't exist, put in place recovery strategies to deal with the possibilities engendered by rampant changes, and then apply change restrictions to prevent all of those possibilities from occurring. In other words, plan for the worst and design for the best.

What to control

Group policies enable you to control a wide range of capabilities and actions. Which ones you address depend on your situation and how they impact your users and systems. The following list summarizes the key issues to address:

• Hardware changes: You can use change control to prevent users from changing existing hardware settings such as display resolution, drive settings, and so on. You can prevent them from changing drivers or installing additional drivers, which helps protect against systems going down because of faulty drivers.
• Application installation and changes: Use change control to prevent users from installing applications or changing existing installations. This helps control problems caused by buggy applications and/or viruses and Trojan horses introduced through shareware or freeware (and not unheard of, but less common with, commercial applications).
• Security needs: Use change control to define whether users can use encryption, IPSec, and other security features. This partly helps keep users out of trouble and helps protect against such situations as a user encrypting his or her documents and then leaving the company after deleting his/her certificates. Although you can recover the encrypted data, it can be a protracted process and at best, an annoyance.
• Network requirements and settings: Prevent users from making changes to their network settings or installing additional network clients or services.
• Access to services: Control users' ability to access and add, remove, change, or control services.
• Local and network resource access: Define the actions that users can take in connecting to and using local and network resources.
• Environment settings: You can employ change control over a wide variety of settings that control the user's working environment including the desktop, mapped drives, printers, and so on. Group policies give you an exceptional level of control over the user's environment and therefore the types of tasks the user can and can't perform.

In addition to the types of change control described above, you'll find that as you become comfortable with group policies they will play an increasingly important role in how you administer your network. You'll use group policies not only to apply change control at the workstation and server level but also to apply granular security and distributed administration to such services as DNS and DHCP, control application installation and deployment, and much more.

Some of the functions and benefits of group policies are easy to see, while others might take you by surprise. For example, you've no doubt surmised by this point that group policies let you enforce change control over a wide variety of items. You can, however, also use group policies to redirect folders, manage Internet Explorer settings, apply logon and logoff scripts, and much more. The following list summarizes key features and functionality offered by group policies:

• Group Policy Object (GPO) can be stored in the Active Directory or defined as a local policy object. In most cases, policies defined at the site, domain, or Organizational Unit (OU) level override local settings.
• GPOs support security, enabling you to assign permissions to each GPO to provide not only change control over the policy object but also delegate administration of GPOs.
• You can use security group membership to apply GPOs, providing an easy way to apply policies across the enterprise while offering simplified administration.
• GPOs provide a high degree over security settings, serving as the primary means by which you apply security policies across Windows 2000 networks.
• GPOs enable you to control Internet Explorer settings to control security zones and other security- and performance-related issues.
• GPOs enable you to apply logon, logoff, startup, and shutdown scripts.
• You can use GPOs for folder redirection, such as defining the user's My Documents folder as being located on a network server for roaming access or to ensure backup of the user's documents.

Conclusion

Before you start defining and implementing group policies, take the time to analyze your network, systems, users, and groups to determine how best to use group policies. Take into account the previous discussion and decide how users should be grouped for the most effective policy application, which groups can accomplish which tasks, what restrictions need to be in place, and so on. You don't need a final picture at this point, just a good overall understanding so you can begin to develop your implementation and application of group policies.

Understanding how different types of permissions interact isn't too difficult, as long as you stick to these basic rules.

Same permission type (either sharing or NTFS)

When working within a certain permission type (sharing or NTFS), permissions are cumulative. The most lenient setting wins for a particular user or group. Deny always overrides Allow and negates any permission with which it conflicts.

Mixing sharing and NTFS permissions

When there's a difference between the sharing permission and the NTFS permission, the most restrictive setting wins.

Permissions across groups

Permissions are not cumulative across groups; each group's permission is calculated separately. For example, if a user is a member of Group A that has Full Control sharing permission but no NTFS permission for an object and of Group B that has Full Control NTFS permission but no sharing permission for the object, that user has no permission for the object.

Examples

Let's look at some examples. Let's say that on John's PC, there is a folder called FOLDER-A containing a file called PRIVATE.DOC. John has shared FOLDER-A with the Marketing group with Change permission and with the Everyone group with Read permission. In the NTFS permissions for the folder, he has allowed for the Marketing group to have only Read access. He has removed the default permissions to the folder for the Everyone group.

If Sarah from Marketing accesses PRIVATE.DOC, will she be able to make changes to it? The Marketing group has Change (for Sharing) and Read (for NTFS), with a net result of Read. The Everyone group has Read (for Sharing) and None (for NTFS), with a net result of None. So Sarah's permissions are the least restrictive of Read and None—in other words, Read. So no, she cannot make changes.

Now, suppose John adds another group to his list of NTFS permissions: Managers. He gives the Managers group Modify access to FOLDER-A. If Sarah is a member of the Managers group, will she now be able to make changes to PRIVATE.DOC? The answer is still no, because even though permissions are cumulative within a type, they are calculated as a whole on each group. As you can see below, the new Managers group has no net permission to the folder because it has no Sharing permission, so it doesn't help Sarah to be able to modify the file.

If John wanted to make sure Sarah had the ability to modify the file, he could :

• Give the Marketing group Modify (or better) permission under NTFS permissions.
• Give the Managers group Change permission under sharing permissions.

Let’s say John takes the first option and changes the Marketing group’s NTFS permission to Modify. Now the chart looks like this:

Now, suppose John uses the NTFS special permissions to deny the Managers group the Write permission. Will Sarah be able to edit the file? No, because the Deny option settings override any Allow settings. Even though the Marketing group still has the rights to edit the file, Sarah is also a member of the Managers group which is specifically denied access.

If John wanted Sarah to be able to change the file but nobody else from the Managers group, he could either remove Sarah from that group or create a separate group containing everyone from Managers except Sarah and deny that group the Write access instead of denying the Managers group.

Practice

The best way to get more confident in your understanding of permissions is to play around with them. Try re-creating the preceding scenario on two client PCs on your network and then experimenting with more "what if" scenarios. For example, what if:

• John turns off Deny Write for Managers and simply deselects the Allow checkbox for the Managers group? Can Sarah then edit the file?
• Sarah then tries to delete the file PRIVATE.DOC? Can she do it with her current permissions?
• John removes all permissions from the folder? Can he still read and modify the file himself?
• Sarah creates a subfolder within FOLDER-A on John's PC? Can John delete it?

Conclusion

In this article, you learned what the rules are when different sets of permissions interact. You also gained some practice in determining net permissions when NTFS and sharing permissions conflict for a user in multiple groups. You now have my permission to set up your network and client machines for the most robust security obtainable in a Windows environment.

Share permissions

The most basic type of permission is a share-level permission. Share permissions have existed in some form since Windows for Workgroups appeared. Basically, share permissions take a file on a hard disk and make it available to other people. If you're using Windows 2000 in a domain environment, you can determine who can have access to a share; in a simple workgroup environment (like Windows 98), however, anyone who has the share password can access the share—regardless of their username. Usually, in a peer-to-peer (or workgroup) environment, access to a shared resource is controlled via multiple passwords. Thus, if users enter one password, they will receive full access to the share, but entering a different password might grant them read-only access to the same share.

To access the share permissions under Windows 2000, right-click on a file or directory that you would like to share. When you see the properties sheet, select the Sharing tab. Now, select the Share This Folder radio button to begin sharing the resource. As you can see in Figure A, you can set the share name to anything you want, and you can add a comment to help you remember the purpose of the share. You also can control how many people are allowed to access the share. Controlling the number of people who may access the share is handy for two reasons. First, if you're sharing a resource off of an older computer, your system may not have enough power to support a large number of users who need to access a share. Your system may be able to support only five users. Second, if you're sharing commercial software, you may have a ten-user license for that product. In this case, you'll want to limit the number of users who can access the share to the number of licenses that you have.

Figure A

Select the Share This Folder radio button to begin sharing the resource.

There are two other buttons on this tab that deserve explanations. First, the Permissions button allows you to control who has access to the share. You can grant access to users and to groups. For example, you might grant a user full control, but you might grant a group read-only access. Unless you're working in a peer-to-peer environment, however, you should always set a share to give everyone full control (assuming that the share resides on an NTFS partition).

The second button that you should know about is the Caching button. Clicking the Caching button displays the Cache Settings dialog box. This dialog box gives you the ability to make the folder available whether the client is connected to the network (and the share) or not. Enable or disable the caching option via the Allow Caching Of Files In This Shared Folder check box. Through the Settings drop-down menu, you can set the caching to Manual Caching For Documents, Automatic Caching For Documents, or Automatic Caching For Programs.

By default, the cache size is 10 percent of the client's free hard disk space. The cached files are stored in a folder called Offline Files. This folder is located in the root directory of a client's hard disk, but you can move it with the Cachemov.exe tool in the Windows 2000 Professional Resource Kit. Of course, the caching only works for clients who are running Windows 2000 Professional. If you want to change the size of the cache, you may do so by going into the Offline Files folder and selecting the Properties command from the folder's File menu.

Web sharing

Web sharing is a new addition to Windows 2000. It allows you to share a file or folder across the Internet. (It also allows you to share a printer across the Internet; thus, someone on the other side of the world would be able to print to your printer.) To share a folder on the Web, you must right-click that folder. Then, select the Properties command from the context menu that appears. When you see the folder's properties sheet, select the Web Sharing tab. By default, the folder is set not to be shared across the Internet, but you can change that setting by selecting the Share This Folder button. Next, you'll see a dialog box similar to the one shown in Figure B. This dialog box requires you to set up an alias, some access permissions, and some application permissions.

Figure B

You must set up an alias and some access and application permissions.

The alias is the name of the folder, as it will appear on the Web. (Obviously, for security reasons, you wouldn't want to include a drive letter or path in the alias.) Next, you must set the access permissions. You can allow read or write access (or both) from across the Web. You also can allow Web clients to access script source or to browse the folder's contents. Just select the appropriate check box if you need that sort of access. Again, due to security concerns, you shouldn't enable any permission across the Web that isn't absolutely necessary. Finally, you must set some application permissions with this dialog box. You may disable applications, allow for the execution of scripts only, or enable all applications, including scripts.

File permissions

The final type of permission in Windows 2000 is file permission. File permissions are the most secure permissions, and they're the preferred permissions for normal operations. File permissions may be applied only to those files and folders that reside on NTFS partitions. The advantage to file permissions is that they work no matter where a user is coming from. File permissions are as effective in protecting resources from users who come in from across the local network as they are in protecting resources from users who come in from across the Web. They even safeguard resources from dial-in users and users who sit down at the server console and attempt to gain access from there.

File permissions have changed drastically since Windows NT 4.0 appeared. To access a folder's file permissions now, you must right-click a folder that resides on an NTFS partition. Then, select the Properties command from the context menu that appears. Next, you'll see the Properties sheet. Select the Security tab, and you'll see the permissions for the folder.

As you can see in Figure C, by default, each folder is set to allow Everyone to have Full Control. You'll also notice that the various check boxes for changing permissions are grayed out. By default, the folder is set to inherit the permissions of its parent folder. Therefore, if a parent folder is set to full control, the folder you see will be set to allow full control, too.

Figure C

By default, Everyone has Full Control on all file permissions.

To get around this problem, simply deselect the Allow Inheritable Permissions From Parent To Propagate To This Object check box. That way, you'll enable all of the other check boxes on the screen. Now, you're free to set your own permissions. You need to keep a few things in mind if you enable the other check boxes. First, a specific denial always overrides an allowance. Second, if the listed permissions don't get the job done (for whatever reason), you can click the Advanced button. Doing so allows you to add or edit users and groups and to apply more extensive permissions. Some of these advanced permissions tend to become very complex, and you probably won't ever have to use them.

When you click the Advanced button, it reveals the Access Control Settings properties sheet for the folder. The Permissions tab is only one section of this properties sheet. You can use the other tabs to implement auditing and to change the folder's owner. (Although these tabs don't relate directly to setting file permissions, I mention them because many people have asked about the location of these two features.)

Best practices

Now that you know about the various types of permissions, I should tell you something about the preferred method of using them. File permissions are cumulative with Web sharing and share permissions; if you set one set of permissions for a user at the share level and a different set of permissions for a group at the file level, the permissions will combine in an effort to determine which access level to give to a user for a particular directory. If you use both types of permissions, things can become very confusing. It can become difficult to troubleshoot problems relating to why a user can't access a specific resource or why another user has too much access to certain resources. To get around these difficulties, you should never restrict share permissions—unless you're working with a non-NTFS partition in which file permissions won't work. Instead, leave the share permissions wide open and set all permissions at the file level.

File permissions are also cumulative. For example, if a group has permission to access a folder and a user who's a member of the group also has permission to access the same folder, the group permissions and the user permissions will combine to determine the user's access level to the folder. Therefore, I recommend that you never give access to individual users. Instead, grant (or deny) file-level permissions to groups and make the user a member of the desired group. If you do so, you'll avoid a lot of confusion.

In a Windows NT environment, each domain is completely independent of other domains. This means that if a user in one domain needs to access a network resource found in another domain, a trust relationship must be established that allows the domain containing the resource to recognize the domain that contains the user.

A trust relationship is essentially a way of telling domain A that it’s safe to trust users from domain B. However, domain A’s administrator must still manually grant access to resources. Simply telling domain A to trust domain B doesn’t magically give the users in domain B full access to everything. Instead, it simply adds the users in domain B to the users that domain A’s administrator can assign permissions to. This is an example of a one-way trust: Domain A trusts domain B.

However, Windows NT also supports a two-way trust in which both domains trust each other. In this particular case, domain A trusts domain B, and domain B trusts domain A. Since each trust relationship in Windows NT must be specifically assigned, things can get a little confusing when establishing trust relationships between more than two domains.

In Windows NT, each trust must be specifically assigned. For example, if you wanted to create a full trust between domains A, B, and C, you’d have to make domain A trust domains B and C, domain B trust domains A and C, and domain C trust domains A and B. That’s six separate trust relationships. You can imagine how difficult it can be to maintain trust relationships in really big Windows NT organizations with a lot of domains.

Windows 2000 trusts

One of the biggest differences between Windows NT and Windows 2000 is the presence of Active Directory (AD). Every domain in the entire organization uses some AD components, such as the schema master and the global catalog. For Windows 2000 to make this exchange possible, it needs some sort of trust relationship in place.

Windows 2000 allows you to create parent and child domains where one domain falls beneath another domain in the domain tree hierarchy. With parent and child domains, the DNS name of the child domain in some way reflects the name of the parent domain. For example, suppose that you had a parent domain named posey.com. Any child domains that fell beneath posey.com would contain posey.com within its DNS name. You could have a child domain named talainia.posey.com or brien.posey.com. Any time you create a child domain, Windows 2000 automatically creates a two-way trust relationship in which the parent trusts the child and the child trusts the parent.

Now, suppose for a moment that the domains posey.com, talainia.posey.com, and brien.posey.com actually existed. Talainia.posey.com would fully trust brien.posey.com and vice versa. Windows 2000 doesn’t explicitly create this trust relationship automatically, and you don’t have to create it either. Instead, the trust relationship between these domains is established via transitive trusts.

A transitive trust is an arrangement where if domain A trusts domain B, and domain B trusts domain C, then domain A will automatically trust domain C. Although no explicit trust relationship between the two parallel domains has been assigned, a full two-way trust exists because of transitive trusts. Windows NT didn't offer transitive trusts, but they are offered in Windows 2000.

Trusts between unrelated domains

To see how trusts work in an environment that contains parallel domains that aren’t involved in a parent/child relationship of any kind, let's look at my network. It contains two domains, posey.com and bud.com. As you can tell by their DNS names, although these domains belong to the same forest—an absolute requirement for any type of trust relationship—they are otherwise unrelated.

Because these two domains are unrelated, they function as totally separate entities from a user standpoint. Sure, they still share a common AD, but no trusts exist. So an administrator in posey.com wouldn’t be able to assign any sort of permissions to allow a user from the bud.com domain to access domain resources. The reverse is also true.

If I wanted to build a trust between these two domains, I would have to do so through AD. The two domains are a part of the same AD and are therefore already sharing some information, so to complete the trusting process, you need only to make an entry into AD indicating it’s okay to implement a normal trust relationship between the two domains.

Figure A

To establish a trust between two unrelated domains within the same forest, select Programs | Administrative Tools | Active Directory Domains And Trusts from the Start menu. When you do, Windows will open the Active Directory Domains And Trusts console. This console displays all of the top-level domains in a format that can be expanded to display any child domains beneath them, as shown in Figure A.

To create a trust relationship, right-click one of the domains and select Properties to view the domain’s properties sheet, and then select the Trusts tab.

Figure B

As you can see in Figure B, the Trusts tab contains two mail sections, the Domains Trusted By This Domain section and the Domains That Trust This Domain section.

The first section indicates that administrators in the present domain—in this case posey.com—will be able to assign permissions to domain resources to users from the foreign domain, bud.com. The second section indicates that the local domain, posey.com, is being trusted by the remote domain, bud.com. As you can see in the figure, both sections contain the bud.com domain. You’ll also notice that the Domains That Trust This Domain section contains an Add, an Edit, and a Remove button. It may seem strange that you can add a remote domain to the list of domains that trust the local domain. However, you’re not actually controlling the security of a remote domain. Instead, you’re establishing one half of the trust relationship.

For example, imagine you work in a very high-security environment. You wouldn’t want the administrator of one domain to start allowing users in another domain to access resources without someone knowing he or she has done so. So as a security precaution, Windows 2000 requires that when a trust relationship is established, both domains' administrators must be involved in the process. If you wanted to establish a one-way trust relationship in which the domain posey.com trusted the domain bud.com, an administrator from posey.com would add bud.com to the list of trusted domains. Then, to complete the process, an administrator from bud.com would have to add posey.com to the list of domains that trust this domain. In a two-way trust, each administrator would have to add the name of the remote domain to both the Domains Trusted By This Domain section and to the Domains That Trust This Domain section.

Another security feature built in to trust relationships is that any time you create a trust relationship, you must enter a password. When you specify a trusted domain, you must enter the administrative password for that domain. Likewise, when you are about to permit a remote domain to trust your domain, you must enter the remote domain’s password. This process ensures that administrators in both domains have full knowledge and final approval before any trust relationships are established.

Also, when you create a new trust, you can either enable transitive trusts or disable them. When you think about it, just because you want someone to trust your domain doesn’t necessarily mean you also want that domain to trust every domain that trusts you or every domain that you trust. Likewise, if you’re about to trust a remote domain, you don’t really know which other domains the administrator of that domain trusts or which domains trust that domain. For added security, a nontransitive, regular trust relationship may be the way to go.

Also, once you’ve created a trust, it might take anywhere from 15 minutes to an hour for the trust to become active. In the meantime, you can verify a trust by selecting the trust, clicking the Edit button, and then clicking Verify. In my experience, if you have one domain running in native mode and one domain running in mixed mode, the trust will sometimes fail to verify, even though it may be working correctly. The real test of a trust is to see if you can access the user list from the remote domain.

Conclusion

While it’s still sometimes necessary to implement trust relationships between Windows 2000 domains, the rules for doing so differ considerably from those in Windows NT. If you're a Windows NT administrator who's moving to a Windows 2000 environment, this guide to the new concepts and tools to make trusts work should put you on the right track. Then, you can make sure your users can access resources across your network no matter which domain they’re in.

NTFS version 5

Before I get started explaining how disk quotas work, I should point out that disk quotas may be applied only to NTFS partitions. However, the Windows 2000 version of NTFS is different from the version that's included in Windows NT. The version of NTFS that comes with Windows NT supports features like file-level permissions but doesn't offer features such as file-level encryption or disk quotas. Fortunately, you don't have to worry about upgrading the NTFS file system, because when you install Windows 2000, Setup automatically performs an NTFS upgrade.

These differences really matter when you're dual-booting Windows 2000 with another operating system. Chances are, you'd probably never dual-boot Windows 2000 Server, but since Windows 2000 Professional also supports disk quotas, the point seems worth mentioning. Basically, the way that things work is if you upgrade a FAT or FAT 32 partition to NTFS so that you can use disk quotas, the other operating system you'll be dual-booting against won't be able to access the newly converted partition. The only exception to this is if the other operating system is Windows NT. Windows NT can interact with Windows 2000 partitions as long as it's running Service Pack 4 or later.

The rules of the game

By now, you know that in a Windows 2000 environment, an administrator can limit a user's hard disk consumption as long as a partition uses NTFS. However, there are some limits to the process of implementing disk quotas. Perhaps the biggest limitation is that the disk quotas must be applied on a per-partition basis. Unfortunately, there's no way to enforce a total amount of disk space that a user is allowed to consume on a per-server, per-site, or per-organization basis. Therefore, you may find yourself implementing a separate set of disk quotas for every server-based partition in your entire organization.

Enabling disk quotas

Now that you have a basic understanding of how disk quotas work, let's examine the process of implementing disk quotas. To implement a disk quota, select Programs | Administrative Tools | Computer Management from the Start menu. When the Computer Management console loads, navigate through the console tree to Computer Management (Local) | Storage | Disk Management. When you do, Windows will display a summary of all of the hard disks that are installed in your system, as shown in Figure A.

Figure A
You can use the Computer Management console to gain access to all of the system's hard disks.

At this point, right-click the partition that you want to work with and select the Properties command from the resulting context menu. You'll then see the partition's Properties sheet. Select the Properties sheet's Quota tab. The disk quotas are disabled by default, but you can enable them from this tab.

Figure B

The disk quotas, which are disabled by default, can be enabled here.

To enable disk quotas, select the Enable Quota Management check box, as shown in Figure B. Keep in mind that doing so enables quota management only for this partition. Other partitions must have quota management enabled separately. Once you've enabled quota management, decide how you want Windows 2000 to regulate the disk quotas.

One option that you can use is selecting the Deny Disk Space To Users Exceeding Quota Limit. By setting this option, you make it impossible for users to save files to partitions in which they have met their limit. However, you may not always want to use this option because not being able to save files could have a negative impact on a user's ability to do his or her job.

Beneath the Deny Disk Space To Users Exceeding Quota Limit check box, you'll see a section that allows you to set the default quota limits. Keep in mind that the limits that you set here have absolutely no effect on existing users. They affect only user accounts that are created after the quotas are enabled. In this section, you can either tell Windows to not limit disk usage, or you can set some limitations.

Windows allows you not only to set the maximum amount of hard disk space a user can consume on a partition but also to set a warning threshold. For example, if you were to limit each user to 100 MB of space, you might set the warning threshold to 90 MB. By doing so, Windows would generate a warning message for users when they exceeded the 90-MB limit.

Simply setting a disk space limit alone, however, won't prevent users from saving files when they've used too much space. It merely provides the administrator with an easy method for checking to see who has exceeded a preset threshold. In fact, you can actually see which users are hogging all of the disk space by enabling quota logging. The Quota tab contains two check boxes that you can use to generate a log entry whenever a user surpasses his or her warning level or quota level.

Applying quotas to users

Whenever you enable quotas, the limits that you set apply only to new user accounts. Therefore, it's necessary to manually apply the quotas to the existing user accounts. At first, you may assume that you had set quota limits to user accounts by going through the Active Directory Users And Computers console. Keep in mind, though, that properties that you apply to Active Directory users are valid for the entire domain, and quotas are applied on a per-partition basis. Therefore, you must set the quota limits from the computer for which you're establishing quotas.

To do so, return to the partition's Properties sheet and select the Quota tab. Now, click the Quota Entries button. When you do, you'll see a screen similar to the one shown in Figure C. This screen contains a list of all of the quotas in effect for the partition, as well as a summary of who is above the limit and how much disk space that each user is actually consuming. This screen brings up an interesting point: Simply enabling quotas doesn't guarantee that you won't run out of hard disk space. In Figure C, I've given each user a 100-MB disk space limit. However, the entire volume is only 16 MB. As you can see, the hard disk would fill up long before any of the quotas that I've set were reached. It's also possible for applications to fill up the hard disk by creating log files or temp files.

Figure C (Click here to view the imge)
The Quota Entries For Local Disk (C:) window allows you to see a summary of existing quotas.

Keep in mind that in Figure C, you see several user accounts listed. However, all of these user accounts except for the BUILTIN\Administrators account were added manually. The BUILTIN\Administrators account is placed in the list automatically. By default, this account is set to not have any limits. You can enable a warning threshold for the administrators, but you can't impose a disk space limit. This is Windows 2000's way of making sure that disk quotas don't hinder administrative chores. It is possible to set a disk quota for the administrator, but you'll have to manually add the administrator to the list to do so.

Unfortunately, you can apply disk quotas only to individual user accounts. You can't apply disk quotas to groups. If this seems strange, keep in mind that it's possible for a user to belong to more than one group, and in such a case, Windows wouldn't have any way of knowing which group's limits should be enforced. Applying quotas directly to individual user accounts, however, isn't as bad as it sounds.

Even though you can't apply disk quotas directly to groups, you can apply them to multiple users simultaneously. To do so, select the New Quota Entry command from the Quota menu. When you do, you'll see the Select Users dialog box. This dialog box displays a list of the users within a given domain. You can select either a single user or multiple users from this list. Once you've selected a group of users, click OK. When you do, you'll see the Add New Quota Entry dialog box. This dialog box allows you to specify the limit and warning thresholds for the users that you've selected.

As you can see, being able to select multiple users greatly expedites the process of applying disk quotas. However, there is an even better shortcut to the process. As I've mentioned, you have to apply disk quotas to each individual partition on each different server. To make this process easier, you can set up the quotas the way that you want them on one server and then export those settings to a file. You can then import the file when configuring other partitions. To do this, simply use the Import and Export commands that are found on the Quota menu.

Disk space reporting

The biggest reason for using disk space quotas may be to prevent users from consuming all of your hard disk space; however, when disk space starts getting low on a server, it's almost as important to know who is consuming the most space. Fortunately, there are several ways of acquiring this information.

You probably noticed in Figure C that the Quota Entries For Local Disk (C:) screen displays how much space each user is using and who is over the limit or above the warning level. However, you can make this screen even more useful. By clicking on a column heading, you can make Windows 2000 sort the list by that column. For example, if you were to click on the Amount Used column, the users would be sorted by who's using the most and least amount of disk space. You can also sort the list based on the Status column so that you can see who's over the limits that you've set.

If you prefer a more conventional method of reporting, simply select the users that you'd like to include in the report and drag them into an empty Excel spreadsheet. Windows will automatically create a spreadsheet that even includes a title and the column headings.

Conclusion

For years, Windows NT users have had free reign to store files on your system. They could completely fill up your server's hard drives and there was little you could do to stop it. I hope that this article has given you the information you need to put the control over disk quotas where it belongs: in the administrator's hands.