- Win Server 2003 : Windows Rights Management Services

In today's competitive business environment, information is a crucial commodity that requires proper security. With the numbers and types of external storage media available, it is even more critical for you to protect your data from accidental or intentional disclosure. There are an increasing number of

government initiatives to protect information that might be accessed or stored by companies. The Health Insurance Portability and Accountability (HIPAA) Act was passed to ensure the protection of personal health information. The Gramm-Leach-Bliley Act was passed to provide more security for consumers' financial privacy. In addition to these government actions, corporations are being held increasingly responsible for the safeguarding of information they hold on their own employees as well as on their customers. The loss or compromise of this data could result in expensive legal action and loss of confidence by consumers.

Windows® Rights Management Services (RMS) can help. RMS can provide the protection for digital information required by your organization or by government regulation. RMS is fully compliant with the Federal Information Processing Standard (FIPS) 140-1., and therefore transactions from private business can be conducted with the government.

Compromise of data can occur through malicious intent or unintentional actions. The ease with which data can be copied and moved to external storage media (CDs, flash drives, external hard drives, and so on) makes it difficult to protect. In many cases, accepted security practices are not able to adequately protect this information any longer. A person may have access to a document, but you may not want this person to be able to save it to the external storage devices. Controlling how a document can be handled is a key element of RMS, as is protecting it while crossing the network.

RMS Resources

• For an overview of Windows RMS technologies for Windows Server 2003, see:
  microsoft.com/windowsserver2003/technologies/rightsmgmt
• A Technical Overview of Windows Rights Management Services whitepaper is available from:
  microsoft.com/windowsserver2003/techinfo/overview/rmenterprisewp.mspx
• You can try out RMS without the fuss of setting up your own lab by using the TechNet Rights Management Services Virtual Lab at:
  microsoft.com/technet/traincert/virtuallab/rms.mspx
• Licensing and download information for Windows RMS is available from:
  microsoft.com/windowsserver2003/techinfo/overview/rmsoverview.mspx

Today it's common to view security as a means of providing protection for networks and the data contained within the network. The first line of defense for networks is the perimeter, which is protected through firewalls, allowing only traffic you approve to enter or leave the network. While a firewall will allow authorized traffic to exit, it doesn't know if what is contained in the authorized traffic is of a compromising nature and should be prevented from leaving the network.

The next layer in network security is the use of NTFS permissions and Access Control Lists (ACLs). Together these are used to limit who can access what resources and, to a certain extent, what they can do with these resources. But once a user has accessed a file, she can save it to another location, thereby bypassing the security measures enforced with permissions and ACLs.

RMS can control what a user can do with a document after it has been accessed. This control will last regardless of where the user might store the document and you can even have time limits associated with the document so that, after a specified period of time, the document is no longer accessible.

When trying to stem the flow of potentially compromising information, you have to take into account e-mail messages. While you may mark e-mail messages "confidential," there haven't been any built-in mechanisms to restrict the forwarding of these messages. Sensitive information that is contained within e-mail is just as susceptible to dissemination as it is within a document. RMS allows for the control of e-mail messages and will prevent the inadvertent forwarding of messages that may contain sensitive data.

RMS Components

There are three essential components that comprise RMS: the RMS server, the RMS client, and RMS-enabled applications and SDKs. The RMS server is responsible for the proper certification of trusted entities, provides licensing of content that is rights-protected, and enrolls any users and servers. It also serves as the administrative point for RMS (see Figure 1).

Figure 1 Rights Management Components

The RMS client must be installed to work with a RMS server. The client software allows applications that are RMS-enabled to communicate with a server. The client requests licenses to consume (access and use) content and allows for the publishing of content.

The final element is the actual application that can use RMS. Applications can be made RMS-aware by using the Rights Management Services SDK.

RMS applies persistent usage policies to ensure consistent and reliable control over content. A trusted entity (an application, computer, group, or user) has been granted permission to use RMS. Since it is trusted, that entity is allowed to make use of RMS. Trusted entities can apply usage rights and conditions to content. They can specify what rights, permissions and actions are applied to a document. A trusted entity can specify that a document cannot be printed or saved, that an e-mail message cannot be forwarded, and even when access to the message will expire, thus eliminating further maintenance of the resource.

RMS-enabled resources are protected with encryption. A user wanting to access a resource must first be validated. This validation determines if the user is allowed access to the resource and, if so, what kind of usage rights are permitted. This usage requirement is maintained for the document.

How RMS Works

RMS is involved in three areas to ensure proper utilization: the actual creation of rights-protected resources, licensing and distributing these rights-protected resources, and decryption and usage of rights-protected resources. A trusted entity (one that has been granted access to make use of RMS) can create resources that are protected. When a resource has been protected, an XrML certificate identifies who is allowed access and what usage requirements are imposed on the resource.

The RMS server will issue a publishing license that delineates who is allowed to access the resource. Once this is done, the protected resource can be sent. When a trusted entity, say a user, wants to access a resource, the user will be validated by the RMS server which holds the public key for the encrypted resource and will issue a use license to the user. This use license specifies how the resource can be used and actions that can be taken with it. So these licenses are employed as the actual control mechanisms. The publishing license is created when a document is RMS-enabled and has been encrypted. The use license is required when a document is consumed.

