Administrators can administer a Windows Server 2003 infrastructure by learning only a few simple tasks and applying them at different levels and to different objects. The overall management of an environment is composed of administrative tasks that touch almost every aspect of the network, including user administration, server and workstation administration, and network administration. For example, in a single day an administrator might check for a successful server backup, reset a user’s password, add users to or remove them from existing groups, or manage LAN and WAN hardware. Although each of these tasks can independently be very simple or difficult in nature, administrators should at least understand their portion of the overall enterprise network and understand how the different components that make up the network communicate and rely on one another.
This chapter focuses on the common Windows Server 2003 Active Directory (AD) user and group administrative tasks and touches on the management of Active Directory sites to optimize user access and replication performance.
Before the computer and networking environment can be managed effectively, an organization and its IT group must first define how the tasks will be assigned and managed. The job of delegating responsibility for the network defines the organization’s administrative model. Three different types of administrative models—centralized, distributed, and mixed—can be used to logically break up the management of the enterprise network between several IT specialists or departments within the organization’s IT division. When there is no administrative model, the environment is managed chaotically, and the bulk of work is usually made up of fire-fighting. Server updates and modifications must more frequently be performed on the spot without proper testing. Also, when administrative or maintenance tasks are not performed correctly or consistently, securing the environment and auditing administrative events are nearly impossible. Environments that do not follow an administrative model are administered reactively rather than proactively.
To choose or define the correct administrative model, the organization must discover what services are needed in each location and where the administrators with the skills to manage these services are located. Placing administrators in remote offices that require very little IT administration might be a waste of money, but when the small group is composed of VIPs in the company, it might be a good idea to give these elite users the highest level of service available.
The centralized administration model is simple in concept: All the IT-related administration is controlled by one group, usually located at one physical location. In the centralized model, all the critical servers are housed in one or a few locations instead of distributed at each location. This arrangement allows for a central backup and always having the correct IT staff member available when a server fails. For example, if an organization uses the Microsoft Exchange 2003 messaging server and a server is located at each site, a qualified staff member might not be available at each location if data or the entire server must be recovered from backup. In such a scenario, administration would need to be handled remotely if possible, but in a centralized administration model, both the Exchange Server 2003 administrator and the servers would be located in the same location, enabling recovery and administration to be handled as efficiently and effectively as possible.
The distributed administration model is the opposite of the centralized model in that tasks can be divided among IT and non-IT staff members in various locations. The rights to perform administrative tasks can be granted based on geography, department, or job function. Also, administrative control can be granted for a specific network service such as DNS or DHCP. This allows separation of server and workstation administration without giving unqualified administrators the rights to modify network settings or security.
Windows Server 2003 systems allow for granular administrative rights and permissions, giving enterprise administrators more flexibility when assigning tasks to staff members. Distributed administration based only on geographical proximity is commonly found among organizations. After all, if a physical visit to the server, workstation, or network device is needed, having the closest qualified administrator responsible for it might prove more effective.
The mixed administration model is a mix of administrative responsibilities, using both centralized and distributed administration. One example could be that all security policies and standard server configurations are defined from a central site or headquarters, but the implementation and management of servers are defined by physical location, limiting administrators from changing configurations on servers in other locations. Also, the rights to manage only specified user accounts can be granted to provide even more distributed administration on a per-site or per-department basis.
Sites can be different things, depending on whom you ask. Within the scope of Active Directory, a site defines the internal and external replication boundaries and helps users locate the closest servers for authentication and network resource access. If you ask an operations manager, she might describe a site as any physical location from which the organization operates business. This section discusses Active Directory site administration.
AD sites can be configured to match a single or many locations that have high-bandwidth connectivity between them. They can be optimized for replication and, during regular daily operations, require very little network bandwidth. After an AD site is defined, servers and client workstations use the information stored in the site configuration to locate the closest domain controllers, global catalog servers, and distributed file shares. Configuring a site can be a simple task, but if the site topology is not defined correctly, network access speed might suffer because servers and users may connect to resources across the wide area network instead of using local resources. In most cases, defining and setting up an Active Directory site configuration might take only a few hours of work. After initial setup, AD sites rarely need to be modified unless changes are made to network addressing, domain controllers are added to or removed from a site, or new sites are added and old ones are decommissioned.
As mentioned previously, configuring a site should take only a short time because there are very few components to manipulate. A site is made up of a site name; subnets within that site; links and bridges to other sites; site-based policies; and, of course, the servers, workstations, and services provided within that site. Some of the components, such as the servers and workstations, are dynamically configured to a site based on their network configuration. Domain controller services and Distributed File System (DFS) targets are also located within sites by the network configuration of the server on which the resources are hosted.
Subnets define the network boundaries of a site and limit WAN traffic by allowing clients to find local services before searching across a WAN link. Many administrators do not define subnets for locations that do not have local servers; instead, they relate site subnets only to Active Directory domain controller replication. If a user workstation subnet is not defined within Active Directory, the user workstation may authenticate and download policies or run services from a domain controller that is not directly connected to a local area network. This authentication and download across a WAN could create excessive traffic and unacceptable response times.
Site links control Active Directory replication and connect individual sites directly together. A site link is configured for a particular type of protocol—namely, RPC, IP, or SMTP—and the frequency and schedule of replication is configured within the link.
Within Active Directory, server licenses and licensing usage can be tracked by a central server in each site. Using the Active Directory Sites and Services Microsoft Management Console (MMC) snap-in, you can define a particular server as the site-licensing server. All Windows servers, including NT4, Windows 2000, and Windows Server 2003, replicate licenses and licensing usage to this server. The site-licensing servers replicate with one another to enable the enterprise administrator to track licenses for the entire enterprise from the Licensing console on any of the site-licensing servers.
Site group policies allow computer and user configurations and permissions to be defined in one location and applied to all the computers and/or users within the site. Because the scope of a site can span all the domains and domain controllers in a forest, site policies should be used with caution. Therefore, site policies are not commonly used except to define custom network security settings for sites with higher requirements or to delegate administrative rights when administration is performed on a mostly geographic basis.
Note
Because sites are usually defined according to high-bandwidth connectivity, some design best practices should be followed when you’re defining the requirements for a site. If possible, sites should contain local network services such as domain controllers, global catalog servers, DNS servers, DHCP servers, and, if necessary, WINS servers. This way, if network connectivity between sites is disrupted, the local site network will remain functional for authentication, Group Policy, name resolution, and resource lookup. Placing file servers at each site may also make sense unless files are housed centrally for security or backup considerations.
The job of configuring and creating sites belongs to the administrators who manage Active Directory, but those who manage the network must be well informed and possibly involved in the design. Whether Active Directory and the network are handled by the same or different groups, they affect each other, and undesired network utilization or failed network connectivity may result. For example, if the Active Directory administrator defines the entire enterprise as a single site and several Active Directory changes happen each day, replication connections would exist across the enterprise, and replication traffic might be heavy, causing poor network performance for other networking services. On the other side, if the network administrator allows only specific ports to communicate between certain subnets, adding Active Directory might require that additional ports be opened or involve specific network requirements on the servers at each location.
When creating a site, Active Directory and network administrators must decide how often AD will replicate between sites. They also must share certain information such as the line speed between the sites and the IP addresses of the servers that will be replicating. Knowing the line speed helps determine the correct cost of a site link. For the network administrator, knowing which IP addresses to expect network traffic from on certain ports is helpful when troubleshooting or monitoring the network. To create a site, the AD administrator needs a site name and subnet and also needs to know which other sites will replicate to the new site.
To create a site, follow these steps:
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.
Choose Start, Run. Type
MMC.exeand click OK.Choose File, Add/Remove Snap-in.
Click Add in the Add/Remove Snap-in window.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
In the console window, click the plus sign next to Active Directory Sites and Services.
Right-click the Sites container and choose New Site.
Type in the name of the site and select any existing site link, as shown in Figure 19.1. Then click OK to create the site.
A pop-up window might appear, stating what tasks still need to be completed to properly create a site. Read the information, take notes if necessary, and click OK.
After you create a site, it should be listed in the console window. To complete the site creation process, follow these steps:
Within the console window, right-click the Subnets container and choose New Subnet.
Type in the address of the subnet and subnet mask, select the appropriate site from the list at the bottom of the window, and click OK to create the new subnet and associate it with the new site. If you are not sure about the address to enter, just enter the IP address and subnet mask of a device on that network, and the wizard will select the correct network number for you.
If a new domain controller is added to a forest, it will dynamically join a site with a matching subnet if the site topology is already configured and subnets have been previously defined. If an existing domain controller is being moved to a new site or the site topology or replication strategy has changed, you can follow these steps to move a domain controller to a different site:
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.
Click Add in the Add/Remove Snap-in window.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
In the console window, click the plus sign next to Active Directory Sites and Services.
Locate the site that contains the desired domain controller. You can browse the site servers by expanding the Sites container, expanding a site within it, and selecting the Servers container of the site, as shown in Figure 19.2.
When you locate the desired server, take note of the source site, right-click the server name, and choose Move.
When a window opens listing all the sites in the forest, select the destination site and click OK to initiate the server move.
When the move is complete, verify that the domain controller has been placed in the correct Servers container of the desired site.
If necessary, manually create replication connections if the desired connections are not automatically created by the Inter-Site Topology Generator (ISTG) within 15 minutes after moving the server. For information on the ISTG and replication connections, refer to Chapter 7, “Active Directory Infrastructure.”
Within Active Directory, server licensing is replicated to a designated site-licensing server. Each site-licensing server replicates its licensing information to the licensing servers in other sites so that each server has the enterprise licensing information. Licensing replication follows the replication interval set on the individual server from within the Licensing applet in the Control Panel of each server. The first domain controller in a site becomes the site-licensing server.
To change the site-licensing server, follow these steps:
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.
Choose File, Add/Remove Snap-in.
Click Add in the Add/Remove Snap-in window.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
In the console window, click the plus sign next to Active Directory Sites and Services.
Select the desired site in the left pane. Then, in the right pane, right-click Licensing Site Settings and choose Properties, as shown in Figure 19.3.
Within the Licensing Site Settings property page, note the licensing computer at the bottom of the window and, if desired, click the Change button to specify a computer.
In the Select Computer window, type in the name of the desired domain controller and click OK.
Back on the Licensing Site Settings property page, click OK to change the licensing server for the site.
To get proper licensing usage information for the entire enterprise, the administrator must understand how licensing information is replicated. Each server replicates its licensing information to the site-licensing server based on a replication interval set in the Licensing applet located in the Control Panel within the server console. The default is set to 24 hours, so licensing information is replicated to the site-licensing server once a day.
When per-user or per-device client access licenses need to be added to properly track Windows and possibly BackOffice, Exchange, and SMS licenses, the licenses should be added directly on the site-licensing server. This ensures that the licenses show up on the licensing server immediately. Many administrators do not understand licensing, so they either disable the licensing logging service or add licenses several times until they realize that the added licenses show up on the licensing server only after replication.
Site links establish connectivity between domain controllers to allow Active Directory replication to be managed and scheduled. The Active Directory database, global catalog, Group Policies, and domain controller SYSVOL share replicate according to the replication schedule configured in a site link. For more information on site links, refer to Chapter 7.
To create an IP-based site link, follow these steps:
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.
Choose Start, Run. Type
MMC.exeand click OK.Choose File, Add/Remove Snap-in.
Click Add in the Add/Remove Snap-in window.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
In the console window, click the plus sign next to Active Directory Sites and Services.
Expand the Sites container and double-click the Inter-Site Transports container.
Right-click the IP container and select New Site Link.
Enter a name for the site link, select a site that will replicate Active Directory using this site link, and click Add. Repeat this step until all the desired sites are in the right window, as shown in Figure 19.4.
Click OK to create the site link.
Back in the Active Directory Sites and Services console, right-click the new site link in the right pane and choose Properties.
At the top of the window, enter a description for the site link. For example, enter
Site link between site A and site B. Keep the description simple but informative.At the bottom of the window, enter a cost for the site link and enter the replication frequency. This number indicates how often Active Directory will attempt to replicate during the allowed replication schedule.
Click the Change Schedule button to configure specific intervals when Active Directory should not replicate and click OK.
Click OK in the Site Link property page to complete the site link configuration.
After the site link is configured, the Active Directory connections between domain controllers in different sites may generate new connections to optimize replication.
Control is sometimes delegated at the site level to give network administrators the rights to manage Active Directory replication without giving them the rights to manage any additional Active Directory objects. Site delegation can also do just the opposite, effectively denying network administrators the right to access Active Directory objects on a per-site basis. Specific administrative rights can be granted using the built-in Delegate Control Wizard, whereas others can be set for all the site objects using a site’s Group Policies.
To delegate control at the site level, follow these steps:
Log on to a server or a Windows XP workstation with Windows Server 2003 Administration Tools installed. For simplicity, log on with an account that has the rights to create a site; usually, an account with Enterprise Administrator rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services. If the console is missing, proceed to the next step; otherwise, skip to step 7.
Choose File, Add/Remove Snap-in.
Click Add in the Add/Remove Snap-in window.
Select Active Directory Sites and Services from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
In the console window, click the plus sign next to Active Directory Sites and Services.
Right-click the Sites container and select Delegate Control.
Click Next on the Delegate Control Wizard Welcome screen.
Using the Add button, select the user, users, or groups that will delegate control over the site and click Next to continue. You may choose an Active Directory group created for the organization’s networking team or the default group named Network Configuration Operators.
In the Active Directory Object Type page, select This Folder, Existing Objects in This Folder and Creation of New Objects in This Folder, which is the default option to delegate control, and then click Next. The permissions granted will trickle down to each of the containers below the initial Sites container. If you don’t want this outcome, return to step 8 and select the appropriate site or subnet container.
On the Permissions page, check the desired permissions type boxes and choose each permission the administrator or, in this case, the networking group should have.
Click Next and then Finish to complete the Delegate Control Wizard.
An Active Directory group is made up of a collection of objects (users and computers and other groups used to simplify resource access and for emailing purposes). Groups can be used for granting administrative rights, granting access to network resources, or distributing email. There are many flavors of groups, and depending on which mode the domain is running in, certain group functionality might not be available.
Windows Server 2003 Active Directory supports two distinct types of groups: distribution and security. Both have their own particular uses and advantages if they are used properly and their characteristics are understood.
Distribution groups allow for the grouping of contacts, users, or groups primarily for emailing purposes. These types of groups cannot be used for granting or denying access to domain-based resources. Discretionary Access Control Lists (DACLs), which are used to grant or deny access to resources or define user rights, are made up of Access Control Entries (ACEs). Distribution groups are not security enabled and cannot be used within a DACL. In some cases, this might simplify security management when outside vendors need to be located in address books but will never need access to resources in the domain or forest.
Security groups are security enabled and can be used for assigning user rights and resource permissions or for applying computer and Active Directory–based Group Policies. Using a security group instead of individual users simplifies administration. Groups can be created for particular resources or tasks, and when changes are made to the list of users who require access, only the group membership must be modified to reflect the changes throughout each resource that uses this group.
To perform administrative tasks, security groups can be defined for different levels of responsibility. For example, a level 1 server administrator may have the right to reset user passwords and manage workstations, whereas a level 2 administrator may have those permissions plus the right to add or remove objects from a particular organizational unit or domain. The level of granularity granted is immense, so creating a functional security group structure can be one way to simplify administration across the enterprise. Security groups can also be used for emailing purposes, so they can serve a dual purpose.
To complicate the group issue somewhat more, after the type of group is determined, the scope of the group must also be chosen. The scope, simply put, defines the boundaries of who can be a member of the group and where the group can be used. Because only security groups can be used to delegate control or grant resource access, security group types are implied for the rest of this chapter.
Domain local groups can be used to assign permissions to perform domain-based administrative tasks and to access resources hosted on domain controllers. These groups can contain members from any domain in the forest and can also contain other groups as members. Domain local groups can be assigned permissions only in the domain in which they are hosted.
Global groups are somewhat more functional than domain local groups. These groups can contain members only from the domain in which they are hosted, but they can be assigned permissions to resources or delegated control to perform administrative tasks or manage services across multiple domains when the proper domain trusts are in place.
Universal groups can contain users, groups, contacts, or computers from any domain in the forest. This simplifies the need to have single-domain groups that have members in multiple forests. Universal group memberships should be kept low or should not be changed frequently because group membership is replicated across domains and populated in the global catalog. As a best practice, create a universal group to span domains but have only a global group from each domain as a member. This practice reduces cross-domain replication.
Note
Universal security groups can be created only in domains running in Windows 2000 Native or Windows Server 2003 domain functionality level. If this level cannot be reached, use global groups from each domain when setting permissions on resources that need to be accessed from users in many domains.
When it comes to creating groups, understanding the characteristics and limitations of each different type and scope is only half the battle. Other points to consider for group creation are how the group will be used and who will need to be a member of the group. A group is commonly used for three separate functions, including delegating administrative rights, distributing email, and securing network resources such as file shares and printer devices. To help clarify group usage, the following examples show how the different groups can be used in different administrative scenarios.
If a group is needed to simplify the process of granting rights to reset user passwords in a single domain, either a domain local or global security group would suffice. The actual domain user rights should have local groups applied only to their access control lists or settings, but these local groups should have global groups as members. For a single-domain model, if the specific user rights need to be granted only at the domain level, a domain local group with users as members would be fine. However, if you need to add the same group of users to an access control list on a member server resource or you need to create a completely new domain, the domain local group cannot be used. This is the main reason it is recommended to place users only into global groups and assign permissions to resources using local groups that have global groups as members. After you use this strategy and use global groups over and over, saving administration time, the reasoning will be validated.
When multiple domains need to be supported by the same IT staff, even if the domain levels are set to Windows 2000 Mixed mode, each domain’s Domain Admins group should be added to each domain’s Administrators group. For example, domain A’s Administrators group would have Domain A Domain Admins, Domain B Domain Admins, and Domain C Domain Admins groups as members. You would need to add these domains whenever a resource or administrative task needs to grant or deny groups from each domain access to a resource in the forest.
If all the domains in the forest run in Windows 2000 Native or Windows Server 2003 Native Domain functional level, you could create a Universal security group named Forest Admins with each of the domain’s Domain Admin groups as members. Then you would need to configure only a single entry to allow all the administrators access forest-wide for a particular resource or user right. Universal security groups are useful because they can have members from each domain, but if a proper group strategy has been developed, domain local and domain global groups could still handle most situations.
There are many different domain functionality levels, with each level adding more functionality. The reason for all the different levels is to provide backward compatibility to support domain controllers running on different platforms. This allows a phased migration of the domain controllers. The four main domain functionality levels are
Windows 2000 Mixed—. This domain level mode was created primarily to allow both Windows 2000 and Windows NT 4.0 domain controllers to function in an Active Directory domain. Universal security groups and any group nesting other than nesting global groups into local groups are not options. This level can be raised to Windows 2000 Native or Windows Server 2003 Native after all the domain controllers are upgraded to the necessary operating system levels.
Windows 2000 Native—. This domain level allows only Windows 2000 and Windows Server 2003 domain controllers in the domain. Universal security groups can be leveraged, along with universal and global security group nesting. This level can be raised to Windows Server 2003 Native level. This mode also allows you to change some existing groups’ scope and type on the fly.
Windows Server 2003 Native—. This level allows only Windows Server 2003 domain controllers and provides all the features of the Windows 2000 Native domain level, plus additional security and functionality features such as domain rename.
Windows Server 2003 Interim—. Windows Server 2003 Interim mode enables the Windows Server 2003 Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers and Windows Server 2003 domain controllers only. This level was created to support environments that seek to upgrade directly from NT 4.0 to Windows Server 2003 Active Directory. This domain level can be raised only to Windows Server 2003 Native domain level. This mode is listed only if an NT 4.0 domain PDC has been upgraded to a Windows Server 2003 domain controller.
Now that you understand what kinds of groups you can create and what they can be used for, you are ready to create a group. To do so, follow these steps:
Log on to a domain controller using an account with the rights to create groups in the respective domain. Usually, an account with Domain Admin rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers.
Select a container in the left pane; for example, the Users container. Right-click it and select New, Group.
Enter the group name and select the appropriate group type and scope, as shown in Figure 19.5. Click OK to finish creating the group.
After you create a group, you can add members to it. The domain level that the domain is running in will determine whether this group can have other groups as members.
To add members to an existing group, follow these steps:
Log on to a domain controller using an account with the rights to create groups in the respective domain. Usually, an account with Domain Admin rights will suffice.
Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers.
Select the container that contains the group you want in the left pane. Then, in the right pane, right-click the group and select Properties.
Enter a description for the group on the General tab and then click the Members tab.
Click Add to add members to the group.
In the Select Users, Contacts, Computers or Groups window, type in the name of each group member separated by a semicolon and click OK to add these users to the group. If you don’t know the names, clicking the Advanced button opens a window where you can perform a search to locate the desired members.
When all the members are listed on the Members tab of the group’s property page, click OK to complete the operation.
After a group is created, it needs to be managed by an administrator, users, or a combination of both, depending on the dynamics of the group. For example, when Exchange Server 2003 is being leveraged in an Active Directory environment, administrative assistants commonly need to modify certain mailing group memberships. For this particular example, if the proper permissions on the group are defined, an administrative assistant would be able to manage group membership using her Outlook client. If group membership needed to be managed outside Outlook, the administrative assistant would need the Windows Server 2003 Administration Pack installed on the workstation.
To delegate control of a group to a particular user, follow these steps:
Log on to a domain controller with Domain Administrator privileges.
Choose Start, All Programs, Administrative Tools, Active Directory Users and Computers.
Select the container that contains the group you want in the left pane. Then, in the right pane, right-click the group and select Properties.
Select the Security tab. If the Security tab is not visible, close the group, and in the Active Directory Users and Computers MMC snap-in, select View, Advanced Features. Open the properties of the desired group and select the Security tab afterward.
On the bottom of the page, click the Advanced button.
In the Advanced Security Settings for Group page, select the Permissions tab.
Click Add. In the Select User, Computer or Group window, type in the name of the account for which you want to grant permissions and click OK.
When the Permissions Entry for Group window appears, select the Properties tab.
Select Apply Onto, Group Objects.
In the Permissions section, check the Allow boxes for Read Members and Write Members, as shown in Figure 19.6. Then click OK.
Click OK to close the Advanced Security Settings for Group page.
Click OK to close the group’s property pages. Then click File, Exit, No (to save console settings) to close the Active Directory Users and Computers MMC snap-in, and log out of the server.
So far this chapter has covered site and group administration, which for the most part require little daily administration. Unfortunately, this is not the case for user administration. With user administration comes several repetitive tasks—for example, changing or adding attribute values such as phone number, resetting passwords for locked-out accounts, managing user profiles, and changing user group membership and user desktop support. These tasks generally are not planned but have to be addressed on a daily basis.
With user administration also comes periodic tasks that must be run to optimize and keep the environment as secure as possible—for example, running reports for inactive or disabled accounts, updating login scripts, and updating user profiles.
A user profile is made of up of all the settings used to configure a user’s desktop experience. Elements stored in a user’s profile are Internet Explorer favorites, mapped drive and printer configurations, email profiles, My Documents folder data, application-specific configurations or settings, desktop settings, and much more. Administrators frequently need to update or reconfigure a user’s profile when a configuration change is necessary or if a new profile is being created.
Several types of user profiles are available, giving administrators greater flexibility when it comes to customizing and automating profile settings. Although each profile type described in the following sections offers certain features, many profile settings can also be configured using Group Policy.
A local user profile is stored on the local server or workstation’s hard disk. This type of profile is maintained and used only on a single machine. If this profile is lost or the user moves to a new machine, a new profile must be created and configured manually. Local profiles are always stored on the local machine, regardless of whether the user is logging on with a roaming or mandatory profile.
A roaming profile is stored on a server file share and follows a user to whatever server or workstation he logs in to. Upon logon, the roaming profile is downloaded from the server share to the local machine. The user then runs the profile from the local cached copy of the roaming profile throughout the entire session. Upon logoff, the profile is saved back to the server share location with any updates intact.
Because roaming profiles must be copied down from the server during logon and pushed back to the server upon logoff, this process can extend user logon/logoff intervals. The bigger the profile size, the longer the wait. Here’s an example. One of our former clients complained that certain users required 15 minutes to log on and 15 minutes to log off. Upon investigation, we found out that these users had more than 400MB of temporary Internet files and the client was on a 10MB network. To fix this problem, we created a Group Policy setting, and configured Internet Explorer to delete all temporary Internet files upon exiting. This reduced the overall profile size and immediately improved logon/logoff performance.
Other folders to consider when planning to use roaming profiles are the My Documents and Desktop folders. Either advise your users to save data directly to their home network drive, or redirect both the Desktop and My Documents folders to a server to eliminate the need for the data stored within these folders to be uploaded and downloaded with the profile during logon/logoff.
A mandatory profile is the same as a roaming profile except that changes made to the profile settings are not saved to the server upon logoff. This type of profile is most commonly used in classroom environments in educational institutions or for public shared access workstations such as those found in an Internet cafe. To change a profile to a mandatory profile, configure the profile as you like and log out of that user account. Then, with an Administrator account, locate the profile folder and rename the Ntuser.dat file to Ntuser.man.
On each Windows 2000 and Windows XP system that was not upgraded from a previous version of the operating system, a default profile folder exists. This profile is used when a user logs on to the system for the first time and her account is not configured to download a roaming or mandatory profile. To create a common profile for all new users when they log on, configure a profile using a test user account and save this profile to the default profile folder.
A temporary profile is used when a user with a roaming profile cannot locate the profile folder on the server. When this happens, the machine first attempts to load this user’s profile from a cached copy on the local profile. This profile might be outdated but will most likely have all the correct information. If a user has never logged on to the workstation but specifies a roaming profile that cannot be located or does not exist yet, the temporary profile will become that user’s profile and be saved up to the server upon logoff, if possible. In other words, if no local copy of the profile exists, the temporary profile is built from the default profile folder.
The All Users profile folder houses profile settings that you want to apply to all users logging on to the system. The settings, usually desktop and Start menu customizations, are added to the user’s existing profile. The All Users profile additions are not carried over or saved to the roaming or local profile. These settings are machine specific only.
When new users are added to an organization, their profiles need to be created from scratch or possibly from a custom script that leverages resource kit tools to minimize the tasks necessary to configure the profiles. To simplify this process even more, you could create template profile folders and save them to a server location. When a new user is created, this profile can be copied to the desired profile location and can be used as a profile starting point for that user. The process to create a template profile is the same as creating a default profile, outlined in the next section, but the location where the profile is saved may vary.
You can create a default profile by logging on to a workstation and manually configuring the desktop settings as desired, including network shortcuts, desktop shortcuts, printers, mapped drives, environmental settings such as path temp file location, and Internet settings. Most of these tasks can also be performed using Group Policy and logon scripts, but configuring a default profile ensures that the desired settings are delivered to each user regardless of whether the user is a local or domain user or if the policy is applied correctly.
To create a default profile, follow these steps:
Log on to a workstation with a standard local or domain user account, with the same level of access a standard user will have. For this example, use an account called TemplateUser1.
Configure the profile the way you want it. Create desktop settings, Internet settings, or whatever is necessary for a standard user.
Log off the workstation. The profile is then saved to the c:Documents and SettingsTemplateUser1 directory.
To make a profile the default profile, you must copy the files to the default user profile folder. To copy the profile, perform the following steps:
Log in with an Administrator account.
Choose Start, Control Panel.
Select the Advanced tab and click the Settings button in the User Profiles section.
Select the correct profile, as shown in Figure 19.7, and click the Copy To button.
In the Copy To window, enter the path to the default user directory. If necessary, click Browse and find the correct folder. The default location is C:Documents and SettingsDefault User.
You don’t need to change the Permitted to Use section, so click OK to complete this task.
Windows Server 2003 systems provide local security policies to manage user and group administrative access on a per-server basis. Within Active Directory, you can use group policies to set configurations and security on a specified collection of computers, users, or groups of users from a single policy. These policies can be used to deliver standard desktop configurations and security settings for server access and application functionality. Also, policies can set user configurations to deliver software on demand, redirect desktop folders, plus affect many more settings. Many settings within each policy explain what the setting controls and whether computer-based settings apply to only Windows XP workstations. Chapter 15, “Security Policies and Tools,” describes security policy in more depth, but the best way to discover and learn about all the Group Policy settings is to open an actual Group Policy Object and start browsing each section.
You can view Active Directory–based group policies or server and workstation local security policies with very little effort by using a single console. Using the Group Policy Object Editor MMC snap-in, you can read and configure both Group Policy Objects and local security policies.
To open an existing policy, follow these steps:
Log on to a Windows Server 2003 system or an XP workstation with the Administration Pack installed.
If you used a standard user account to log on, at the Run prompt, type
runas/user:administrator mmc.exeand click OK to open the MMC with an elevated account. In this example, you use the Administrator account, but you can use any account with the rights to view or modify the respective policy.A command-prompt window then opens, prompting for the correct password if you used the
runascommand. Type in the password and press Enter.When the MMC opens, choose File, Add/Remove Snap-in.
In the Add/Remove Snap-in window, click Add.
In the Add Stand-alone Snap-in page, scroll down and select Group Policy Object Editor and then click Add.
The Select Group Policy Wizard opens, asking which policy you want to open. The default is the local computer policy of the machine currently logged in. To choose a domain-based group policy or a local security policy on a different server workstation, click the Browse button.
Select the correct tab to find the policy, as shown in Figure 19.8, and click OK.
Click Finish in the Select Group Policy Wizard, click Close in the Add Stand-alone Snap-in page, and click OK in the Add/Remove Snap-in window to return to the console and access the respective policy.
After you access the policy, you can view each setting or settings container to determine the default value and, in some cases, learn what the setting controls. Keep in mind that, with the correct level of permissions, any changes you make to this policy are live changes; there is no undo other than reversing the individual setting changes or performing a Primary restore of the SYSVOL folder on a domain controller that has already replicated the changes.
When changes need to be made or tested using group policies, the administrator should leave the production environment untouched and create test policies in isolated test lab environments. When test labs are not available or cannot replicate the production environment, the administrator can test policies in isolated organizational units within a domain. Also, if domain- or site-based policies need to be created for testing, security filtering could be modified to apply the policy only to a specific set of test users or groups.
The preceding section described how to locate a group policy. Using the Active Directory Users and Computers and Active Directory Site and Services snap-ins, you can create, configure, and open site, domain, and organizational unit (OU) group policies for editing. The following steps outline how to create a new domain-based policy and configure its security filtering to apply to a single user:
Log on to a Windows Server 2003 system or an XP workstation with the Windows Server 2003 Administration Pack installed.
Choose Start, Run. Type
MMC.exeand click OK.If you used a standard user account to log on, at the Run prompt, type
runas/user:administrator mmc.exeand click OK to open the MMC with an elevated account. In this example, you use the Administrator account, but you can use any account with the rights to view or modify the respective policy.A command-prompt window then opens, prompting for the correct password if you used the
runascommand. Type in the password and press Enter.When the MMC opens, choose File, Add/Remove Snap-in.
In the Add/Remove Snap-in window, click Add.
In the Add Stand-alone Snap-in page, select Active Directory Users and Computers and click Add.
Click Close in the Add Stand-alone Snap-in page and click OK in the Add/Remove Snap-in window to return to the console and access the snap-in.
The snap-in defaults to the domain used for the login. To change the domain focus, right-click Active Directory Users and Computers in the left pane and select Connect to Domain.
Type in the fully qualified name of the domain and click OK to return to the console. If necessary, click the Browse button to locate the domain.
In the console, you should see the domain listed. Right-click the domain listing and select Properties.
Select the Group Policy tab and then click the New button. A new policy then appears in the window.
Type in a descriptive policy name and press Enter to create the policy.
When the policy is listed, select it and click the Properties button.
Select the Security tab and highlight the Authenticated Users entry.
In the Permissions section, scroll down and uncheck the Allow box for Apply Group Policy.
Select each entry in the Group Policy access control list and verify that no existing groups are allowed to apply the group policy.
Click Add and type in the name of a user or group. To find a list of users and groups within the current domain, click the Advanced button, and in the search window, click Find Now to return the complete list. Scroll down and select the users or groups you want and click OK.
Click OK to add the entries to the policy.
Back in the security window, select the respective entry and check the Allow box for Apply Group Policy, as shown in Figure 19.9. Click OK when you’re finished.
Click Apply to update the Group Policy security; then select the General tab.
On the bottom of the General tab, you can disable the Computer or User Settings section of Group Policy to improve policy application intervals. Leave both sections enabled if both user and computer settings will be used. Click OK to close the Group Policy properties.
If you want to configure the group policy now, select the policy from the window and click the Edit button to open the Group Policy Object Editor with the focus on the new policy. Otherwise, click Close.
After a Group Policy Object is created, a few steps should be taken to configure how the policy will be applied and to optimize the time to apply the policy. Group policies can be limited to computer- or user-specific settings. To determine whether either type of setting can be disabled, the administrator should figure out which settings are necessary to provide the desired policy settings. In many cases, a policy uses settings for both types. To disable either user or computer policy settings, open the properties as described in the section “Viewing Policies with the Group Policy Object Editor” earlier in this chapter. When the policy is listed, right-click the policy and select Properties. On the General tab, check the appropriate boxes to disable computer or user settings and click OK to save the settings.
When multiple group policies exist, they are applied in a predefined order. For a particular user or computer, the order can be derived using the Resultant Set of Polices snap-in described in the “The Resultant Set of Policies MMC Snap-in” section. The results of standard policies are that if setting X is enabled on a top-level policy and disabled on the last policy to apply to an object, the resulting setting will disable setting X. Many policy settings have three states: enabled, disabled, and the default of not configured.
You can limit group policies to apply to specific users or computers by modifying the security entries. They can be limited to which types of settings will be disabled using the general properties of the policy, and policies can be blocked at the site, domain, or OU container level using a setting called Block Policy Inheritance. When company-wide, domain-wide, or site-wide settings need to be configured and imposed, the group policy can be configured to use No Override.
The Block Policy Inheritance option allows an administrator to prevent higher-level policies from applying to users and computers within a certain site, domain, or OU. This capability can be useful to optimize Group Policy applications and to ensure that rights are grandfathered down to the Active Directory objects within the container.
To block policy inheritance, follow these steps:
To block inheritance, open either the AD Users and Computers MMC snap-in for domain or OU objects or the AD Sites and Services MMC snap-in for site objects.
Right-click the object you want to modify and select Properties.
Select the Group Policy tab and check the Block Policy Inheritance box, as shown in Figure 19.10.
Click OK to update the container’s Group Policy properties.
Configuring the No Override option prevents lower-level policies from blocking policy inheritance and from changing the parameters or configured settings in a policy. This option should be used only if policy needs to be enforced on AD objects in every container and subcontainer with a link or inheritance to this policy object.
To configure the No Override option for the default domain policy, follow these steps:
Open the AD Users and Computers MMC snap-in for the desired domain.
Right-click the domain listing and select Properties.
Select the Group Policy tab, select the default domain, and click the Options button.
Check the No Override box and click OK in the Policy Options property page.
Click OK to close the Domain property page to complete the process.
When policies are used throughout an organization, sometimes the policy settings do not apply to a user or computer as originally intended. To begin basic troubleshooting of Group Policy application issues, you need to understand the policy application hierarchy. First, the local server or workstation policy applies to the user or computer, followed by site group policies, domain group policies, and finally the organizational unit group policies. If nested OUs have group policies, the parent OU policies are processed first, followed by the child OUs, and finally the OU containing the Active Directory object (user or computer). You might find it easier to remember “LSD-OU”—the acronym for local, site, domain, and then OU.
Now that you know the order in which policies are applied, you can proceed to use the Group Policy testing and troubleshooting tools provided with Windows Server 2003—namely the Resultant Set of Policies MMC snap-in and the command-line utility GPResult.exe, which is the command-line version of the RSOP snap-in.
The RSOP snap-in can be used to show the effective policy settings for a user who logs on to a server or workstation after all the respective policies have been applied. This tool is good for identifying which policies are being applied and what the effective setting is.
To test the policies for a user, use the RSOP snap-in as follows:
Log on to the server or workstation where the user has already logged on.
Choose File, Add/Remove Snap-in.
Click Add in the Add/Remove Snap-in window.
Select Resultant Set of Policy from the Add Stand-alone Snap-in page and click Add. Click Close and then OK in the Add/Remove Snap-in window.
In the console window, right-click Resultant Set of Policy and select Generate RSOP Data.
Choose Logging Mode on the Mode Selection page and click Next.
On the Computer Selection page, select This Computer and click Next.
On the User Selection page, select the Display Policy Settings For radio button and then select the Select a Specific User option, as shown in Figure 19.11.
On the Summary of Selections page, verify that all the correct selections were chosen and click Next to gather the data.
When the snap-in has finished collecting data, click Finish to return to the console and review it.
Within the console, you can review each particular setting to see whether a setting was applied or the desired setting was overwritten by a higher-level policy. To figure out which actual policies have been applied, right-click either the Computer Configuration or User Configuration container and then select Properties to see the list of policies applied for the specified user.
The Print Management Component (PMC) was added to Windows 2003 R2 as an add-in component to help organizations better manage and administer printers on an enterprise basis. Prior to the Print Management Component, a network administrator would have to point to each network printer or printer server individually to manage and administer the device. For a large enterprise with hundreds of printers and dozens of printer servers, selecting print servers each time a printer needed to be managed was a very tedious task. Furthermore, if the administrator didn’t remember which printer was attached to which print server, finding the printer and print server that needed management could take a while.
The Print Management Component provides a single interface where an administrator can open the Print Management utility and view all printers and print servers in the enterprise. Furthermore, PMC can be configured to group printers together so that certain administrators can manage and administer only certain printers. As an example, if an organization has an administrator for a particular building, the PMC interface can be filtered to list only the printers within the building. This allows the administrator to see only certain printers for which he is responsible, as well as consolidate multiple print server groups of printers into a single interface for management and administration.
The Print Management Component needs to be installed only on the system from which the administrator is managing; it does not need to be installed on all print servers or systems in the enterprise. Functionally, PMC could be installed on just one system.
To install the Print Management Component, the Windows 2003 R2 components need to be installed on the system (see the section, “Preparing a System and Installing the Windows 2003 R2 Components,” in Chapter 3 for installation instructions). Perform the following steps to enable the Print Management Component option on the system:
Log on to the desired server using an account with Local Administrator access.
Select Start, Settings, Control Panel, Add/Remove Programs.
Click Add/Remove Windows Components, and double-click the Management and Monitoring Tools folder. Select the Print Management Component option and click Next.
Click Next to install the component, and then click Finished when done. The installation of the Print Management Component typically does not require you to restart the server.
After the Print Management Component has been installed on a system, the utility needs to be configured to identify the printers and print servers in the enterprise. Printers can be manually added to the Print Management tool for administration and management, or the network can be scanned to attempt to automatically identify printers in the enterprise.
To configure print management resources, launch the Print Management utility by doing the following:
Select Start, Settings, Control Panel.
Open the Administrative Tools folder and double-click Print Management to launch the Print Management Component.
Upon opening the Print Management Component, a screen will appear similar to the one shown in Figure 19.12.
There are two ways to add new printers to a Windows 2003 R2 network. One way is the standard Windows printer installation method of using the Add Printer option. The other option is using the new Print Management utility and adding a printer within the utility. Both methods return the same result, so the main reason to use the Print Management utility method is to simplify all print management tasks of adding, modifying, and managing printers from a single utility.
To add a new printer that is locally attached to a Print Server using the standard Windows Add Printer option method, do the following:
Click Add Printers to launch the Add Printer Wizard, and click Next to bypass the initial installation screen.
Because the printer is locally attached to the Print Server, select Local Printer Attached to This Computer, and then click Next.
Choose the port (LPT1, LPT2, COM1, COM2, and so on) to which the printer is attached, and then click Next.
Choose the manufacturer and the printer type of the printer being added (such as HP for manufacturer and Laserjet 2200 for printer type), and then click Next.
When prompted, give the printer a name (such as “HP Laserjet 2200 in the Marketing Dept”), and then click Next.
When prompted whether you want to share the printer, select the Share Name option and type in a name that will describe the printer (such as HP2200MKTG), and then click Next.
For location, this is optional, but in an enterprise, it is helpful to describe where this printer is located so that when you want to find a printer, you have a better description of the printer and where it is located. For location, enter something such as Building 11, 2nd Floor, and then click Next.
If you want to do a test page, select Yes; otherwise, choose No, and then click Next.
Click Finish to complete the addition of the printer.
To add a new printer that is attached directly to the network backbone using the standard Windows Add Printer option method, do the following:
Select Start, Settings, Printers and Faxes.
Click Add Printers to launch the Add Printer Wizard, and click Next to bypass the initial installation screen.
Because the printer is network attached, select A Network Printer, or a Printer Attached to Another Computer, and then click Next.
Enter the printer name or URL of the printer that will be shared (such as
\pserver1hpljet).Note
If the printer has a network adapter built directly into the printer, such as an HP laser printer with a JetDirect Ethernet port on the back of the printer, see the installation manual that comes with the printer. As an example, for HP printers with built-in Ethernet, you would need to install the HP JetDirect software that comes with the printer to assign an IP address to the printer using the HP utility, and then the utility will walk you through the process of publishing the printer on the Windows network. When using the printer vendor–provided utility, you can skip this section.
Choose the manufacturer and the printer type of the printer being added (such as HP for manufacturer and Laserjet 2200 for printer type), and then click Next.
When prompted, give the printer a name (such as “HP Laserjet 2200 in the Marketing Dept”), and then click Next.
When prompted whether you want to share the printer, select the Share Name option and type in a name that will describe the printer (such as HP2200MKTG), and then click Next.
Entering a location is optional, but in an enterprise, it is helpful to describe where this printer is located so that when you want to find a printer, you have a better description of the printer and where to find it. For location, enter something such as Building 11, 2nd Floor, and then click Next.
If you want to do a test page, select Yes; otherwise, choose No, and then click Next.
Click Finish to complete the addition of the printer.
Another option of adding a printer to the network is to use the Print Management Component utility to add the printer. This process is identical to adding the printer using the Windows Add Printer option addressed in the previous section. However, instead of using two separate interfaces for adding and managing printers, using the Print Management Component option can centralize the tasks into a single interface.
To start the Add Printer Wizard within the Print Management Component, do the following:
Expand the Print Servers section of the Print Management interface.
Right-click one of the print servers listed in the Print Servers section of the interface and choose Add Printer.
If the printer is attached directly to the print server, follow the instructions in the “Using the Add Printer Option in Windows to Add a Local Printer” section of this chapter.
If the printer is attached directly to the network, follow the instructions in the “Using the Add Printer Option in Windows to Add a Network-Attached Printer” section of this chapter.
After printers and print servers have been added to the network, as noted in the previous sections, an administrator can begin to add print servers to the Print Management Component to centrally view, manage, and maintain the printers on the network.
Adding a print server to the Print Management Component will allow the administrator to manage the print server and all the printers the print server hosts. To add a print server to the Print Management Component, do the following:
With printers added to the network and print servers added to the Print Management Component, an administrator can begin to centrally view, manage, and administer the printers and print servers. Some of the tasks that an administrator can perform from the Print Management Component are tasks that an administrator would normally do right on the print server, such as change printer ports, add or modify forms, or view the status of printers whether the printers are online or not. Other tasks are new to the Print Management Component, such as creating custom printer filters that allow multiple administrators to view and manage selected printers based on their site, rights, and roles.
From within the Print Management Component, the administrator can perform general printer administration task. Some of these tasks include
Updating printer drivers—. By right-clicking the Drivers item on the Print Server section of the Print Management interface and choosing Manage Drivers, an administrator can update or change a printer’s printer driver. This is rarely done in a network environment, but there are times when a new printer add-on, such as an envelope feeder or expansion paper feeder or sorter, is added, and a new printer driver is needed to support the new add-on.
Forms—. By right-clicking the Forms item on the Print Server section and choosing Manage Forms, an administrator can create and delete new forms to support different-sized paper or to specify a custom letterhead paper form. Additionally, within this interface an administrator can change the printer port to which a printer is attached on a print server, define log settings, and enable the function to have users notified when a print job has successfully completed printing.
Note
One might wonder when someone would ever create a new printer form or worry about being notified when a print job has been completed, especially when most print jobs are simple 1-page emails or a handful of pages of a Word document. However, a creative use of this feature is used by accounting departments, publishers, or other individuals that print large print jobs. One would want to know when a 400-page document has finished printing, or when 100 sets of a 15-page document are finished printing, collating, and stapling. By creating a custom form, which may just be a simple 8 1/2 × 11-inch form with advanced notifications enabled to notify the user that job has been completed, a user who chooses that form instead of the normal 8 1/2 × 11 form will be notified when the print job has been completed.
A unique function of the Print Management Component is the Custom Printer Filters function that enables an administrator to group printers typically for the purpose of distributing the administration of printers in the environment. For large organizations that might have multiple buildings, sites, and administration boundaries of devices such as printers, the administrators can perform a filter view to see only the printers that fit within their administrative responsibilities.
First of all, to view all printers in the environment, an administrator can click the All Printers section of the Custom Printer Filters section of the Print Management interface. All the printers for the network will be listed here.
Note
If printers on the network are not listed in the All Printers view, please refer to the section, “Adding Print Servers to the Print Management Component.”
To create a custom printers view, do the following:
Right-click the Custom Printers View in the Print Management utility and choose Add New Printer Filter.
Type in a descriptive name for this filter view, such as All Printers in the San Francisco Site or All Printers in Building 11.
In the Field drop-down box, choose a field that will contain information that can be filtered. In many cases, the print servers can be filtered because a print server frequently serves printers in a specific geography. Alternatively, organizations that entered location information for printers, such as Building 11, would be able to filter for that designation in a custom printer filter filtered by name. An example might be Field=Location, Condition=Contains, or Value=Building 11. Click Next to continue.
In the Set Notification options page, an administrator can note an email address where the administrator can be notified on the status of events related to the printers in the filter. This might include being emailed every time a printer is offline or every time a printer is out of paper. Enter the appropriate email information (email address, SMTP mail server to be used, and message desired), or leave this section unchecked, and then click Finish.
By clicking on the newly created filter, the filter rule is applied and the printers noted in the filter will be displayed as shown in Figure 19.13. In this figure, you will notice a designation that there are six printers in the environment; however, the filter is searching only for printers in Building 11, and thus only four printers are displayed for this administrator to view and manage.
Virtually an unlimited number of printer filters can be created to show different groupings of printers to be managed or administered. Organizations have created custom printer filters by printer manufacturer, such as HP, Xerox, and Sharp, or by printer type, such as laser, color laser, and plotter, to be able to view assets by make, model, or configuration.
Managing Active Directory sites, groups, and users can be daunting if some of these tasks cannot be automated or simplified. This chapter outlined ways to create these objects and included the information necessary to manage these objects from a standalone and enterprise level. For more detailed information on these topics, refer to Chapters 5 and 6 for Active Directory design, Chapters 21 and 29 for Group Policy specifics, and Chapter 23 for ideas on how to script simple administrative tasks to reduce manual tasks.
Clearly understand your roles and responsibilities in the enterprise network and understand how the different components that make up the network communicate and rely on one another.
Choose the appropriate administrative model (central, distributed, or mixed) for the organization based on required services and skillsets in each location.
Track licensing usage using a centralized server.
Use site policies to define custom network security settings for sites with higher requirements or to delegate administrative rights when administration is performed on a mostly geographic basis.
Ensure that sites contain local network services such as domain controllers, global catalog servers, DNS servers, DHCP servers, and, if necessary, WINS servers.
Use security groups to create distribution lists.
Create a universal group to span domains, but have only a global group from each domain as a member.
Keep roaming profiles at small, manageable sizes.
Use mandatory profiles to increase security and gain control over the desktop.
Use profile templates to minimize the amount of required administration.
Use local and group policies to manage users and desktops.
Modify Group Policy security entries to limit Group Policy application to specific users or computers.
Use RSOP or the command-line utility GPResult.exe to view and troubleshoot the way group policies are applied.
Use the Print Management Component added to Windows 2003 R2 to centrally view, manage, and administer printers in the network environment.