Encrypting and Securing Content

Exactly how does RMS direct the process whereby control is maintained over documents, e-mail messages, and applications? RMS employs Public Key Infrastructure (PKI) as the basis for controlling access to documents. PKI uses asymmetric encryption in which two keys are used for the encryption/decryption process: one public key and one private key. In a typical PKI environment, a user will encrypt a document that can only be unencrypted by the recipient. In an RMS environment, the document is encrypted by the user and is maintained by the server. Any requests to access the document are made to the server, which will validate the request and its purpose, to include printing, forwarding, and even the saving a document.

The keystone of RMS is in using a standardized rights expression language (REL) to provide a common framework for interoperability. The language that is used to provide this commonality is XrML version 1.2.1. The XrML language can be used to apply rights and security to digital information in the form of a license. This XrML license is attached to the resource and is used to specify the permissions and usage applied to it.

XrML provides a universal method for securely specifying and managing rights and conditions associated with all kinds of resources including digital content and services. It is fully compliant with XML namespaces using XML schema technology.

Now let's see how the process of using RMS on a document works. The IT hero in this scenario has been tasked with coming up with the raises and salary information for the next fiscal year. Let's assume that he has the appropriate RMS client software installed on his machine. He creates a spreadsheet containing the new financial figures (something any company would want to keep under tight control!) and wants to apply RMS security to this confidential document.

Our hero uses an RMS-enabled application—in this case Microsoft Office 2003—to contact the RMS server through the application to apply for a publishing license for this document. The RMS server issues the publishing license which is applied to the document. The document has been encrypted, has a publishing license attached, and has suitable usage restrictions applied due to this process. The document has now been made more secure than simply using NTFS permissions and ACLs.

The IT guy sends the document to his manager for final review and comments. Before the manager can access the document, she will need to contact an RMS server to receive a use license for the document. The request for a use license is performed through the RMS-enabled application and, once complete, allows the manager to access the document according to the usage restrictions that were applied by the author of the document (see Figure 2).

Figure 2 Using RMS to Protect Documents and E-Mail (Click the image for a larger view)

Requirements and Installation

The base requirements for RMS are Active Directory®, IIS 6.0, the .NET Framework and ASP.NET, and Microsoft® Message Queue Server (MSMQ). You'll also need RMS server software (RMS will only run on Windows Server 2003), RMS client software and RMS-aware applications, as well as a SQL Server™ 2000 SP3 (or greater) database.

Once you have the requisite software installed on the RMS server, you will need to provision the server. Provisioning simply means getting the server to communicate and respond as an RMS server on your network. The first RMS server you install will need to contact a Microsoft RMS enrollment server and request a Server Licensor Certificate (SLC). Once the SLC has been received from the enrollment server and installed, you will need to register the RMS Service Connection Point (SCP). RMS-enabled applications search SCP when trying to contact an RMS server. The actual SCP is stored as an entry in the Active Directory Configuration container.

The next step after configuring the RMS server is to configure the client machines for use with RMS. There are three distinct steps associated with configuring client machines for RMS, a process called Client Machine Activation. You need to install the RMS client software package on each machine; then you will go through the machine activation process that will create a lockbox (which holds the cryptographic keys) on each client machine. The final step involves getting a user certificate, which is used to generate an association between the user and a particular computer.

To take the RMS process a step further, you can create and deploy a Rights Policy Template to ensure that users who request a publish license receive a standard template that matches your requirements. This template will have the permissions listed that you can choose to apply.

RMS has a valuable place in a network where securing information from improper dissemination is vital. While there is a certain amount of effort required to install and provision an RMS solution, the end result more than justifies that effort.

- Win Server 2003 : 19 Smart Tips for Securing Active Directory

Does Active Directory keep you up at night? One could easily understand why. It is most likely the largest and most critical distributed system in your enterprise. Along with

disaster recovery, Active Directory® security is at the top of the list of topics that gnaw away at an administrator’s sleep.

But there’s a lot you can do to enhance your Active Directory security, and you’ve probably already taken some steps. What follows is a list of tips you can use to help you make your Active Directory installation more secure. First I’ll cover administrative security, then passwords and group security, then wrap up with tips for domain controller security.

1. Document What You Have

The very first step you need to take is to document your Active Directory configuration. It’s not very exciting work, but you can’t tell where you need to go if you don’t know where you are right now. A good place to start is with the high-level structures like forest and domain configuration, organizational unit (OU) structure, top-level directory security, and existing trust relationships. Document your site topology by listing the sites, configuration settings for each site, site links and their settings, the list of subnets and their settings, and any manually created connection objects and their settings. Document your Group Policy Objects (GPOs) with a Group Policy utility like the Group Policy Management Console (GPMC), available from Microsoft downloads and included in Windows Server™ 2003 R2. The documentation you create should include password and audit policies, and don’t forget to include what the GPOs are linked to and who has rights on them. Be sure you have a list of all changes you’ve made to the Active Directory schema, preferably in the form of a Lightweight Directory Interchange Format (LDIF) file. There’s even a GPMC script included in the download to help you get started. It is located in the %programfiles%\gpmc\scripts directory and is called GetReportsForAllGPOs.wsf.

While you’re at it, also list your domain controllers and their names, their OS versions, and virus scanning software and their versions. Record the backup methods you’re using and how often they run, along with how long you keep the backups. If you use disk-based backups, record where you securely keep the backup files. If you use Windows® DNS, use DNSCMD and DNSLINT to document its configuration. Note whether it’s integrated with Active Directory, whether you use application partitions, and how they are configured.

2. Control Your Administration

Active Directory security begins right at the top—your administration model. Controlling your administration is the single most important step in securing your forest and it’s also probably the hardest. Everyone wants to own a piece of Active Directory, but a well-secured forest model can’t allow this. If your company’s installation is like most, your logical Active Directory design is already set, so you have to work within its constraints. If not, you have the opportunity to build Active Directory from the start.

The forest is the only true security boundary within Active Directory. Domains should be used to facilitate your company’s IT support infrastructure and replication, and OUs should be used to delegate administration within a domain. If you have hard security constraints between two parts of your company, consider implementing another forest. See "Multiple Forest Considerations in Windows 2000 and Windows Server 2003" for recommendations. If necessary, add a security-filtered forest trust to communicate with your first forest (see "Planning and Implementing Federated Forests in Windows Server 2003" for more information). If your domains are already administered by different groups, realize that administrative access to any domain controller in the forest can jeopardize the entire forest. As a result, you need to work closely with the administrative teams of the other domains to ensure you have a uniform domain controller (DC) administration model across the forest. For more detail on this topic, read "Design Considerations for Delegation of Administration in Active Directory".

3. Limit the Number of Administrators

Within your forest, you need to do everything you can to limit the number of administrators. Though the Active Directory security model is much better than it was in Windows NT® 4.0, it still has a weakness: you can’t fully administer a domain controller without being an administrator of the domain. This means that in a basic Active Directory implementation, computer operators in locations that contain DCs are usually members of Domain Admins so they can perform all maintenance functions on these servers. Don’t do this! You’ve handed the keys to your Active Directory forest to a potentially large number of employees with unknown backgrounds and security qualifications. Instead, follow the time-honored practice of determining requirements first and then creating a solution based on these requirements. Meet with operations management to figure out exactly what tasks they need to perform on DCs. Then, design a solution using a combination of Group Policy and third-party tools to grant them as many rights as possible without elevating them to Domain Admins.

Finally, your administration team must assume the tasks you can’t securely delegate to operations. This is a very touchy area because you’re taking away responsibilities from operations, but you’ll have the big stick of information security on your side.

4. Test Group Policy Settings

This is a good opportunity to say a few words about Group Policy. It’s the single most powerful tool for controlling your forest’s security. Precisely because it’s so powerful, however, you need to make sure you test these settings in a controlled environment before rolling them out. You can use a duplicate test-bed environment, be it physical or virtual (through the use of virtualization software such as Virtual Server 2006). You can implement these policies in stages by first linking new security-focused GPOs to individual OUs, then to the entire domain.

5. Use Separate Administrative Accounts

Once you’ve limited the number of administrators, make sure all employees who perform operations with elevated privileges use separate administrative accounts. These accounts should have a naming convention that’s different from standard accounts and should reside in their own OU so you can apply unique GPOs to them. You can group these accounts by the roles they perform and assign rights to these groups rather than to individuals. For example, helpdesk members responsible for account management should have their administrative accounts in a group named " Account Admins", and this group should be added to the Account Operators built-in group.

6. Restrict Elevated Built-In Groups

If your security model follows the recommendations I just outlined, it’s relatively easy to put all elevated built-in groups into Group Policy’s Restricted Groups feature. This will ensure that the group’s membership is enforced every five minutes, limiting the chance that a rogue administrator will inject their account into it. Use Restricted Groups to keep groups like Schema Admins empty and to keep Enterprise Admins very small.

7. Use a Dedicated Terminal Server for Administration

Service administrators (responsible for running core Active Directory services like DCs, sites, and the schema) should perform all their tasks from dedicated terminal server administration points (TSAPs) rather than from their desktops. This is a much more secure practice that minimizes any leaking of desktop malware, makes working with a separate administrative account much less cumbersome and provides a locked-down, customized administration point. Keep these TSAPs in their own OU, and use GPOs to prevent Internet access, restrict logon locally to administrative accounts only, increase auditing procedures, and implement a password-protected screen saver. Upgrading your TSAP to Windows Server 2003 will cause its Active Directory administration tools to sign and encrypt Lightweight Directory Access Protocol (LDAP) traffic between itself and your Windows Server 2003 DCs.

8. Disable Guest and Rename Administrator

Basic account security measures are to disable the guest account and rename the administrator account. You may have already done this. Either way, don’t forget to also remove the default description of these accounts, since that’s easy for bad guys to search for. Most programmatic attacks use the administrator account’s well-known Security Identifier (SID) rather than its name, so renaming Administrator is really of limited use. It does show that you’re using due diligence for security audits, however. The rename policy also can be useful for creating a honeypot Administrator account. This is an account named Administrator (after you’ve renamed the real account) that has a high level of auditing enabled. If anyone attempts to log onto this account by guessing the password, the attempt will be logged. If you have an event log monitoring utility, you can also trigger an alert.

9. Limit Access to the Administrator Account

You should severely limit the number of people who have access to the real Administrator account and password. For the highest level of security, consider the nuclear password option: two (or more) administrators generate two (or more) eight-digit, random, strong passwords separate from each other; then each admin enters his password into the password field. (For a good password generator, take a look at www.winguides.com/security/password.php.) The account now has a password that is 16-digits or longer and that requires at least two administrators to log on; one administrator can’t do it alone.

10. Watch the DSRM Password

An often overlooked but important password is the Directory Service Restore Mode (DSRM) password on domain controllers. The DSRM password, unique to each DC, is used to log onto a DC that has been rebooted into DSRM mode to take its copy of Active Directory offline. You need to update the DSRM password regularly because with this password a local operator can copy NTDS.DIT (the Active Directory database) off the server and reboot before anyone noticed. In early builds of Windows 2000, the only way to change the password was to log on and change it manually—impractical if you have more than two DCs. Windows 2000 Service Pack 2 introduced the SETPWD command (see the Knowledge Base article "Configure Your Server Wizard sets a blank recovery mode password") to remotely update the DSRM password. The NTDSUTIL command in Windows 2003 has the ability to change it remotely (see "How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003"). Create a script to run this operation against your DCs, and run it regularly.

11. Enforce Strong Password Rules

By now, you all know the benefits of strong passwords, but it’s probably too much to expect your users to use them willingly. To help them along, you really should enforce strong password rules in your domain (see "Enabling Strong Password Functionality in Windows 2000"). You can help your users by suggesting strategies such as the use of passphrases instead of confusing word/number/character combinations.

12. Protect the Service Account’s Password

As you know, service accounts are another sore subject. The nature of service accounts—used on application servers for the application’s service—makes a low-impact password change very difficult, and so the password is usually set to never expire. Because the account controls an important service (often on many servers), compromising the service account’s password is not something you want to happen.

Though it may be difficult to solve the password change problem, you can take steps to mitigate the risk of attack or accidental changes. Give the accounts a naming convention that identifies them as service accounts and suggests what they’re used for. Put all of these accounts into a group named something like "Service Accounts" and apply a policy to your application servers to deny the "Log on Locally" policy but allow "Log on as a Service". Keep them in their own OU so you can apply GPOs unique to their requirements.

13. Make Sure that Each DC is Physically Secure

Domain controllers make up the physical aspect of Active Directory. Distributed throughout your enterprise, each DC has its own copy of the Active Directory database NTDS.DIT. This means that one of your paramount security concerns is to make sure that each DC is physically secure. If one of them grows legs and walks off, the thief will have physical access to the directory information tree (DIT) and can run cracking programs against it to obtain usernames and passwords. Therefore, you must have a reaction plan in place to change all passwords in a domain if one of its DCs is stolen.

A proposed feature of the forthcoming version of Windows Server (code-named "Longhorn") aims to mitigate the risk from this scenario dramatically with the read-only domain controller (RODC), a DC whose DIT contains no user passwords. Users are logged on via a Kerberos referral from a full DC; you can configure the RODC to cache the passwords of users who use it for authentication. In a branch office scenario, only the branch office’s users will have their passwords cached on the RODC so if it’s compromised they’re the only passwords that must be changed immediately. The RODC caching configuration is very flexible; it even includes a way to determine who had their password cached on it. As with all discussion of prerelease software, though, this is subject to change.

14. Minimize Unnecessary Services and Open Ports

The Windows Server 2003 SP1 Security Configuration Wizard can quickly harden your DCs in this aspect by stepping you through a wizard to lock it down.

One attack to be wary of—a denial of service of sorts—fills the available disk space on a DC. There are two ways this attack can be executed. The first is by attempting to flood Active Directory with objects. Because Active Directory is hugely scalable, it is unlikely to crash in this scenario, but flooding Active Directory with objects will increase the size of the database until it fills the disk partition. Besides ensuring the DIT is on a partition with lots of free space, consider implementing directory quotas via DSMOD PARTITION or DSMOD QUOTA. This will prevent any one security principal from adding too many objects to the directory.

Another denial of service attack has to do with flooding the SYSVOL folder with files, causing it to fill up the boot partition, and crashing the DC. You can’t use a quota system in this case, but you can create a simple reserve file or files to take up existing free disk space. If you encounter this type of disk-filling situation, simply erase reserve files, one at a time, to maintain free disk space until you resolve the root cause. You can easily create reserve files with the FSUTIL FILE CREATENEW command.

15. Make the DC Time Source Secure

Because Active Directory depends on Kerberos, it’s very sensitive to time variations between its DCs. This is especially true in trusts between forests because they may rely on different time hierarchies. By default, the PDC operations master in the root domain is the reference to which all other DCs in the forest look for accurate time. What time source does this DC look to for accurate time? Is it secure?

16. Audit Important Events

You must enable auditing in a domain-level GPO, with no override, to ensure every system in your domain is tracking important events. You should audit failed logons, successful and failed account management, object access, and policy change. Use the same GPO to boost the security log size, because with the increased auditing you’ll need it.

17. Use IPsec

Many organizations have dragged their feet on the implementation of IPsec because of the complex rules you must build, but it’s relatively easy to implement for inter-DC communication only. For communications from DCs to clients, there are a number of options to consider. Windows Server 2003 DCs by default have SMB signing enabled, which means they sign all their communications to the client to prevent spoofing. Its policy is listed as "Microsoft network server: Digitally sign communications (always)". Be aware of this change when you upgrade, and don’t disable it if you don’t have to.

18. Don’t Store LAN Manager Hash Values

You should try to rid yourself of LM (Lan Manager) password hashes if possible; many password crackers attack the weak LM hash and then deduce the stronger NTLM hash. The policy you need is "Do Not Store LAN Manager Hash Value on Next Password Change". Also consider enabling "Send NTLM v2 response only, refuse LM and NTLM". Most down-level clients can be configured to use NTLMv2. This may not be possible for Active Directory installations in factory environments or other installations where embedded Windows is used. Test these settings carefully because they can break down-level clients. It’s important to remember that these clients not only include Windows NT 4.0 and Windows Me, but also other Server Message Block (SMB)-enabled network clients like network attached storage (NAS) devices, UNIX clients running Samba, or embedded Windows devices like factory station controllers. The Knowledge Base article "Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments" lists recommendations for most DC security settings and user rights.

19. Don’t Forget Your Business Practices

Handle emergencies and document procedures for facing situations like compromised passwords, general Active Directory attacks, and Active Directory disaster recovery. Microsoft has done much of this work for you in "Best Practice Guide for Securing Active Directory Installations", and "Best Practices: Active Directory Forest Recovery".

Prerelease info in this article is subject to change.

- Win Server 2003 : Manage Printers

Windows Server 2003 R2 has a truckload of neat new features, one of which, the Print Management Component, includes great tools for use with Group Policy. The Print Management Component can

centrally manage almost all aspects of the printers on your network. And even better, it lets you deploy printers to users or computers via Group Policy so you can ensure that whenever a user moves from machine A to machine B, she keeps her printer mappings. It can even ensure that every user on machine C will have the same printer settings.

Put Group Policy to Work

Before you can begin using the Print Management Component, you need to perform a number of steps. First you will have to update your Windows Server™ 2003 schema to match the Windows Server 2003 R2 schema. If you want to use Windows Server 2003 to perform printer management, you need to load the Print Management Component on Windows Server 2003. On the other hand, if you want to use Windows® XP for printer management, you need to load the Windows Server 2003 Administration Tools Pack onto your management station. In order to update the schema you’ll need approval from your Active Directory® Schema Administrator. Once you have the approval, this operation is best performed directly upon the Schema Master in your domain.

You need to do the schema upgrade so that printer connection objects get a new fast query lookup via LDAP in Active Directory. This way, the Print Management Console (which I’ll explore shortly) doesn’t have to inspect every Group Policy Object (GPO) in the domain to determine where printers are deployed.

When you pop in the R2 disks, you’ll be presented with the option to continue Windows Server 2003 R2 setup. If you do, however, you’ll get the message stating that setup can’t continue because the Active Directory schema version of the controller is not compatible with Windows Server 2003 R2 and that you must upgrade the schema. You are also instructed that you can upgrade the schema by running adprep.exe /forestprep on the schema operations master. Adprep.exe can be found in the Cmpnents\r2\adprep directory on the Windows Server 2003 installation disk 2. To update the schema, start out by locating Windows Server 2003 R2’s disk 2. In the \Cmpnents directory, run adprep/forestprep. Once this is done, you can continue the installation of R2 by clicking R2Auto.exe on the root of the R2 CD-ROM. The rest of the installation should be a piece of cake.

For the rest of the article, I’ll assume you’re using your Windows Server 2003 and have upgraded it to R2. I’ll also assume that you want to manage your printers from that server, as opposed to a Windows XP management station.

Install the Print Management Component

Next load the Print Management Component by going to Add/Remove Programs | Windows Components | Management and Monitoring tools and selecting Print Management Component, as you can see in Figure 1. Note that next time the Configure Your Server Wizard appears, you’ll see that it’s been installed.

Figure 1 Load the Print Management Console

Now that the Print Management Component has been loaded, you’re ready to deploy printers to your users or your computers. You can do this either by hand using the regular Group Policy editor snap-in or by using the tools provided in the Print Management console.

Deploy Printers Using GPOs

To push a printer down to your users or computers, you start by creating a GPO and linking it to an organizational unit (OU) containing either users or computers, for example, the Sales Users OU. When you edit your next GPO, you’ll see a Deployed Printers node in both the computer and user half of the GPO along with a new Action called Deploy Printer in the Action menu, as seen in Figure 2.

Figure 2 Manage Printers within the GPO Editor

Note that if you don’t see the Deployed Printers node, it’s likely that you don’t have the updated Adminpak tools on your management station (the computer from which you’re editing this GPO). To get the latest tools, download the Windows Server 2003 Administration Tools. This isn’t one huge file like Adminpak.msi; instead it’s a collection of smaller files for specific updated components, such as the Print Console.

Once you select User Configuration | Deployed Printers | Deploy Printer (as seen in Figure 2) or Computer Configuration | Deployed Printers | Deploy Printer, you’ll be ready to blast new printer assignments down. Just type \\server\printer into the Enter printer name dialog (shown in Figure 3), click Add, and it appears that you’re finished. However, you need to go the extra mile to tell your users or computers to actually accept this newly chosen printer.

Figure 3 Enter the UNC Printer Path

Pushprinterconnections.exe is a new R2 command that users or computers need to run. If you’re deploying printers to users, the .exe needs to be run in the user’s Login Script. If you’re deploying printers to computers, it needs to be run in the computer’s Startup Script.

The pushprinterconnections.exe program is found on your R2 server in the \windows\PMCSnap directory along with some other bits associated with the Print Management console (which I’ll talk about in a minute). You can see that in Figure 4. However, this isn’t where you run it. Your job is to take the file and plunk it directly into the GPO itself.

Figure 4 pushprinterconnections.exe in /windows/PMCSnap

While editing the GPO, drill down to the script type (User Login or Computer Startup). Click the Show Files button. Next, copy pushprinterconnections.exe into the window that opens. Back at the properties of the script, click Add and locate and select the pushprinterconnections.exe file. Then click OK. If you want to enable the logging of troubleshooting information, type –log in the Script Parameters box. A per-user debug log file will be written to %temp% and a per-machine debug log will be written to %windir%\temp (these are totally different directories). It’s worth noting that you shouldn’t use the –log parameter in a production environment—unless you want the utility filling up your client machine hard disks with megabytes of log files.

If you are using Windows Vista™, you’ll see that this utility isn’t required; the ability to push down printer connections is built in. As a result, the first thing that PushPrinterConnections.exe does when you run it is to check if it is running on Windows Vista. If so, the utility simply exits. Network administrators don’t have to worry if Windows Vista clients accidentally ran pushprinterconnections.exe.

At this point, you should see the printers when you log in as the user or restart the computer. Note that these printers won’t change during background refresh after you’re already logged in because the pushprinterconnections.exe utility only runs at login or startup.

An Easier Method

There is an alternative to deploying printers by hand using the Group Policy editor: the Print Management Console, which displays printers deployed via GPOs. In Figure 5, you can see each of my printers (HPLaser1 and HPLaser2), the GPOs they’re assigned in, and which side—user or computer—is being forced.

Figure 5 Deployed Printers Node

The Print Management Console also has the ability to push printers directly by creating GPOs of its own. Just drill down to Print Management | Custom Printer Filters | All Printers, locate the printer you want to push down to a computer or user, and select Deploy with Group Policy, as shown in Figure 6. The process begins simply enough, as you can see in the Deploy with Group Policy dialog box in Figure 7; however, after that things get difficult.

Figure 6 Print Management Console

Figure 7 Deploying Printers via GPOs

The interface from there on is almost a throwback to the days before the Group Policy Management Console (GPMC), and we all hated those days. The idea is to click Browse and either find a GPO you happen to know is linked to a Site, Domain, or OU or drill down into an OU and choose to create a new GPO that’s linked to the level to which you drilled. You can see this in Figure 8. The icon being pointed to in the figure is used to create a new GPO and link it.

Figure 8 Create a New GPO to Affect Your Target OU

Once you’ve created and linked the GPO, it’s time to deploy the printer. Here you select which group you want to deploy to: users, computers, or both. Make your choice, then click the Add button, and click OK. Just make sure you don’t miss that Add button. I missed it several times and was driving myself completely nuts!

The important point to remember here is that deploying printers via the Print Management Console doesn’t complete the whole job. While it puts the printer in place in the Deployed Printers node, it doesn’t put the pushprinterconnections.exe app into the Logon Script or Startup Script. This means you have to go back in, via the GPMC, edit the GPO, and put in pushprinterconnections.exe. It can be frustrating, but after you’ve done it a few times it will become part of your routine.

Final Thoughts

Clearly, this ability to push printers down to either users or computers is a nice leap forward. But, unfortunately this new magic isn’t built on the client-side extension of Group Policy. Rather, this is a little trick to push printers down to users. I’d like to see the ability for users to get a changed GPO and have the printers change on the fly with the background refresh interval. It’s not there yet, but appears to be coming soon with Windows Vista. Just remember when you’re planning to use this technique that Windows 2000 only supports per-user printer connections, while Windows XP and Windows Server 2003 support per-user and per-computer printer connections.

How do I install Active Directory on Windows Server 2003?

First make sure you read and understand Active Directory Installation Requirements. If you don't comply with all the requirements of that article you will not be able to set up your AD (for example: you don't have a NIC or you're using a computer that's not connected to a LAN).

Note: This article is only good for understanding how to install the FIRST DC in a NEW ADNEW TREE, in a NEW FOREST. Meaning - don't do it for any other scenario, such as a new replica DC in an existing domain. In order to install a Windows Server 2003 DC in an EXISTING Windows 2000 Domain follow the Windows 2003 ADPrep tip.

Windows 2000 Note: If you plan to install a new Windows 2000 DC please read How to Install Active Directory on Windows 2000.

Windows Server 2003 Note: If you plan to install a new Windows Server 2003 DC in an existing AD forest please read the page BEFORE you go on, otherwise you'll end up with the following error:

Here is a quick list of what you must have:

• An NTFS partition with enough free space
• An Administrator's username and password
• The correct operating system version
• A NIC
• Properly configured TCP/IP (IP address, subnet mask and - optional - default gateway)
• A network connection (to a hub or to another computer via a crossover cable)
• An operational DNS server (which can be installed on the DC itself)
• A Domain name that you want to use
• The Windows Server 2003 CD media (or at least the i386 folder)
• Brains (recommended, not required...)

This article assumes that all of the above requirements are fulfilled.

Step 1: Configure the computer's suffix

(Not mandatory, can be done via the Dcpromo process).

1. Right click My Computer and choose Properties.
2. Click the Computer Name tab, then Change.
3. Set the computer's NetBIOS name. In Windows Server 2003, this CAN be changed after the computer has been promoted to Domain Controller.
4. Click More.
5. In the Primary DNS suffix of this computer box enter the would-be domain name. Make sure you got it right. No spelling mistakes, no "oh, I thought I did it right...". Although the domain name CAN be changed after the computer has been promoted to Domain Controller, this is not a procedure that one should consider lightly, especially because on the possible consequences. Read more about it on my Windows 2003 Domain Rename Tool page.
6. Click Ok.
7. You'll get a warning window.
8. Click Ok.
9. Check your settings. See if they're correct.
10. Click Ok.
11. You'll get a warning window.
12. Click Ok to restart.

Step 2: Configuring the computer's TCP/IP settings

You must configure the would-be Domain Controller to use it's own IP address as the address of the DNS server, so it will point to itself when registering SRV records and when querying the DNS database.

Configure TCP/IP

1. Click Start, point to Settings and then click Control Panel.
2. Double-click Network and Dial-up Connections.
3. Right-click Local Area Connection, and then click Properties.
   
4. Click Internet Protocol (TCP/IP), and then click Properties.
5. Assign this server a static IP address, subnet mask, and gateway address. Enter the server's IP address in the Preferred DNS server box.Note: This is true if the server itself will also be it's own DNS server.

   

   If you have another operational Windows 2000/2003 server that is properly configured as your DNS server (read my Create a New DNS Server for AD page) - enter that server's IP address instead:

   

6. Click Advanced.
7. Click the DNS Tab.
8. Select "Append primary and connection specific DNS suffixes"
9. Check "Append parent suffixes of the primary DNS suffix"
10. Check "Register this connection's addresses in DNS". If this Windows 2000/2003-based DNS server is on an intranet, it should only point to its own IP address for DNS; do not enter IP addresses for other DNS servers here. If this server needs to resolve names on the Internet, it should have a forwarder configured.
11. Click OK to close the Advanced TCP/IP Settings properties.
12. Click OK to accept the changes to your TCP/IP configuration.
13. Click OK to close the Local Area Connections properties.

Step 3: Configure the DNS Zone

(Not mandatory, can be done via the Dcpromo process).

This article assumes that you already have the DNS service installed. If this is not the case, please read Create a New DNS Server for AD.

Furthermore, it is assumed that the DC will also be it's own DNS server. If that is not the case, you MUST configure another Windows 2000/2003 server as the DNS server, and if you try to run DCPROMO without doing so, you'll end up with errors and the process will fail.

Creating a Standard Primary Forward Lookup Zone

1. Click Start, point to All Programs, point to Administrative Tools, and then click DNS Manager. You see two zones under your computer name: Forward Lookup Zone and Reverse Lookup Zone.
2. Right click Forward Lookup Zones and choose to add a new zone.
3. Click Next. The new forward lookup zone must be a primary zone so that it can accept dynamic updates. Click Primary, and then click Next.
4. The name of the zone must be the same as the name of the Active Directory domain, or be a logical DNS container for that name. For example, if the Active Directory domain is named "lab.dpetri.net", legal zone names are "lab.dpetri.net", "dpetri.net", or "net".

   Type the name of the zone, and then click Next.

5. Accept the default name for the new zone file. Click Next.
6. To be able to accept dynamic updates to this new zone, click "Allow both nonsecure and secure dynamic updates". Click Next.
7. Click Finish.

You should now make sure your computer can register itself in the new zone. Go to the Command Prompt (CMD) and run "ipconfig /registerdns" (no quotes, duh...). Go back to the DNS console, open the new zone and refresh it (F5). Notice that the computer should by now be listed as an A Record in the right pane.

If it's not there try to reboot (although if it's not there a reboot won't do much good). Check the spelling on your zone and compare it to the suffix you created in step 1. Check your IP settings.

Enable DNS Forwarding for Internet connections (Not mandatory)

1. Start the DNS Management Console.
2. Right click the DNS Server object for your server in the left pane of the console, and click Properties.
3. Click the Forwarders tab.
4. In the IP address box enter the IP address of the DNS servers you want to forward queries to - typically the DNS server of your ISP. You can also move them up or down. The one that is highest in the list gets the first try, and if it does not respond within a given time limit - the query will be forwarded to the next server in the list.
5. Click OK.

Creating a Standard Primary Reverse Lookup Zone

You can (but you don't have to) also create a reverse lookup zone on your DNS server. The zone's name will be the same as your TCP/IP Network ID. For example, if your IP address is 192.168.0.200, then the zone's name will be 192.168.0 (DNS will append a long name to it, don't worry about it). You should also configure the new zone to accept dynamic updates. I guess you can do it on your own by now, can't you?

Step 4: Running DCPROMO

After completing all the previous steps (remember you didn't have to do them) and after double checking your requirements you should now run Dcpromo.exe from the Run command.

1. Click Start, point to Run and type "dcpromo".
2. The wizard windows will appear. Click Next.
2. 
3. In the Operating System Compatibility windows read the requirements for the domain's clients and if you like what you see - press Next.
4. Choose Domain Controller for a new domain and click Next.
5. Choose Create a new Domain in a new forest and click Next.
6. Enter the full DNS name of the new domain, for example - kuku.co.il - this must be the same as the DNS zone you've created in step 3, and the same as the computer name suffix you've created in step 1. Click Next.

   This step might take some time because the computer is searching for the DNS server and checking to see if any naming conflicts exist.

7. Accept the the down-level NetBIOS domain name, in this case it's KUKU. Click Next
8. Accept the Database and Log file location dialog box (unless you want to change them of course). The location of the files is by default %systemroot%\NTDS, and you should not change it unless you have performance issues in mind. Click Next.
9. Accept the Sysvol folder location dialog box (unless you want to change it of course). The location of the files is by default %systemroot%SYSVOL, and you should not change it unless you have performance issues in mind. This folder must be on an NTFS v5.0 partition. This folder will hold all the GPO and scripts you'll create, and will be replicated to all other Domain Controllers. Click Next.
10. If your DNS server, zone and/or computer name suffix were not configured correctly you will get the following warning:This means the Dcpromo wizard could not contact the DNS server, or it did contact it but could not find a zone with the name of the future domain. You should check your settings. Go back to steps 1, 2 and 3. Click Ok.

    You have an option to let Dcpromo do the configuration for you. If you want, Dcpromo can install the DNS service, create the appropriate zone, configure it to accept dynamic updates, and configure the TCP/IP settings for the DNS server IP address.

    To let Dcpromo do the work for you, select "Install and configure the DNS server...".

    Click Next.

    Otherwise, you can accept the default choice and then quit Dcpromo and check steps 1-3.

    

11. If your DNS settings were right, you'll get a confirmation window.

    Just click Next.

12. Accept the Permissions compatible only with Windows 2000 or Windows Server 2003 settings, unless you have legacy apps running on Pre-W2K servers.
13. Enter the Restore Mode administrator's password. In Windows Server 2003 this password can be later changed via NTDSUTIL. Click Next.
14. Review your settings and if you like what you see - Click Next.
15. See the wizard going through the various stages of installing AD. Whatever you do - NEVER click Cancel!!! You'll wreck your computer if you do. If you see you made a mistake and want to undo it, you'd better let the wizard finish and then run it again to undo the AD.
    
16. If all went well you'll see the final confirmation window. Click Finish.
17. You must reboot in order for the AD to function properly.
18. Click Restart now.

Step 5: Checking the AD installation

You should now check to see if the AD installation went well.

1. First, see that the Administrative Tools folder has all the AD management tools installed.
2. Run Active Directory Users and Computers (or type "dsa.msc" from the Run command). See that all OUs and Containers are there.
3. Run Active Directory Sites and Services. See that you have a site named Default-First-Site-Name, and that in it your server is listed.
4. If they don't (like in the following screenshot), your AD functions will be broken (a good sign of that is the long time it took you to log on. The "Preparing Network Connections" windows will sit on the screen for many moments, and even when you do log on many AD operations will give you errors when trying to perform them). = Bad

   This might happen if you did not manually configure your DNS server and let the DCPROMO process do it for you.
   Another reason for the lack of SRV records (and of all other records for that matter) is the fact that you DID configure the DNS server manually, but you made a mistake, either with the computer suffix name or with the IP address of the DNS server (see steps 1 through 3).

   Open the DNS console. See that you have a zone with the same name as your AD domain (the one you've just created, remember? Duh...). See that within it you have the 4 SRV record folders. They must exist.
   = Good

   To try and fix the problems first see if the zone is configured to accept dynamic updates.

5. Right-click the zone you created, and then click Properties.
6. On the General tab, under Dynamic Update, click to select "Nonsecure and secure" from the drop-down list, and then click OK to accept the change.You should now restart the NETLOGON service to force the SRV registration.

   You can do it from the Services console in Administrative tools:

   

   

   Or from the command prompt type "net stop netlogon", and after it finishes, type "net start netlogon".

   Let it finish, go back to the DNS console, click your zone and refresh it (F5). If all is ok you'll now see the 4 SRV record folders.

   If the 4 SRV records are still not present double check the spelling of the zone in the DNS server. It should be exactly the same as the AD Domain name. Also check the computer's suffix (see step 1). You won't be able to change the computer's suffix after the AD is installed, but if you have a spelling mistake you'd be better off by removing the AD now, before you have any users, groups and other objects in place, and then after repairing the mistake - re-running DCPROMO.

   

7. Check the NTDS folder for the presence of the required files.
8. Check the SYSVOL folder for the presence of the required subfolders.
9. Check to see if you have the SYSVOL and NETLOGON shares, and their location.

If all of the above is ok, I think it's safe to say that your AD is properly installed.

If not, read Troubleshooting Dcpromo Errors and re-read steps 1-4 in this article.