 TechNet Magazine February 2007

TechNet Magazine February 2007

Windows Administration: Inside the Windows Vista Kernel: Part 1

With Windows Vista, changes to the OS kernel bring about advances in many areas, ranging from memory management to reliability to security. We kick off this series with a look at how the kernel delivers improvements in the areas of processes, threads, and I/O.

Mark Russinovich Windows Administration: Delegating Authority in Active Directory

Implementing delegation in Active Directory can enhance security and simplify management tasks, and getting started is easier than you think. Here are some simple delegation models that will work in most IT infrastructures with little modification.

Joel Yoker and Rob Campbell Windows Administration: Dig into New Group Policy Templates in Windows Vista

Windows Vista introduces significant changes to Group Policy templates. Find out everything you need to know about the new format, called ADMX, and how these changes will improve the administration of system configurations.

Darren Mar-Elia Windows Administration: Your Guide to Group Policy Troubleshooting

Getting to the bottom of Group Policy issues can be a difficult process, but understanding how Group Policy works, and where problems can arise, makes things easier. This overview will help you troubleshoot Group Policy issues like a guru.

Derek Melber Windows Administration: Monitoring Active Directory with MOM

Management packs for Microsoft Operations Manager 2005 allow you to more effectively monitor your IT infrastructure. See how these five management packs can help you keep an eye on the health, security, and reliability of your Active Directory environment.

John Hann Windows Administration: Gaming in a Secure Environment

Whether you’re busy at work or doing some serious gaming at home, running as a limited user has many security benefits. Unfortunately, some games don’t want to work when they’re not run as administrator. Here’s a look at some common problems and their solutions.

Matt Clapham From the Editor: Under the Covers

Joshua Trupin Toolbox: New Products for IT Pros

Greg Steen SQL Q&A: Database Size, Mirroring, Marked Transactions, and More

Edited by Nancy Michell Utility Spotlight: Group Policy Inventory

Greg Steen The Cable Guy: QoS Support in Windows

Joseph Davies Windows PowerShell: Scripting One Line at a Time

Don Jones Hey, Scripting Guy!: Chasing Cars… and XML

The Microsoft Scripting Guys Security Watch: Deploying EFS: Part 1

John Morello The Desktop Files: Extending Windows PE

Wes Miller Field Notes: It Just Stops Working

R'ykandar Korra'ti Windows Confidential: A "Mixed" Blessing

Raymond Chen


 Windows Administration: Inside the Windows Vista Kernel: Part 1
This article is the first part of a three part series. Click here to read Part Two. Click here to read Part Three.

Windows Administration Mark Russinovich

Inside the Windows Vista Kernel: Part 1
At a Glance:
  • Thread priority and scheduling
  • File-based symbolic links
  • Canceling I/O operations

This is the first part of a series on what's new in the Windows Vista kernel. In this issue, I'll look at changes in the areas of processes and threads, and in I/O. Future installments will cover memory management, startup and shutdown, reliability and recovery, and security.
The scope of this article comprises changes to the Windows Vista™ kernel only, specifically Ntoskrnl.exe and its closely associated components. Please remember that there are many other significant changes in Windows Vista that fall outside the kernel proper and therefore won't be covered. This includes improvements to the shell (such as integrated desktop search), networking (like the new IPv6 stack and two-way firewall), and the next-generation graphics model (such as Aero™ Glass, Windows® Presentation Foundation, the Desktop Window Manager, and the new graphics driver model). Also not covered are the new Windows User-Mode and Kernel-Mode Driver Frameworks (UMDF and KMDF) since these are back-level installable on earlier versions of Windows.

CPU Cycle Counting
Windows Vista includes a number of enhancements in the area of processes and threads that include use of the CPU cycle counter for fairer CPU allocation and the new Multimedia Class Scheduler Service (MMCSS) that helps media applications deliver glitch-free playback.
All versions of Windows NT® up to and including Windows Vista program an interval-timer interrupt routine to execute approximately every 10 or 15 ms (milliseconds), depending on the hardware platform. The routine looks at what thread it interrupted and updates the thread's CPU usage statistics as if that thread had run for the entire interval, while in reality the thread might have started executing just before the interval's end. Further, the thread might have been technically assigned the CPU, but didn't get a chance to run because hardware and software interrupt routines executed instead.
While clock-based time accounting might be OK for diagnostic tools that report thread and process CPU usage, use of that method by the thread scheduler can cause unfair CPU allocation. By default, on client versions of Windows threads are permitted to run up to 2 clock ticks (6 if in the foreground). However, the thread might get virtually no time on the CPU or up to 6 ticks (18 if in the foreground), depending on its behavior and other activity on the system.
Figure 1 shows the unfairness that can occur when two threads that have the same priority become ready to run at the same time. Thread A runs until the next time-slice interval expiration when the scheduler assumes it has run for the entire interval and so decides that Thread A's turn is finished. Furthermore, Thread A gets unfairly charged for the interrupt that occurred during its turn. At the next interval, the scheduler picks Thread B to take over and it runs for a full interval.
Figure 1 Unfair Thread Scheduling
Figure 1 Unfair Thread Scheduling
In Windows Vista, the scheduler uses the cycle counter register of modern processors to track precisely how many CPU cycles a thread executes. By estimating how many cycles the CPU can execute in a clock interval, it can more accurately dole out turns on the CPU. In addition, the Windows Vista scheduler does not count interrupt execution against a thread's turn. This means that on Windows Vista a thread will always get at least its turn on the CPU and never more than an extra clock interval of execution, resulting in greater fairness and more deterministic app behavior. Figure 2 shows how Windows Vista responds to the scenario shown in Figure 1 by giving both threads at least one time slice interval of execution.
Figure 2 Windows Vista Cycle-Based Scheduling
Figure 2 Windows Vista Cycle-Based Scheduling
The "Watching Process CPU Usage" sidebar illustrates how you can monitor process CPU cycle usage for yourself by using the Process Explorer utility.

Multimedia Class Scheduler Service
Users expect multimedia applications, including music and video players, to offer a seamless playback experience. However, demand for the CPU by other concurrently running applications, like antivirus, content indexing, or even the mail client, can result in unpleasant hiccups. To provide a better playback experience, Windows Vista introduces MMCSS to manage the CPU priorities of multimedia threads.
A multimedia app like Windows Media® Player 11 registers with MMCSS using new APIs that indicate its multimedia characteristics, which must match one of those listed by name under the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks
The various task keys specify how much preference threads associated with different multimedia types get for CPU and graphics processor resources (though graphics processor resource management is not implemented in Windows Vista). Figure 3 shows the contents of one of the task registry keys after a clean Windows Vista installation, though third-party developers can add their own task definitions.
Watching Process CPU Usage
You can see the inaccuracy of the Windows standard clock-based time accounting using the Process Explorer utility from Sysinternals. Run Process Explorer on a Windows Vista system and add the Cycles Delta column to the process view. Cycles Delta shows the number of cycles the threads of each process execute between Process Explorer updates. Because CPU time accounting is still based on the interval timer, if you also add the CPU Time column, then you'll see many processes that have threads consuming millions of CPU cycles and yet don't have their CPU time updated and don't show up in the CPU usage column.
Figure A Viewing CPU Time and Cycles Delta in Process Explorer
Figure A Viewing CPU Time and Cycles Delta in Process Explorer

Figure 3 Multimedia Class Scheduler Audio Task Definition
Figure 3 Multimedia Class Scheduler Audio Task Definition
MMCSS, which is implemented in %SystemRoot%\System32\Mmcss.dll and runs in a Service Host (Svchost.exe) process, has a priority-management thread that runs at priority 27. (Thread priorities in Windows range from 0 to 31.) This thread boosts the priority of registered multimedia threads into the range associated with the Scheduling Category value of their task's registry key as listed in Figure 4. In Windows, thread priorities 16 and higher are in the real-time priority range and higher than all other threads on a system (with the exception of the kernel's Memory Manager worker threads, which run at priorities 28 and 29). Only administrative accounts, like the Local System account in which MMCSS executes, have the Increase Priority privilege that's required to set real-time thread priorities.
Figure 4 MMCSS Thread Priorities (Close Figure 4)

Scheduling Category | Boosted Thread Priority
High | 23-26
Medium | 16-23
When you play an audio file, Windows Media Player registers Audio task threads, and when you play a video, it registers Playback task threads. The MMCSS service boosts all threads that have indicated that they are delivering a stream at the same time when they are running in the process that owns the foreground window and when they have the BackgroundOnly value set to True in their task's definition key.
But while MMCSS wants to help multimedia threads get the CPU time they need, it also wants to ensure that other threads get at least some CPU time so that the system and other applications remain responsive. MMCSS therefore reserves a percentage of CPU time for other activity, specified in the following registry value:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
By default, this is 20 percent; MMCSS monitors CPU usage to ensure that multimedia threads aren't boosted for more than 8 ms over a 10 ms period if other threads want the CPU. To get the multimedia threads out of the way for the remaining 2 ms, the scheduler drops their priorities into the 1-7 range.
You can see how MMCSS boosts thread priority by reading the "Watching MMCSS Priority Boosting" sidebar.

File-Based Symbolic Links
The Windows Vista I/O-related changes include file-based symbolic links, more efficient I/O completion processing, comprehensive support for I/O cancellation, and prioritized I/O.
A file system feature many have considered missing from NTFS, the symbolic file link (or as it's called in UNIX, the soft link) finally arrives in Windows Vista. The Windows 2000 version of NTFS introduced symbolic directory links, called directory junctions, which allow you to create a directory that points at a different directory, but until the Windows Vista version, NTFS has only supported hard links for files.
A major difference in the way Windows resolves symbolic links and directory junctions is where the processing takes place. Windows processes symbolic links on the local system, even when they reference a location on a remote file server. Windows processes directory junctions that reference a remote file server on the server itself. Symbolic links on a server can therefore refer to locations that are only accessible from a client, like other client volumes, whereas directory junctions cannot. To address this, Windows Vista supports the new symbolic link type for both files and directories.
Many file system commands have been updated to understand the implications of symbolic links. For example, the Delete command knows not to follow links, which would result in deletion of the target, but to delete the link instead. However, because not all applications may handle symbolic links correctly, creating a symbolic link requires the new Create Symbolic Link privilege that only administrators have by default.
You can create a symbolic link from a command prompt with the Mklink command. The command prompt's built-in directory command identifies a symbolic link by flagging it with <SYMLINK> and showing you the target in brackets, as shown in Figure 5. Windows Explorer is also symbolic-link-aware and shows them with the short-cut arrow. You can see the target of a link in Explorer by adding the Link Target column to the browsing window.
Watching MMCSS Priority Boosting
You can witness the thread boosting that the MMCSS service applies to Windows Media Player threads by playing a video or audio clip, running the Performance Monitor, setting the graph scale to 31 (the highest Windows thread priority), and adding the Priority Current counter for all instances of the Windows Media Player (Wmplayer.exe) thread objects to the display. One or more threads will run at priority 21.
Figure B Thread Priority Boosting for Windows Media Player
Figure B Thread Priority Boosting for Windows Media Player

Figure 5 Using Mklink to Create a Symbolic Link
Figure 5 Using Mklink to Create a Symbolic Link

I/O Completion and Cancellation
There are a number of under-the-hood changes to the I/O system that can improve the performance of server applications. These applications commonly use a synchronization object called a completion port to wait for the completion of asynchronous I/O requests. Prior to Windows Vista, when such an I/O completed, the thread that issued the I/O would execute I/O completion work, causing a switch to the process the thread belongs to and interrupting whatever else was going on. Then the I/O system would update the completion port status to wake up a thread waiting for it to change.
On Windows Vista, the I/O completion processing is performed not necessarily by the thread that issued the I/O, but instead by the one that is waiting for the completion port to wake it up. This relatively minor change avoids needless thread scheduling and context switches that can degrade the application's and the system's overall performance. To improve performance further, a server can retrieve the results of multiple I/O operations from a completion in one request, avoiding transitions to kernel mode.
Probably the most visible change in the I/O system from an end-user perspective is Windows Vista support for canceling synchronous I/O operations. If you've ever performed a net view command or attempted to access a share to an off-line remote system using Windows XP or Windows Server® 2003, you've experienced the problems with I/O operations that can't be canceled: the command or file browser won't respond until a network timeout expires. An application has no choice but to wait until the operation fails because there's no way for it to tell the device driver executing the I/O that it doesn't care about the I/O anymore.
In Windows Vista most I/O operations can be canceled, including the open file I/O that Net View and Explorer use. Applications have to be updated to respond to end-user requests to cancel I/O, however, and many of the Windows Vista utilities that interact with devices that have timeouts have the necessary support. The file open and save dialogs that are used by virtually every Windows application, including third-party applications, for example, now enable their Cancel button while trying to display the contents of a folder. The Net command also cancels its synchronous I/O when you press Ctrl+C.
You can see the benefits of I/O cancellation by opening a command prompt on Windows Vista and typing:
net view \\nonexistentmachine
The command will hang while Windows tries to contact the nonexistent system, but you can type Ctrl+C to terminate it. In Windows XP, Ctrl+C has no effect and the command doesn't return until the network operation times out.
Another type of I/O that has caused users problems in past versions of Windows are those that device drivers didn't cancel properly because there was no easy way for them to know that they should. If you've ever terminated a process, but subsequently saw it lingering in process-viewing tools, then you've witnessed a device driver failing to respond to a process termination and canceling I/O issued by the process that hadn't completed. Windows can't perform final process cleanup until all the process' I/O has either finished or been canceled. In Windows Vista, device drivers easily register for notification of process terminations and so most of the un-killable process problems are gone.

I/O Priority
While Windows has always supported prioritization of CPU usage, it hasn't included the concept of I/O priority. Without I/O priority, background activities like search indexing, virus scanning, and disk defragmenting can severely impact the responsiveness of foreground operations. A user launching an app or opening a document while another process is performing disk I/O, for example, experiences delays as the foreground task waits for disk access. The same interference also affects the streaming playback of multimedia content like songs from a hard disk.
Windows Vista introduces two new types of I/O prioritization in order to help make foreground I/O operations get preference: priority on individual I/O operations and I/O bandwidth reservations. The Windows Vista I/O system internally includes support for five I/O priorities as shown in Figure 6, but only four of the priorities are used (future versions of Windows may support High).
Figure 6 Windows Vista I/O Priorities (Close Figure 6)

I/O Priority | Usage
Critical | Memory manager
High | Unused
Normal | Default priority
Low | Default task priority
Very low | Background activity
I/O has a default priority of Medium and the Memory Manager uses Critical when it wants to write dirty memory data out to disk under low memory situations to make room in RAM for other data and code. The Windows Task Scheduler sets the I/O priority for tasks that have the default task priority to Low, and the priority specified by applications written for Windows Vista that perform background processing is Very Low. All of the Windows Vista background operations, including Windows Defender scanning and desktop search indexing, use Very Low I/O priority.
Seeing Very Low I/O Priority
Process Monitor, a real-time file system and Registry monitoring utility from Sysinternals, collects detailed information for read and write file system operations, including their I/O priorities on Windows Vista. The highlighted line shows an example of a very low-priority I/O that was issued by SuperFetch, (which I'll discuss in my next installment).
Figure C Viewing Very Low I/O Priority in Proces Monitor
Figure C Viewing Very Low I/O Priority in Proces Monitor

The system storage class device driver (%SystemRoot%\System32\Classpnp.sys) enforces I/O priorities and so they automatically apply to I/O directed at most storage devices. The class and other storage drivers insert Medium I/Os ahead of those that are Low and Very Low in their queues, but issue at least one waiting Low or Very Low I/O every second so that background processes can make forward progress. Data read using Very Low I/O also causes the Cache Manager to immediately write modifications to disk instead of doing it later, and to bypass its read-ahead logic for read operations that would otherwise preemptively read from the file being accessed. Take a look at the sidebar "Seeing Very Low I/O Priority" for an example of Very Low I/O priority using the Process Monitor utility.
The Windows Vista bandwidth reservation support is useful for media player applications and Windows Media Player uses it, along with MMCSS priority boosts, to deliver nearly glitch-free playback of local content. A media player application asks the I/O system to guarantee it the ability to read data at a specified rate and, if the device can deliver data at the requested rate and existing reservations allow it, it gives the app guidance as to how fast it should issue I/Os and how large the I/Os should be. The I/O system won't service other I/Os unless it can satisfy the requirements of apps that have made reservations on the target storage device.
One final change in the I/O system worth mentioning relates to the size of I/O operations. Since the first version of Windows NT, the Memory Manager and the I/O system have limited the amount of data processed by an individual storage I/O request to 64KB. Thus, even if an application issues a much larger I/O request, it's broken into individual requests having a maximum size of 64KB. Each I/O incurs an overhead for transitions to kernel-mode and initiating an I/O transfer on the storage device, so in Windows Vista storage I/O request sizes are no longer capped. Several Windows Vista user-mode components have been modified to take advantage of the support for larger I/Os, including Explorer's copy functionality and the command prompt's Copy command, which now issue 1MB I/Os.

Next Up
Now you've seen two areas in which the Windows Vista kernel has been enhanced. You can expect additional in-depth information in the next edition of my book, Windows Internals (coauthored with David Solomon), planned for release at the same time as the next version of Windows Server, code-named "Longhorn." In my next installment, I'll continue introducing you to the new kernel by discussing memory management along with system start up and shutdown.

Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division. He is a coauthor of Microsoft Windows Internals (Microsoft Press, 2004) and a frequent speaker at IT and developer conferences. He joined Microsoft with the recent acquisition of the company he cofounded, Winternals Software. He also created Sysinternals, where he published the Process Explorer, Filemon, and Regmon utilities.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Windows Administration: Delegating Authority in Active Directory
Windows Administration Joel Yoker and Rob Campbell

Delegating Authority in Active Directory
At a Glance:
  • Defining administrative roles
  • Developing an OU and security group model
  • Using secondary accounts
  • Tools for delegating rights

The delegation capabilities in Active Directory are quite powerful, addressing a number of security issues and simplifying management tasks. By properly delegating rights within Active
Directory®, you can enforce specified roles in the environment, limit the impact and likelihood of administrative error, and apply the principle of least privilege throughout your infrastructure. Yet many of the organizations that rely on Active Directory have yet to tap into the power of delegation. In part, this is because, on the surface, developing an Active Directory delegation model for your enterprise appears to be fairly complex. While the largest hurdle is to develop a delegation model that fits the unique needs of your organization, the truth is that there are very simple models that can be applied to most IT infrastructures with little modification.
Although every environment is different in some way, shape, or form, the reality is that most large enterprises are similar in many ways and face the same IT challenges. For instance, many organizations are divided into geographic regions, have evolved from separate IT engineering or operational support teams, and have independent business units. And many large organizations must deal with such matters as privilege escalation, service account abuse, and "trust."
Trust is an interesting term and often becomes the justification for having multiple Active Directory forests. Trust issues frequently stem from one division's or region's ability to impact the system availability of another division or region. It's common for skill levels to differ across organizational boundaries and for there to be a lack of in-depth knowledge of specific systems required to support a particular region or business unit. Thus, divisions typically don't want to give up their administrative rights to a central group.
Meanwhile, for any Active Directory implementation, the administrators must define the rules of engagement for applications that utilize the Active Directory infrastructure. Unfortunately, a common approach-one that is often cited in application installation guides-is to make a service account a member of the Domain Admins group. The problem with this approach is that service accounts are essentially generic accounts. By granting these accounts Domain Administrator rights, you present a significant threat to the IT environment. Service accounts can easily fall prey to improper use by malicious or careless administrators or be leveraged by attackers who exploit underlying security issues within an application.
While these hurdles may seem insurmountable, they represent a prime scenario for implementing an Active Directory delegation model. Developing a delegation model is an iterative design process and we suggest you follow these steps:
  1. Define the IT administrative roles within your organization.
  2. Develop an Organizational Unit and Security Group model.
  3. Establish secondary accounts for IT administrators.
  4. Delegate rights.
Let's take a closer look at these steps.

Define Roles
The role definition process starts with a thorough understanding of both service administration and data administration. These concepts are the cornerstone of any Active Directory delegation model.
At its core, service administration is the management of critical directory service infrastructure components, such as Exchange servers and domain controllers. Data administration is the management of objects, such as mailboxes and user accounts that reside within these services. Within the scope of Active Directory, service administrators are ultimately responsible for the delivery and availability of directory services while data administrators manage user and server accounts, groups, and other domain resources.
Active Directory supports granular delegation of authority through Organizational Units (OUs). OUs can frequently be tailored to provide the same level of authority that is available to administrators within the existing directory service or domain models. But it is important to understand that some functions simply cannot be delegated and must be managed by a single, well-trusted group or entity.
Task analysis is also critical. You need to know which Active Directory tasks are carried out by administrators and how those tasks are mapped to roles. For example, Active Directory site creation is a service administration task, while modification of security group membership generally falls under data administration. Each task should be evaluated for frequency, importance, and difficulty. These are vital aspects of task definition because they govern whether a right should be delegated. Tasks that are performed routinely, have limited risk, and are trivial to complete are excellent candidates for delegation. On the other hand, tasks that are performed rarely have great impact across the organization, and require high skill levels are poor candidates for delegation. Instead, escalation (temporarily elevating an account to the required role or reassigning the task) is the proper path for these tasks.
Since many characteristics of large organizations are similar, it's safe to assume that a common delegation model can be implemented. For the purposes of this article, we'll provide a sample set of roles that enable management capabilities while respecting organizational boundaries and attempting to mitigate trust issues (such as the availability of enterprise wide assets like domain controllers). Note that this model is just an example-it's a great start for roles discussion within your organization, but you shouldn't plan on using this guidance verbatim.
Some roles are already defined by Active Directory and some must be created from scratch to round out the delegation model. An example set of roles that would fit many large Active Directory environments might include Enterprise Admins, Domain Admins, and Tier4 Admins for service administration, and Tier3 Admins, Regional Admins, Tier2 Admins, and Tier1 Admins for data administration. See Figure 1 for a list of these roles and their responsibilities.
Figure 1 Define Roles and Responsibilities (Close Figure 1)

Service Administrators | Description
Enterprise Admins | Responsible for top-level service administration across the enterprise. Should contain no permanent members.
Domain Admins | Responsible for top-level service administration across the domain. Should contain only a small, manageable number of trusted administrators.
Tier 4 Admins | Responsible for service administration across the domain. Granted only the rights necessary to manage necessary services. Serves as an escalation point for data administrators.
Data Administrators | Description
Tier 1 Admins | Responsible for general management of directory objects, performing tasks such as password resets, modifying user account properties, and so on.
Tier 2 Admins | Responsible for the selective creation and/or deletion of user and computer accounts for their locale or organization.
Regional Admins | Responsible for the management of their local OU structure. Granted permissions to create most objects within their OU.
Tier 3 Admins | Responsible for management of all data administrators. Serves as top-tier help desk and escalation point for all regional admins.

Service Administrators
Let's take a closer look at the service administrator roles. Service administrators manage critical infrastructure components and all of the admins who fall into this category are highly privileged. Therefore, a strategy of least privilege, which means only granting the minimum set of permissions necessary to perform the required tasks, is highly recommended in this case.
Enterprise and Domain Admins Active Directory defines two groups of special administrators whose security context is required for critical functions within the directory. These groups-Enterprise Admins and Domain Admins-are responsible for top-level service administration. To mitigate the risks inherent in such highly privileged groups, we strongly advise constraining membership to these groups. In fact, the Enterprise Admins group should have no permanent members and the Domain Admins groups should contain only a small, manageable number of trusted individuals who work for the organization on a full-time basis.
When enterprise administration tasks such as DHCP server authorization or Active Directory site creation need to be performed, the Domain Admins in the root domain of the Active Directory forest can escalate privileges by managing the membership of the Enterprise Admins group. These privileges should only be granted for short periods of time in order to avoid the creation of permanent members in the Enterprise Admins group. Of course, all members of a Domain Admins group in a given Active Directory forest must be trusted equally.
A common pitfall that catches most organizations when developing a delegation model is disabling or crippling these built-in roles. Modification of the default roles can cause unpredictable results, and there is no guarantee that service pack revisions or product upgrades would retain these settings. In addition, this type of modification creates an unsupported environment outside the organization. A practical approach is to use the built-in groups and roles but limit membership. To do this, you'll probably have to create new roles for administrators who previously relied on membership in groups like Domain Admins.
Tier4 Admins The Tier4 Admins group should consist of centralized service administrators who provide support for all enterprise services. Since this is a created role, directory service and system access permissiions can be tailored to the specific requirements of your organization. While members of this group are service administrators, they may also perform occasional forest-wide data management tasks. Since there are many classes of systems and different areas of responsibility, Tier4 roles are broken into various sub-groups within the directory. For example, separate Tier4 groups should be created to provide discrete management of specific systems, such as Exchange servers. This group also serves as an escalation point for data administrators.
One reason people often want to be granted membership in the Domain Admins group is to gain administrative rights over every system in a given domain. The trick to making these service administrators run in least-privilege mode is to grant Tier4 Admins control of enterprise servers without making them Domain Admins. In order to prevent privilege escalation, Tier4 Admins should not be granted membership in the BUILTIN\Administrators group on domain controllers since that group has many underlying rights to the directory service that cannot be separated. For instance, a member of the BUILTIN\Administrators group of a given domain can manage the membership of the Domain Admins group, allowing members to escalate privileges without any checks and balances.
Remembering our rule about not crippling default permissions, this risk can be mitigated by making the Tier4 groups nested members of the Server Operators and DNS Admins built-in domain groups. This allows for the local management of domain controllers while limiting the ability of Tier4 Admins to escalate privileges. For most systems (other than Domain Controllers, Certificate Servers, and so on), you should make the Tier4 Admins group a member of the local Administrators group. Automation of nested local group membership can be achieved with the Restricted Groups functionality in Group Policy.

Data Administrators
Now let's dive into the data administration roles. These should be designed with cumulative rights, meaning that a Tier2 Admin should have all of the rights of a Tier1 Admin along with some additional privileges, and so on. For that reason, we'll look at these groups from the bottom up.
Tier1 Admins The Tier1 Admins group should provide general management of previously created directory objects. This group is for the minimally trained administrator or for those performing isolated tasks, such as password resets. Grant this group the rights within their organizational unit to modify user account properties, reset user account passwords, unlock accounts, enable/disable user accounts, add and reset workstation computer accounts, and modify group object membership for non-administrative groups.
Tier2 Admins This group should enable selective management and creation of objects, allowing for objects to be created only where they can be managed by Tier1 Admins. (For example, security groups may only be created in the Groups OU). Tier2 Admins can add and modify Tier1 Admin accounts; add, modify, and delete user accounts for an OU; delete Workstation computer objects; and add, modify, and delete Server, Contact, and Shared Folder objects.
Regional Admins This group is granted exclusive rights over their regional OU structure. They cannot, however, manage other regional OU structures within the directory. Regional Admin accounts should be considered highly privileged and, as a result, the accounts are stored in a separate OU hierarchy and managed by the Tier4 Admin service administrators. Regional Admins are permitted to create most objects without restrictions within their OU structure (a notable exception is the creation of other organizational units), which carries the additional risk of creating objects that may not be manageable by lower tiers.
Tier3 Admins Many organizations have a centralized or upper-tier help desk. This role fills out the list of data administrators, providing a data administrator group over all Regional Admins. Rights aren't delegated to these groups specifically within the directory; rather, they are made via nested membership in each Regional Admins group. This provides a top-level escalation point for all data administrators as well as a point of entry for issues to be escalated to the service administration groups.

Build an OU and Security Group Model
Once roles are defined in the organization, an OU and security group model must be defined. There are two primary reasons to create an OU in Active Directory: delegation of rights and creation of a point where Group Policy Objects can be linked. OUs define a scope-of-management (SOM) within the directory and these can be used to constrain rights to objects at various levels. As a result, how you choose to delegate authority should be a primary factor in how you implement your OU structure.
With this in mind, a top-level OU (or series of OUs) should be created directly beneath the domain to house all objects. This OU serves the specific purpose of defining the highest-level SOM for the Tier4 Admins. By creating a top-level OU, rights over the directory service can start explicitly at the OU level rather than at the domain level. Delegation from a top-level OU rather than from the domain mitigates the risk of users having the ability to escalate privileges through the manipulation of the built-in domain groups we noted earlier.
Below the top-level OUs, you should create separate sub-OU hierarchies to represent each region or business unit that has a discrete data management team. Each regional sub-OU should have a common, non-extensible OU hierarchy for management of directory objects. Uniformity is critical to ongoing management since much of the delegation of rights will be automated. This is a tall order, as each region may desire unique OUs. But IT administrators must stick to their guns, and if an extension is required for one region, the sub-OU structure should be extended for all regions. This may seem hard in the beginning, but if the organization provides generic housing for objects, outlying situations tend to fall in place over time.
Finally, create separate sub-admin groups and accounts to remove administrators ability to escalate their privileges-a Tier1 Admins, Tier2 Admins, and Regional Admins group for each sub-OU hierarchy. Placing these accounts in separate OUs allows the restriction of management to their level or below. Thus, if all Tier1 Admins accounts and the associated security group reside in an OU where they do not have rights, admins won't be able to hijack other admin accounts or escalate the privileges of other administrators to their level. Any member of the Domain Admins group, for example, can make any other user account in the domain a Domain Admin. However, with this OU model in place, that risk is mitigated. An example OU structure with associated security groups is shown in Figure 2.
Figure 2 OU Structure and Associated Security Groups
Figure 2 OU Structure and Associated Security Groups

Establish Secondary Accounts
The key to a successful delegation model is enforcing the principle of least privilege. In practice, this means that a security principal should have only the ability to perform the tasks required for its given role and nothing more. Unfortunately, many IT administrators use the same security principal for directory administration and for everyday tasks like Web browsing and reading e-mail. Having separate accounts decreases the likelihood that a tiered administrator will damage the directory service by mistake or fall victim to an attack that is delivered via everyday applications but targeted at the directory administrator.
To accomplish this without requiring the user to log off and back on, you use the Secondary Logon service (Runas.exe). This allows users to elevate their privileges by providing an alternate set of credentials when executing scripts or executables on servers and workstations.
While the concept of using least-privileged accounts is relatively simple, organizations sometimes find it hard to enforce as old IT habits may be rather difficult to break. A straightforward approach to preventing the use of privileged accounts for everyday tasks is to not provide mail access to these accounts in Exchange Server, enforcing this through administrative policy within the organization. This relatively simple approach significantly reduces the likelihood that such accounts will be used for routine, non-administrative tasks.

Delegate Rights
The final step in developing a delegation model is the actual delegation of rights within Active Directory. This entails the manipulation of access control entries (ACEs) and access control lists (ACLs) on data stored within the directory. ACLs on Active Directory containers define what objects can be created and how those objects are managed. Delegation of rights involves basic operations on objects, such as the ability to view an object, create a child object of a specified class, or read attribute and security information on objects of a specified class. Besides these basic operations, Active Directory defines Extended Rights, which enable operations such as Send As and Manage Replication Topology.
In previous steps, we discussed creating security groups that map to defined organizational roles. This means that for every role there is an associated security group by sub-OU structure. To implement the delegation model, these groups need to be assigned permissions over the objects in the directory. At this point in the process, you don't want to reinvent the wheel and create a highly customized environment. Instead, try to leverage built-in groups and rights where possible. Say a particular role needs to manage DNS records for the forest. Don't attempt to delegate rights over the containers and naming contexts related to Active Directory-integrated DNS; instead, simply leverage the BUILTIN\DNS Admins group in the domain. In addition, User Rights and other permissions can be extended through Group Policy to provide the additional rights required to manage a specific class of system by a given role.
When assigning permissions using delegation, you should limit or even completely eliminate the use of Deny ACEs within the directory. These can get tricky when it comes to troubleshooting. A better approach is to make use of explicit Allow ACEs to grant rights to the custom groups representing your roles. Remember that user-defined roles, such as Tier4 Admins, will only have the explicit rights defined by that role.
Inheritance is critical to Active Directory security and defines how a particular ACL applies to child objects in a given container or sub-container. Always be specific about the scope of inheritance by ensuring inheritable ACEs are applied as close to the target objects as possible. Inheritable deny permissions applied on the parent object will precede any inheritable deny permissions applied on the grandparent object, which is one of the main reasons why Deny ACEs are not recommended for practical delegation. Moreover, inheritable permissions cannot override an explicit ACE on an object. For that reason it is recommended that you limit or eliminate the ability for tiered administrators to modify the discretionary access control list (by removing the Write DACL privilege) on directory objects. (Note that the creator of the object has these rights implicitly.) The rule of thumb is that if an administrator has the ability to change the DACL on an object, he probably will. Don't let the hard work your organization has put into its delegation model go to waste by introducing choice and potential administrative error.
There are a number of tools you'll need to use to properly implement an Active Directory delegation model. For most large organizations, using the built-in Delegation Wizard for assigning permissions in the directory is a daunting task rife with the possibility of administrative error. Instead, automation should always be used to ensure that the delegation model is well documented, that it's supportable, and that it provides a recovery option in case settings are somehow lost or changed inadvertently.
The primary tool required for implementing delegation is DSACLS.EXE, a command-line tool used to manipulate directory service ACLs on objects. This tool also allows for the inheritance flags for a DACL to be specified on the parent object. (Inheritance flags include this object and sub-objects, sub-objects only, and propagate inheritable permissions one level only.) DSACLS commands will ultimately fail if an inheritance flag is set improperly, so testing is crucial when using this tool. Here's an example of the DSACLS syntax for delegating the ability to create computer objects in the target demo OU:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS is case-sensitive with respect to object types. This means that attempting to delegate permissions for the "cn=Computer" object class over the "cn=computer" will not work (see Figure 3).
Figure 3 Error Due to Case Sensitivity
Figure 3 Error Due to Case Sensitivity
A specific set of rights is required for creating some objects. This has to do with "must contain" and "may contain" attributes on objects. The best metaphor I've heard to explain this concept is the hamburger model. Hamburgers must contain a meat patty and a bun to be considered a hamburger. Those are the must-contain attributes of the hamburger object class. Items such as pickles, ketchup, lettuce, and so on are may-contain attributes. If we extend the object class to define a cheeseburger, we would add cheese to the list of must-contain attributes.
User objects work the same way. Let's say we were to follow this model to create User objects using the following DSACLS syntax:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
The administrator would be confronted with several errors during user object creation. We need to grant the privileges necessary to set required attributes on the user object, including setting the password. This is outlined in the following additional DSACLS syntax.
For the first step, grant the privilege to write must-contain attributes by granting Generic Read/Generic Write to all attributes of the user class:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
For the next step, grant the extended right to change the password:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
For the final step, grant the privilege to Read Property and Write Property of Password Last Set attribute:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
Once the proper rights have been delegated, the defined roles will be limited to only managing object classes defined in the container's DACL. Using the previous computer object example, the context menu in Active Directory Users and Computers restricts the list of new objects that can be created by the user who is delegated such rights (see the restricted list in Figure 4).
Figure 4 Restricted List of New Objects
Figure 4 Restricted List of New Objects
DSACLS can also be automated to provide a complex deployment of rights. Here are some of the DSACLS commands that can be used to delegate rights to manipulate common address attributes over user objects in a given container:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Examples such as these are common for most delegation models and can be used in conjunction with the previously defined roles.
Another tool used for implementing delegation is DSREVOKE.EXE, which allows administrators to locate and remove delegated rights for specific security principals on objects within the directory. While this tool can be very useful, it is specific to a security principal and does not evaluate nested membership inside security groups.
Beyond these command-line tools, we also highly recommend the use of User Rights Assignment and Restricted Groups with Group Policy. As discussed earlier, User Rights Assignment allows IT administrators to extend or remove low-level rights (such as the right to remotely access and restart a system) for various groups of users on specific target systems. Restricted Groups can be used to specify and enforce local and domain group membership within the forest. In combination, these tools provide everything you need to automate and implement an Active Directory delegation model.

Summary
Though the task of developing an Active Directory delegation model may seem complex, the truth is that very simple models can be applied to most IT infrastructures. One of the most important steps in deploying a practical delegation model is to define clear roles. You should limit the defined roles to a small, manageable number. The balance is tricky, as too many roles will result in roles not being used while too few roles won't allow for role separation.
Remember, when defining tasks, categorize them by frequency, importance, and difficulty. Once you define the roles, develop a set of use cases to help identify what each role can or cannot do and automate the testing process. Well-prepared use cases will help you explain these roles to the stakeholders in your organization and mitigate any surprises due to automation errors.
Finally, it's always a good idea to take a practical approach when developing a delegation model. Remember, simplicity equals supportability and a sustainable delegation model will pay huge dividends in controlling administrative rights within your Active Directory environment.
Additional Resources
  • Design Considerations for Delegation of Administration in Active Directory
  • Best Practices for Delegating Active Directory Administration

Joel Yoker is a Senior Consultant on the Microsoft Federal team. Joel and Rob are both focused on developing and deploying security solutions for United States Federal government customers.
Rob Campbell is a Senior Technical Specialist on the Microsoft Federal team. Joel and Rob are both focused on developing and deploying security solutions for United States Federal government customers.


 Windows Administration: Dig into New Group Policy Templates in Windows Vista
Windows Administration Darren Mar-Elia

Dig into New Group Policy Templates in Windows Vista
At a Glance:
  • Inside ADMX
  • Editing ADMX files
  • How ADM and ADMX files differ
  • Creating a Central Store

Prior to Windows Vista, the registry values you could set within Group Policy were governed by ADM files, whose syntax was cryptic and proprietary. If you wanted to control additional registry values beyond the ones Microsoft shipped with the standard ADM files, you had to learn this
syntax and create a custom ADM file. In addition, these ADM files were stored with each Group Policy Object (GPO) in your Active Directory® environment, and each of these GPOs with the accompanying ADM files were replicated to all domain controllers in the domain.
With the release of Windows Vista™, Microsoft takes a major step in the area of Group Policy-based registry templates. Windows Vista introduces significant changes in both the format of the ADM file, now called ADMX, and the way in which these files are stored. In this article, I'll take a look inside the new ADMX format and discuss how these files are different from ADM. I'll also look at how storage of these files is handled in a Windows Vista environment.

ADMX Differences
The biggest difference between the new ADMX file format and the old ADM format that's been around since Windows NT® 4.0 is that ADMX has adopted the XML standard for describing registry policy settings. This is good for several reasons. The first is that there are many more tools for editing XML than for the ADM syntax. The second is that, because XML is schematized, it will eventually become easier to build tools that help you know the right tags to put in the right places to create a well-formed ADMX file. What schematized means is that, for a given application of XML such as the ADMX format, there's a documented schema that describes the elements and attributes that are possible, and how they are organized. We'll look at an example later in the article.
The other key difference between ADMX and ADM is the separation of the strings section of the main ADMX file into a language-specific ADML file. If you're familiar with ADM files, you know that at the end of every file there's a section delimited with a "[strings]" tag where you could assign values to strings of text you wanted to appear when using the Group Policy Editor and Administrative Templates. For example, the text you saw when you clicked on the Explain tab on a given policy was stored within that strings section. The problem with this is that the strings were stored within the ADM file, so if you wanted to use that ADM on a Windows® system running a different language, you had to create a new ADM file with a strings section for that language.
It got even more complicated if someone on, let's say, the French version of Windows, wanted to edit an existing GPO that had used English ADMs. The French admin would only see English in the Group Policy editor. Windows Vista gets around this problem by separating the [strings] section into an XML-based ADM Language (or ADML) file. The ADML file can be shipped in any supported language and can easily be changed to support any new language without having to touch the main ADMX file that stores the policies. More importantly, when that French admin edits a GPO from his Windows Vista workstation, the Group Policy Editor will detect that the French version of Windows is being used and will load the French ADML files for that GPO automatically.
You can see all of the ADMX and ADML files that come with your installation of Windows Vista by opening the folder at c:\windows\policydefinitions (see Figure 1).
Figure 1 ADMX Files in Windows Vista
Figure 1 ADMX Files in Windows Vista
Note that at the top of the file listing in Figure 1, there is a folder called en-us. This is the language-specific folder that contains the ADML files for the ADMX files you see in this PolicyDefinitions folder-in this case for US English. There is one ADML file for each ADMX. As of this writing, Windows Vista contains 132 ADMX/ADML files by default. This is another big difference between Windows Vista and prior versions: Windows XP-created GPOs typically held five ADM files, the largest being System.adm, which held policy items for most of the Windows components under policy control. In Windows Vista, Microsoft decided to break up the ADMX files by function-hence the much larger number of ADMX files. Each ADMX typically covers a single Windows component (such as Control Panel, DNS Client, Windows Explorer, and so on).

Inside the ADMX
That ADMXs are written in XML is a significant improvement, as I noted earlier. However, many administrators don't know how to write XML, let alone understand the schema used by ADMX for creating policy extensions. While a tutorial on custom ADMX creation is beyond the scope of this article, let's look at how ADMXs are formed.
You can open an ADMX or ADML file in any text editor, even Notepad, but unless your editor understands XML syntax, it may not be very meaningful. I use Visual Studio® because its IntelliSense® feature helps you complete particular elements. Figure 2 shows the first few lines from one of the ADMXs that ships with Windows Vista.
Figure 2 Some XML in an ADMX File (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
This may look strange if you're not familiar with XML, but many of these XML elements can be found in any ADMX file. The policyNamespaces element, for example, uniquely identifies this ADMX file within the universe of all ADMX files.
If you created custom ADM files in prior versions of Windows, you know there was a set of tags, such as Category, Policy, ListBox and ActionList, you employed to define the policy settings that would appear in the Group Policy Editor. Many of these tags haven't changed, or have changed only slightly in the ADMX format, but they look much different because they're represented as XML. For example, I had written a custom ADM file that enabled various types of logging within Windows for Group Policy troubleshooting. A section of that custom ADM is shown in Figure 3. I ported this file to the new ADMX format, as shown in Figure 4.
Figure 4 The ADM File Converted to an ADMX File (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 A Custom ADM File (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
In many respects, this ADMX snippet is much simpler to understand than its ADM cousin, as it's more succinct. The policy element specifies what this policy is doing (Folder Redirection Logging). The attributes prefixed with $(string. are references to the corresponding ADML string element. The key and valuename attributes, obviously, specify which registry key and value this policy affects. The parentCategory element controls where this policy appears in the Group Policy Editor Administrative Template hierarchy. The supportedOn element indicates which operating system version respects this policy, and finally, the enabledvalue and disabledvalue elements specify what values are put into the registry when this policy is set to enabled and disabled.
This is a pretty simple on/off policy. As in ADM syntax, it is possible to create more complex UI elements within the Group Policy Editor. When you do that within ADMX, the syntax gets a bit more involved and includes a presentation attribute that references a portion of the ADML file where the UI element's text labels can be found. But beyond this, the ADMX syntax is really not much more complicated. One thing to keep in mind is that some of the tag names have changed between ADM and ADMX. So for example, in ADM parlance you had "edittext" and "listbox" tags. In ADMX, you find those tags referred to as "text" and "list" within the ADMX file. Those elements will have corresponding entries in the ADML file that specifies the text that appears alongside them.
As you may already know, an administrator can load a custom (legacy) ADM file into the Windows Vista Group Policy Object Editor. People often ask me whether Microsoft will provide a utility for converting custom ADM files to the ADMX syntax. In fact, Microsoft teamed with FullArmor Corp. to release a free tool called the ADMX Migrator. This tool does two things. First, it converts your old custom ADM files to the ADMX format (see Figure 5 for an example of using the tool to convert my custom gpolog.adm).
Figure 5 ADMX Migrator
Figure 5 ADMX Migrator
The second thing it provides is an ADMX Editor that lets you create new ADMX files from scratch. You can download this tool at go.microsoft.com/fwlink/?LinkID=77409.

ADMX Storage
The other notable change I want to discuss is how ADMX and ADML files are stored for use. In versions of Windows prior to Windows Vista, when you edited a new GPO, the ADM files were automatically copied up from the local workstation where you performed your editing tasks to the SYSVOL portion of the GPO on a domain controller within your Active Directory domain. These ADMs were then subsequently replicated to every DC in a domain, for every GPO that was created. This wasted a lot of network bandwidth and disk storage, especially in large environments with dozens or hundreds of GPOs. Windows Vista turns this process on its head. By default, when you create an Active Directory-based GPO from a Windows Vista workstation, the Administrative Template policies that appear in the Group Policy Editor are loaded from the c:\windows\policydefinitions folder on the computer you're editing the GPO from.
The ADMX and ADML files are not copied up to SYSVOL-they are only referenced locally. This eliminates the storage and network burden that ADMs put on the Group Policy environment. But it gets even better. Windows Vista also supports a central store, a repository for Administrative Templates. This addresses how you effectively control the ADMX files used to edit GPOs, regardless of who is editing them. You do so by copying all of the official ADMX and ADML files (and any custom ones you create) up to a network location, and then all subsequent Group Policy editing from Windows Vista workstations references those network-based versions instead of each of their individual local ones. Setting up a central store is an easy, one-time-per-domain task. Just follow the steps in the "Creating a Central Store" sidebar.

Summary
The new ADMX format in Windows Vista is a clear improvement over the ADM files used with previous OS versions. The use of XML provides a cleaner framework for editing and searching these files. The moving of language-specific strings into separate files make multi-language Group Policy editing seamless, and the central store eliminates the need to store and update all of your GPOs with copies of ADM files. All this makes learning about ADMX a smart move.
Creating a Central Store
The creation of the central store is relatively straightforward. Follow these simple steps to create one in your Active Directory domain:
Step 1: Open Explorer and navigate to the SYSVOL share on the PDC-emulator DC in your environment (you can use any DC but the PDC role owner is usually where any Group Policy changes are focused).
Step 2: Drill into the Policies folder under SYSVOL and create a new folder called PolicyDefinitions.
Step 3: Copy the contents of the C:\windows\policydefinitions folder on your Windows Vista workstation to the new PolicyDefinitions folder, including the language-dependent ADML folder (for example, en-us on US English computers).
Once the ADMX and ADML files are copied to the Central Store folder, the Group Policy Object Editor on Windows Vista will start referencing the files there, and will ignore the ones stored locally!

Darren Mar-Elia is a Microsoft Group Policy MVP, creator of the popular Group Policy site—www.gpoguy.com and coauthor of Microsoft Windows Group Policy Guide (Microsoft Press, 2005). He is also CTO and founder of SDM Software, Inc. Reach him at Darren@gpoguy.com.


 Windows Administration: Your Guide to Group Policy Troubleshooting
Windows Administration Derek Melber

Your Guide to Group Policy Troubleshooting
At a Glance:
  • Common GPO Issues
  • Group Policy Rules
  • Troubleshooting GPO problems
  • Tools for troubleshooting

Microsoft Active Directory has become a critical component of many IT infrastructures. One of the most important features of Active Directory is Group Policy, which allows administrators to centralize the management of domain controllers, member servers, and desktops.
While Group Policy clearly provides many benefits, it has one small glitch. It can be complex to design and implement in a large organization and even more problematic to troubleshoot when something goes awry. In this article, I'll investigate how Group Policy is structured and show you how to troubleshoot it. By the end, you will have all of the ammunition you need to tackle almost any Group Policy issue.

Troublesome Settings
There are many moving parts within Group Policy, especially in regard to the way it interfaces with the overall Active Directory® design and implementation. When troubleshooting many kinds of access and network issues, you must always include Active Directory and the basics of Group Policy implementation in your search for a solution. To begin the troubleshooting process, let's look at Group Policy settings that can be configured incorrectly, then move on to more complex issues that might cause Group Policy to malfunction.
Group Policy settings are viewed by Active Directory administrators using administrative template files (ADM or ADMX files) and the Group Policy Object Editor, or GPEdit (launched by running gpedit.msc). Using GPEdit, the administrator creates Group Policy Object files, or GPOs. The GPOs are configured to apply (or not apply) to computers and users within the Active Directory structure. There are a number of rules GPOs must follow in order to function correctly. Let's look at them now.
GPO Must Be Linked When a new GPO is created, it may not be linked to any node within Active Directory. Even though the GPO can be edited and modified, it will not affect any objects until it is linked to a node. To ensure that the GPO is properly linked, you can view the information window in the Group Policy Management Console (GPMC) that is shown in Figure 1.
Figure 1 GPO Links Are Clearly Shown
Figure 1 GPO Links Are Clearly Shown
GPO Must Target Correct Object As you know, Group Policy must target the correct objects in Active Directory. However, this is sometimes overlooked in the midst of a troubleshooting exercise. Within a GPO, there are two major categories: computer and user. When you configure a GPO, be sure to note if it is for a computer or user object. Then you can verify that the correct object types are placed in the Organizational Unit (OU) where the GPO is linked.
GPOs Don't Apply to Groups Although you may wish it were so, a GPO cannot apply to an Active Directory security group object. The only two objects that a GPO setting can configure are computers and users. GPOs can't configure objects via group membership. For example, if there is a GPO linked to the Finance OU, as shown in Figure 2 the only objects that will be affected by the setting are Derek and Frank. The settings in the GPO will not affect the members of the Marketing group, no matter who has membership in that group.
Figure 2 Finance OU and the Objects Within It
Figure 2 Finance OU and the Objects Within It
Target Object Must Be in the Path of the GPO When you notice that a GPO setting is not affecting an object as it should, there is one more important setting-the object must be in the Scope of Management (SOM) of the GPO. This means that the object must be located under the node where the GPO is linked (even a child node will be sufficient). For example, none of the objects in the Marketing OU will be affected by a GPO that is linked to the Finance OU, as shown in Figure 3. The SOM of a GPO is from the node where it is linked, down through the Active Directory structure.
Figure 3 When OUs Are at the Same Level, GPOs Only Apply to the OU Where It Is Linked
Figure 3 When OUs Are at the Same Level, GPOs Only Apply to the OU Where It Is Linked
GPO Needs To Be Enabled When a GPO is created, it is not configured to make any modifications to target objects. However, it is enabled for both the computer and user portions. If either of these portions is disabled, it can be tricky to track this down. Therefore, when you are troubleshooting a GPO that will not apply, it is a good idea to check to see if some or all of the GPO is disabled. You can do so by looking under Group Policy Objects | Account Policy in the GPMC and checking the GPO status.
Some Settings Need a Reboot When a GPO setting is not working properly, it might be due to the inherent processing of GPOs. When the periodic background refresh of GPOs is triggered, it can only process some of the GPO settings, but not all. So while you may have created a setting, it may not have taken effect yet. There are some settings that are categorized as Foreground Policies, and they are only applied when the computer is rebooted or the user logs off and then logs back in. Examples of settings that behave this way include software installation, folder redirection, and script application.

Synchronous and Asynchronous Application of Settings
Within a GPO you can configure how policy application occurs at boot time and logon. The changes that you can make will either provide immediate access to the desktop while policies are still applying, or ensure all policies apply before the user has access to the desktop. Figure 4 shows how each operating system behaves by default. If you want to alter this behavior, you can modify the following policy setting:
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Default Processing on Client (Close Figure 4)

Operating System | Startup | Logon | Policy Refresh
Windows 2000 | Synchronously | Synchronously | Asynchronously
Windows XP Professional | Asynchronously | Asynchronously | Asynchronously
Windows Server 2003 | Synchronously | Synchronously | Asynchronously
Most administrators prefer to have a synchronous application of policy, to ensure that all policies are applied before the user can access the desktop. This ensures that all security and configuration settings are applied before any work can be done by the user. Note that this is not the default state in Windows® XP Professional, which was optimized for enhanced logon speed.

Altering Default Inheritance
There are four different methods that can be used to alter the default inheritance of GPO processing. These options are powerful and should be used sparingly, as they can cause significant alterations to the behavior of Group Policy processing. They can also be very difficult to troubleshoot. The options for altering default inheritance include the following four settings and configurations:
  • Block policy inheritance
  • GPO enforcement
  • GPO filtering of the access control list (ACL)
  • Windows Management Instrumentation (WMI) Filters
Since these settings should be used sparingly, it should be easy to document when they are being used. To find out if these options are in use, look in the GPMC. Block inheritance is performed at the domain or organizational unit (OU) node in GPMC. GPO enforcement, filtering of the ACL, and WMI filtering are set on each GPO.
Alternatively you can run the Gpresult command from the target computer to get an idea about whether any of these settings are prohibiting the policies from applying. To get a more in-depth view of the resulting set of policies being applied, you can add the /v switch to the Gpresult command, which will give you the verbose output.

ADM Template Issues
When you are attempting to configure settings in a GPO under the Administrative Templates section, you are working with ADM templates. In addition to the ADM templates that ship with the operating system, you can customize your own for use in a GPO. The code in the ADM template creates the folders and policies in the Group Policy Editor under the Administrative Templates node. However, if the ADM template is corrupt, missing, or not configured properly, it's quite possible that you won't see some or all of the settings in the editor. Here are some other issues to guard against when using ADM templates.
Missing ADM Templates When you edit a GPO and find that there are settings in a custom ADM template that are not showing up in the editor, you need to import the ADM template into the GPO. You do this by simply right-clicking on the Administrative Templates node in the editor and selecting Add/Remove Templates.
Missing Preferences There are two types of settings that can be created in a custom GPO: Preferences and Policies. Policies are the default Microsoft settings that all fall into one of four subkeys in the registry, each ending with the text "Policies". Preferences are "old style" Registry modifications that don't fall under one of the four subkeys, and are difficult to reverse once configured. These preferences don't show up in the editor by default. You must enable them to show up, which is possible when you go under the View menu on the toolbar. From there, select Filtering, then check the "Only show policy settings that can be fully managed" checkbox. This will immediately display the preferences that are configured in your custom ADM templates that have been imported.

Handy Tools
There are plenty of tools available for helping you track down your Group Policy issues. Some are built into the operating system and others can be downloaded and installed. Next I'll discuss the appropriate tools so you can choose the right one for your task.
Dcgpofix There might be a time when you have an issue with one of the two default GPOs: Default Domain Policy and Default Domain Controllers Policy. If one or both of the GPOs becomes corrupted, too far out of configuration where you can't fix it, or some other unknown issue, you can use the dcgpofix tool to revert them to the default state. This tool is included in Windows Server® 2003. You should not run this tool on a Windows 2000 domain controller; use Recreatedefpol instead. And remember, when you use this tool, you will lose any customized settings.
Recreatedefpol This tool is similar to Dcgpofix, but for Windows 2000 servers. It can return the two default GPOs to their freshly installed state. This tool should only be used in a disaster recovery situation, not for routine maintenance of GPOs. You can download this tool.
Event Viewer The Event Viewer has a wealth of information regarding Group Policy. Unfortunately, it requires you to look at all of the different log files to find entries for Group Policy. There you'll find entries related to policy application, policy replication, and policy refresh, all of which can be useful when trying to track down a problem. There is not always a lot of information on specific Group Policy errors in the event logs, but remember that you can always search TechNet if you find errors you can't identify.
Gpresult This tool can only be run locally on the target computer, but it provides information about the Resultant Set of Policies (RSoP), blocked GPOs, permissions on GPOs, and much more. Using the command with the /v switch will show a great deal of information about the GPOs that are affecting the computer and about user accounts associated with the current logon session.
Gpupdate If you are implementing new GPO settings or trying to ensure that all GPO processing has occurred, you can use the Gpupdate tool. This is a command-line tool that ships with the operating system (Windows XP and greater). When you run it, it will trigger a background refresh which will apply all GPO settings that adhere to this type of refresh. If you add the /force switch, it will reapply all GPO settings, even if there have been no changes to the GPO since the last refresh. Running this command before running the Gpresult command is a very powerful method for tracking GPO issues.
Gpotool Since GPOs are replicated from the domain controller where the GPO changes initially occur to all other domain controllers, there is a chance of replication failing or not converging efficiently. The result of this is inconsistency or failure of the changes to be properly applied to the target computers. Tools such as Gpresult and RSOP can help determine what GPOs have applied, but this tool, Gpotool, can help you determine if the GPOs on each domain controller are consistent. The tool is part of the Windows Server 2003 Resource Kit at go.microsoft.com/fwlink/?LinkId=77613.
Replmon When troubleshooting replication of GPOs from one domain controller to another, it is important to know which tools you can use to help get the replication working. Since there are two parts of a GPO that must be replicated, there are two parts that need to be addressed. The first, which is the contents of SYSVOL on each domain controller, is controlled by the File Replication Service (FRS). There is really not much you can do to control this replication, except to disable and enable the service to help it trigger a replication interval. The other part of the GPO, which is stored in Active Directory, is controlled by Active Directory replication. This replication can be controlled between domain controllers in the same Active Directory site by using Active Directory Sites and Services. However, when you need to trigger a replication between domain controllers in different Active Directory sites, you need to use a tool like Replmon. Replmon can force replication of the Active Directory database across site boundaries, while Active Directory Sites and Services can't. Therefore, when you have a mismatch of Group Policy information, which is stored in Active Directory, you can use Replmon to trigger a replication process to get that information converged on each domain controller. Replmon is part of the Resource Kit and Windows XP Support Tools. You can download it at go.microsoft.com/fwlink/?LinkId=77614.
RSOP Much like the command line tool Gpresult, RSOP provides a graphical interface for looking at the settings that have been applied by all of the GPOs. RSOP.MSC is a built-in tool for Windows XP Professional and Windows Server 2003. The tool provides you with a result of all applied policy settings in a format similar to that of the Group Policy Object Editor, as shown in Figure 5.
Figure 5 Resultant Set of Policies Tool
Figure 5 Resultant Set of Policies Tool

Wrap-Up
Troubleshooting Group Policy issues is not the easiest task you will ever attempt. In fact, as this article shows, Group Policy can be quite complex. When you approach it for troubleshooting, you need to understand the core architecture and overall processing typical of Group Policy. You also need to understand how a GPO is updated, replicated, processed, and applied. If you have a good grasp of all these concepts, the troubleshooting of any particular Group Policy issue is much easier. By following the guidelines in this article and using your tools appropriately, you'll be ready to tackle all the Group Policy problems you may encounter.

Derek Melber is the Director of Education, Certification, and Compliance Solutions for DesktopStandard, a wholly owned subsidiary of Microsoft. Derek co-wrote Microsoft Windows Group Policy Guide (Microsoft Press, 2005). He also wrote a series of books on auditing Windows security (www.theiia.org). Contact him at derekm@desktopstandard.com.


 Windows Administration: Monitoring Active Directory with MOM
Windows Administration John Hann

Monitoring Active Directory with MOM
At a Glance:
  • Management packs for Active Directory
  • Customization tips for MOM
  • Alert tuning

Management packs are the life-blood of Microsoft Operations Manager (MOM) 2005 and are what differentiate it from other management products. MOM uses management packs to put rules, reports, tasks, and views together and can be limited in scope to a specific application
or service, such as Active Directory. Microsoft product teams create the management packs for the applications they develop, ensuring that MOM reflects the teams' deep product knowledge. Furthermore, management packs can be customized to fit your IT environment. You then have rules that monitor and manage the product based on your particular server and application environment.
Not only is there a specific management pack for Active Directory®, but there are a myriad of management packs for measuring directory services health from Windows Server® Base Operating System to Dynamic Host Configuration Protocol (DHCP), DNS, and File Replication Service (FRS). Let's go over these management packs in detail so you'll have a better understanding of the end-to-end management of Active Directory possible through MOM.

DHCP Management Pack
The DHCP Service management pack monitors the DHCP service running on Windows NT®, Windows® 2000, and Windows Server 2003. It's a good idea to monitor DHCP so you know if clients are having issues connecting to the network. You'll also be alerted to rogue (unauthorized) DHCP servers running in your environment. The download package for this management pack contains a guide that documents the rules and reports as well as monitoring scenarios and deployment. A treasure trove of additional documentation and guidance can be found at the TechNet MOM 2005 Web site (microsoft.com/technet/prodtechnol/mom/mom2005).
The newer the version of Windows you're running the DHCP service on, the more instrumentation and functionality MOM 2005 provides for managing it. Therefore, you'll get more information about a Windows Server 2003 DHCP server than a Windows NT DHCP server. For example, a DHCP server running on Windows Server 2003 can have its superscopes monitored, whereas the DHCP management pack only monitors normal scopes on a Windows 2000 DHCP server. You can exclude scopes from being monitored by placing the scopes to be excluded as a parameter for the monitoring script.
As mentioned earlier, the DHCP management pack supports DHCP servers running on Windows NT, Windows 2000 Server, and Windows Server 2003. The computer groups are populated through formulas that use the operating system version and whether the server hosts the DHCP Server service.
The DHCP management pack does not support low-privilege configurations. The agent Action Account must be a member of the local Administrators group. Agentless monitoring is supported, but tasks are not supported in an agentless configuration. Figure 1 lists the reports that are available in the DHCP management pack.
Figure 1 DHCP Service Reports (Close Figure 1)

All DHCP Servers
All Authorized DHCP Servers
Performance History-Active Queue Length
Performance History-Conflict Check Queue Length
Performance History-Declines per Second
Performance History-Discovers per Second
Performance History-Milliseconds per Packet (Avg)
Performance History-NACKs per Second
Performance History-Scope Free Addresses
Performance History-Scope Addresses in Use
Performance History-Superscope Free Addresses
Perfromance History-Superscope Addresses in Use
You can download the DHCP management pack from go.microsoft.com/fwlink/?LinkId=79527.

DNS Management Pack
The Domain Name Service management pack monitors the DNS service running on Windows 2000 Server and Windows Server 2003. Since it's such an integral part of the overall health of an Active Directory implementation, monitoring DNS with MOM 2005 is crucial. The DNS management pack monitors name resolution issues, database issues, registry issues, runtime events and errors, as well as related performance counters.
For Windows 2000 Server, a Windows Management Instrumentation (WMI) DNS provider has to be installed. Specifically, this allows the DNS management pack to query the WMI DNS namespace for information and testing.
The computer groups are all populated through formulas that use the operating system version and whether the server hosts the DNS Server service to determine group membership. The DNS management pack supports low privilege on Windows Server 2003 only. On Windows 2000, the Action Account must be a member of the local Administrators group. On Windows Server 2003, the Action Account must be a member of the local Users and Performance Monitor Users groups. In addition, the Action Account must have Manage auditing and security log (SeSecurityPrivilege) and Allow log on locally (SeInteractiveLogonRight) permissions. Figure 2 lists the reports that are available in the DNS management pack.
Figure 2 DNS Service Reports (Close Figure 2)

All Windows DNS Servers
All Windows DNS Servers by Zone
All Windows DNS Zones by Server
Marcus Oh, an MVP for Microsoft® Systems Management Server (SMS), developed a script that tests a DNS server by calling nslookup to verify the DNS server's ability to resolve names. Take the time to review his blog post at marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html; you'll want to integrate this script into your DNS management pack.
You can download the DNS management pack from go.microsoft.com/fwlink/?LinkId=79528.

FRS Management Pack
The Windows File Replication Service management pack monitors the FRS service running on Windows 2000 and Windows Server 2003. FRS is used by the domain controllers to replicate logon scripts and Group Policy information. The FRS management pack will detail the health of the FRS service for each domain controller.
The FRS management pack utilizes the Ultrasound tool, which is available from go.microsoft.com/fwlink/?LinkId=79529. Ultrasound creates a WMI namespace for FRS on each domain controller. Note that Ultrasound requires a database and will store the information from the WMI namespace on each domain controller for health monitoring. By using the information from Ultrasound, the FRS management pack provides monitoring for replica sets, members, connections, the FRS service itself, and the Ultrasound controller service.
In fact, you should install Ultrasound on a separate server from the management server. Ultrasound rules generate events and alerts on behalf of other computers. In order for the Ultrasound rules to process data properly, you must enable agent proxying in the MOM Administrator console on each server running Ultrasound. Figure 3 lists the four service reports that are available in the FRS management pack.
Figure 3 FRS Service Reports (Close Figure 3)

Ultrasound-Frequently Detected Issues-Most Problematic Connections
Ultrasound-Frequently Detected Issues-Most Problematic Members
Ultrasound-Frequently Detected Issues-Most Problematic Replica Set
Ultrasound-Frequently Detected Issues-Summary
Computer groups associated with this management pack include Microsoft Ultrasound 1.0 servers and FRS servers running on Windows 2000 Server and Windows Server 2003. The computer groups are all populated through formulas that use the operating system version and whether the server hosts the FRS service to determine group membership. The Ultrasound Servers group is populated when a server has Ultrasound installed.
When you configure the FRS management pack for low privilege, tasks do not work, but the rest of the management pack functionality is supported. The Action Account must have read access to the Ultrasound database and run permission for the GetControllerStatusForMOM001 stored procedure. The FRS management pack includes support for monitoring agentless as well as agant-managed computers.
You can download the FRS management pack from go.microsoft.com/fwlink/?LinkId=79530.

Windows Server Management Pack
The Windows Base Operating System management pack monitors Windows NT 4.0 Server, Windows 2000 Server, and Windows Server 2003. The Base OS management pack will report the health of the operating system for your domain controllers and also monitors the root services on the system. The management pack provides the status of core Windows services, memory and processor performance, as well as disk free space and disk latency. There is some overlap between the monitoring rules of this management pack and the others covered in this article, but it provides a great bottom-up view of the health of the domain controller.
Figure 4 shows the reports available in the Base OS management pack. As with the other management packs, the computer groups are all populated through formulas that use the operating system version.
Figure 4 Base Operating System Reports (Close Figure 4)

Disk Performance Analysis
Operating System Configuration
Operating System Performance
Operating System Shutdown by Event
Operating System Shutdown by Server
Operating System Storage Configuration
Software and Applications Installations by Application
Software and Applications Installations by Instance
Software and Applications Installations by Server
Reliability-Application Failures by Application
Reliability-Application Failures by Computer
Reliability-Application Failures by Event
Reliability-Operating System Failures by Computer
Reliability-Operating System Failures by Event
Reliability-Operating System Failures by Stop Code
Performance History-Performance History
Performance History-Additional Reports
When you configure the Base OS management pack for operation with low privileges, Windows 2000 requires that the Action Account be a member of the local Administrators group. Windows Server 2003 requires the Action Account be a member of the local Users and Performance Monitor Users group, as well as having Manage auditing and security log (SeSecurityPrivilege) and Allow log on locally (SeInteractiveLog-onRight) permissions. Most of the Base OS management pack, except tasks, is supported on agentless monitored computers.
You can download the Base OS management pack from go.microsoft.com/fwlink/?LinkId=79531.

Active Directory Management Pack
The Active Directory management pack is very broad and its rules cover both Windows 2000 Server and Windows Server 2003. The Active Directory management pack encompasses five areas of rules: client-side monitoring, trust monitoring, replication monitoring, and topology discovery, plus rules covering the Windows 2000 Server and Windows Server 2003 operating systems. As noted earlier, newer versions of Windows enable more instrumentation and therefore additional monitoring. For example, the management pack supports trust monitoring on Windows Server 2003, but not on Windows 2000.
The Active Directory management pack creates a number of groups that it uses to apply rules to specific computers. The client-side monitoring rules use a group called Active Directory Client Side Monitoring. You would place computers that have the MOM agent installed in this group to monitor and manage these rules. I put a few desktop computers that have been licensed with the agent into this group as well as some of the Exchange servers. Exchange Server uses Active Directory extensively and would be a lead indicator of a developing problem. Desktop computers in the group can help you gauge end-user experience. The client-side monitoring rules utilize scripts to test connectivity to domain controllers, querying them via LDAP, and reporting failures. It is important to note that the client-side monitoring rules can only be applied to agent-managed computers that have proxying enabled but that are not domain controllers.
The trust-monitoring rules use a group called Active Directory Trust Monitoring. Windows Servers 2003 computers would be placed into this group to test trusts. Windows Server 2003 has a WMI namespace for trust monitoring. A script is employed by these rules to query against the WMI namespace. When errors in trusts with other domains are detected, these rules will alert you.
There are many Active Directory management pack rules that apply to either Windows 2000 Server or Windows Server 2003. These rules delineate the differences in how Active Directory is implemented between the two operating systems. However, most of the Active Directory management pack is in the combined rules for both operating systems. Some of these rules include scripts to test connectivity between domain controllers, verifying flexible single master operation (FSMO) role holders, directory information tree (DIT) database size, validating Group Policy processing, Knowledge Consistency Checker (KCC) inspection, and Intersite Messaging service testing.
Replication monitoring is the centerpiece of the Active Directory management pack. Two groups, Active Directory Replication Latency Data Collection (Sources and Active Directory Replication Latency Data Collection) Targets are in place to allow you to configure the domain controllers used only for reporting replication monitoring. Replication latency is calculated for each member of the data collection groups. Performance counters are populated with the time it takes for updates to replicate to each of the group members. Enterprise-wide replication latency is calculated and reported (and alerts are generated) if it exceeds defined thresholds. Note that a WMI namespace for replication monitoring has to be installed on Windows 2000 Server.
Topology discovery in the Active Directory management pack is used to create diagrams of your implementation. These useful diagrams can be exported to Microsoft Office Visio®. The diagrams are built in real-time by MOM so you can create an up-to-date version in just seconds.
Under the Diagram Views in the MOM 2005 Operator Console, there are three Active Directory management pack diagrams. The Broken Connection Objects diagram (see Figure 5) will show any connections that are in an error state. This diagram can be blank if no connection errors exist.
Figure 5 Broken Connections are Highlighted in Diagram View
Figure 5 Broken Connections are Highlighted in Diagram View
The Connection Objects diagram highlights the connections between DCs. The Site Links diagram shows each Active Directory site, encapsulating the appropriate domain controllers in that site and the connecting site links.
Since the diagrams created by MOM for these views are dynamic, you can export them to Visio for easy editing and customization. For example, Figure 6 shows the Site Links diagram being edited in Visio.
Figure 6 Editing a Site Links Diagram in Visio
Figure 6 Editing a Site Links Diagram in Visio
Figure 7 lists the reports that are available in the Active Directory management pack. Computer groups associated with this management pack are shown in Figure 8. As you can see, the Active Directory computer groups are populated by explicit membership; the Windows computer groups are populated according to the version of the operating system and whether the machine is a domain controller.
Figure 8 Computer Groups (Close Figure 8)

Active Directory Client-Side Monitoring
Active Directory Replication Latency Data
Collection-Sources
Active Directory Replication Latency Data
Collection-Targets
Active Directory Trust Monitoring
Windows 2000 Server Domain Controllers
Windows Server 2003 Domain Controllers
Figure 7 Active Directory Reports (Close Figure 7)

AD Domain Controller
AD Role Holders
AD Replication Connection Objects
AD Replication Site Links
AD DC Disk Space
AD Domain Changes
AD Machine Account Authentication Failures
AD Replication Bandwidth
AD Replication Latency
The Active Directory management pack can be configured for low privileges on Windows Server 2003 domain controllers. The management pack does not support agentless monitoring. On Windows 2000 Server, the agent Action Account must be in the Domain Admins or local Administrators group. The agent Action Account on Windows Server 2003 domain controllers must have additional permissions to be configured for low privileges, including membership in the Users and Performance Monitor Users groups, access to Event logs, and the SeSecurityPrivilege, SeAuditPrivilege, and SeInteractiveLogonRight privileges. Additionally, the following access is required: full access to the CN=MomLatencyMonitors Container in Active Directory for replication monitoring, read access to the directories containing the NTDS.dit database and log files, and read access to the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
If you are monitoring trusts in Windows Server 2003, note that the script AD Monitor Trusts requires that the agent Action Account have Domain Admin or Administrators group membership.
You can download the Active Directory management pack from go.microsoft.com/fwlink/?LinkId=79540.

Customizing MOM for Active Directory
The Active Directory management pack has to be configured or the alerts will keep your console full. The noisiest time for the Active Directory management pack occurs when a domain controller restarts-every possible alert seems to be triggered. The bad news is that it is not easy to stop this. Your best bet is to utilize Maintenance Mode within MOM to control the alerts during anticipated maintenance windows. The purpose of Maintenance Mode is to auto-resolve alerts for the domain controllers so that the console is not filled.
Be sure to configure the Active Directory Client Side Monitoring group by placing client computers and appropriate servers within the group. The rules associated with this group will help determine the health of your FSMOs and connectivity to them.
There are performance rules that use thresholds for binding to the FSMOs using LDAP, PING, and DNS to verify connectivity. These rules are located in the Active Directory Availability performance rules. You should customize the thresholds used by these rules by setting the alert severity. For instance, the FSMO bindings use attribute values that are in seconds. The performance rules for each of the FSMO roles use this alert creation methodology.
It's important to understand how the Alert Severity Calculation for State Rule settings work. The dialog box uses If-Else conditions for the attribute value and sets the alert severity accordingly (see Figure 9). When the rule collects the Last Bind performance counter created by the AD Op Master Response script, it checks them against the conditional thresholds set by these rules. You need to configure these different alert levels for your environment.
Figure 9 Setting Alert Severity Rules
Figure 9 Setting Alert Severity Rules
Remember the replication schedule for each domain controller. If a given domain controller has a different schedule from others, it will skew the replication latency results and cause you to set thresholds higher. You'll need to set the parameters for the replication scripts to suit the needs of your particular environment. It is important to note that when any domain controller is down or having replication issues, every other domain controller in these groups can report a replication failure for that domain controller even if it is not a direct replication partner. Therefore, even if you place the offending domain controller in Maintenance Mode, the other domain controllers can report replication failures.
Replication monitoring is where you should spend most of your effort in tuning the Active Directory management pack. You'll need to run the management pack in your environment for a couple weeks to see how it alerts. Once you see some trends developing, use the reports to outline latencies and tune the thresholds accordingly.
Finally, you should take advantage of the guidance provided in the Alert Tuning Solution Accelerator.

Looking Forward
MOM 2005 and the Active Directory management pack allow you to effectively and efficiently monitor your organization's Active Directory implementation. With the Active Directory, DHCP, DNS, FRS, and Windows Server Base OS management packs, you are better able to monitor most aspects of your infrastructure, protecting the health and well-being of your Active Directory infrastructure-and your users, too. Using the expansive data collected into your reporting data warehouse, you can analyze your performance and event data to assist with capacity planning and performance trending.
To find the management packs that I've discussed in this article, along with many others, see the Management Pack Catalog.
The next update to the Active Directory management pack will contain the usual collection of fixes and tweaks to a few thresholds. More interesting are the new features planned for the next release of the product, called System Center Operations Manager 2007, including the ability to monitor multiple forests from a single configuration group, to define groups of domain controllers (each with its own expected replication latency between other groups) and to monitor domain controllers running on the next version of Window Server. Stop by the MOM Web site at microsoft.com/mom for details

John Hann has worked with MOM since MOM 2000 and has been a MOM MVP since 2004. John contributes to MyITForum.com, MOMCommunity.com, and LearnMOM.com. You can contact him through his blog.


 Windows Administration: Gaming in a Secure Environment
Windows Administration Matt Clapham

Gaming in a Secure Environment
At a Glance:
  • Writing to protected folders and registry keys
  • Copy protection failures
  • Firewall issues
  • Problems with enterprise clients

By day, I work as a Security Program Manager at Microsoft. I also write about security quite often for TechNet Magazine. Needless to say, I take security very seriously. But I have other interests
too. In my spare time, I love to play Windows®-based games. I'm especially fond of first-person shooters, simulators, role-playing, and real-time strategy games. There's a catch, though. Like my friends Jesper Johansson and Aaron Margosis, I refuse to run with administrative privilege except when absolutely necessary. I do this partly to make sure that I only get 0wn3d in a network game due to my lack of skills and not as a result of someone bombing me with a rootkit to slow my aiming (see the Quake 3 Buffer Overflow Advisory listed in the "Resources" sidebar).
I'm so passionate about this that I often can't play a hot new title (see Figure 1). If I can't get the game to run under my Limited User Account (LUA) on a Small Business Server (SBS) domain-joined client after installing and updating it under an administrator account, I promptly remove it. There's no excuse for such poor engineering, and I'm not lacking games to choose from. I admit this might sound like an extreme position to take, but I'm adamant about this point. Still, I'm not against working around a few minor foibles for the sake of some quality gaming time, and that is what I'll be discussing here. So allow me to share some of the game-related problems I've encountered, and the solutions I've found to work. For a quick summary of best practices, take a look at the sidebar "Tips for Gaming as a Limited User".
Figure 1 File Access Problem when Performing a Manual Update
Figure 1 File Access Problem when Performing a Manual Update

Common Problems
This privilege problem is nothing new. There are numerous games, and other types of programs, that require administrative privilege to run properly. Take a look at Knowledge Base article "Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account" (see support.microsoft.com/kb/307091). It lists nearly 200 games and applications that have difficulty when run by a limited user, including a few programs from Microsoft.
I want to be clear that I do not consider requiring administrative privilege to install or (manually) update a game to be a problem. This is generally required until we have the ability to do routine per-user installations on Windows. That day is coming soon, but we're not quite there yet. However, once a game is installed and updated it ought to be ready to play by any user on a system, even one with just limited privilege.
Trying to Write to Protected Folders and Registry Keys The single most common problem I've seen is when a game fails at launch or during play because it attempts to write to protected folders or registry keys (common in many Windows-based applications). By default, only administrators (and the deprecated Power Users) can write to certain folders (such as %PROGRAMFILES%) and registry hives (like HKEY_LOCAL_MACHINE). The errors from this may be relatively obvious: "Error 42: Can't write log files to C:\Program Files\CoolGamesInc\NewestFPS\Logs\" or "Game not installed properly, reinstall and restart." I've also seen examples in mid-game, such as error messages that appear when I save my progress. Sometimes the game writers at least alert the user that the game currently needs administrative privilege to function, which is what I experienced with Age of Mythology®. Massively multiplayer online games (MMOGs) often bump into problems with privilege since they frequently update themselves and the self-updating angle is a bit trickier to solve technologically. When I ran through the EVE Online trial, I noticed it suffered not only from placing log files in inappropriate locations, but also from trying to self-update game content data to the install folder.
Copy Protection Fails The second most common reason I've seen for games failing to launch is when the game's built-in copy protection (or other anti-piracy feature) doesn't work as a limited user. It could be that the driver didn't start properly or some background service isn't running. The most common representation I've seen for this problem is the game asking the user to insert a disk—even when the required media is already in the drive. I've also seen games claim administrator privileges are necessary on the misbegotten belief that only administrators can properly run the copy protection check. The worst cases give some ill-formed, nonsensical error message that has no reference on the game's support site.
Failure to Request a Firewall Exception Multiplayer games that can be played over a local network or the Internet are very common, and Windows XP Service Pack 2 (SP2) added a warning message that tells the user when applications are attempting to listen on the network. This brings me to the next common problem I've observed: games that need a firewall exception but don't ask to add this exception at setup time. Since limited users can't alter the firewall configuration, this warning (see Figure 2) can't be remedied without some configuration work done by an administrator. Worse yet, sometimes the problem isn't obvious, since the warning appears in the Windows shell, not within the game's interface. In fact, I typically don't even see the error message until after I've exited the game.
Figure 2 When Firewall Settings Stop all the Fun
Figure 2 When Firewall Settings Stop all the Fun
Problems with Enterprise Clients I've found another problem not directly related to running as a limited user, but it's worth discussing nonetheless. I run my home computing environment like a small enterprise (I won't go into too much detail here, but you can read about it in the article "Master Your Domain: Build a Corporate Network at Home" that Jesper Johansson and I wrote for the October 2006 issue of TechNet Magazine. Using SBS 2003 (R2), I have set up a complete Windows domain with a My Documents folder that is redirected to a server share. This is how I discovered the last most common problem I'll discuss: games that can't handle enterprise clients.
I noticed a double whammy with Age of Empires® III (AoE3). To the development team's credit, the game starts and plays properly as a limited user. However, I noticed that scenarios loaded slowly due to lots of logging data being written over the network. Additionally, AoE3 lost my configuration, saved games, and progress whenever I exited the game. The files were clearly there in the My Documents folder, but the game just wouldn't load them. This was a real disappointment, especially considering how much more LUA-friendly AoE3 had become compared to earlier titles in the series.
I have seen one game that at least acknowledges such enterprise client issues. When I tried Fable®: The Lost Chapters™, the game was considerate enough to tell me that remote My Documents folders are unsupported, and then it gracefully exited. I commend the development team for recognizing an unsupported scenario and ruling it out. However, it seemed a bit odd that the game would go out of its way to stop the user, given that the game wanted to place only a few megabytes of data in the My Documents folder.

Simple Solutions
I've seen these problems over and over, on more games than I can recall. Fortunately, most have convenient workarounds. My favorite fix is to drop the game altogether, switching to a LUA-ready title in the same genre by a different publisher. Again, that might sound a bit extreme. And it's not a great solution when I've just spent 60 dollars on a new title and I can't return it because the box is already opened. So let's look at ways to fix the games I already own.Tips for Gaming as a Limited User
  • Upgrade to Windows Vista.
  • Try the demo before you buy. This will most likely present any LUA problems the full version has.
  • Check out the list of programs known to have problems running under a LUA ().
  • Look for games that carry the Designed for Windows logo.
  • Update the game after installation and before running it as a limited user.
  • When you find a game that doesn’t work as a limited user, express your concerns to the publisher and to the company’s tech support service.
  • If you must, use a system local power user account.

Fixing Copy Protection Issues First, let's tackle the copy protection driver issue. Copy protection systems are here to stay, but that doesn't mean they should prevent nonadministrators from running games! Most games use Macrovision's SafeDisc copy protection mechanism, which installs a driver that checks for an original game disk. By default, the driver is configured to start on demand (a function limited users aren't allowed to do). Microsoft and Macrovision have distributed fixes, but I've found another workaround:
  1. Open Device Manager using an administrator account.
  2. Go to the View menu and select Show hidden devices.
  3. Expand the Non-Plug and Play Drivers node.
  4. Open the properties for the Security or SecDrv driver (see Figure 3).
  5. Change the startup type to Automatic.
Figure 3 Allowing Copy Protection to Run Properly
Figure 3 Allowing Copy Protection to Run Properly
Since the driver now starts when the computer boots, it's ready when the user inserts the disk to run the game.
Fixing File System and Registry Access Issues The assumption of unfettered access to any part of the file system or registry is a common problem with many current and legacy programs, not just games. Aaron Margosis's article "Problems of Privilege: Find and Fix LUA Bugs" goes into greater detail about solutions to the various problems that lead to requiring administrator privileges.
Access problems can be a little tricky to track down, but once the requisite set of files, folders, and registry keys are discerned, loosening the access control lists (ACLs) to allow limited users to play the game is pretty straightforward. I've had the most success with the following method:
  1. Get the latest versions of Filemon and Regmon from microsoft.com/technet/sysinternals.
  2. Run the tools as an administrator and have them start collecting logs.
  3. Play the game for a few minutes as an administrator, performing the most common tasks (start a new campaign, save a game, host a network game, and so on).
  4. Filter the results from Filemon and Regmon to focus on accesses from the game being tested.
  5. Loosen the ACLs as necessary on the folders and registry keys in question.
  6. Run the game as a nonadministrator to make sure it now works.
One word of caution on loosening the ACLs: don't open them too broadly (such as Everyone—Full Control) or at too high a level (like HKEY_CLASSES_ROOT). It's also best to avoid changing any permissions on system folders like %SYSTEMROOT% and %PROGRAMFILES% to avoid breaking Windows entirely or leaving the system in an unsecure state.
Another potential work-around is running the game as a system local Power User. This isn't my first choice, but by using an account that is local to that system, the scope of impact is at least limited to a single workstation, should something go wrong. I've found that this fix works for most games that seem to only work properly as an administrator.
As an aside, I find that running a game briefly as an administrator is a handy way to get it self-updated. I typically run the game as an administrator, invoke its update option, and then exit the game and return to my limited user account to actually play. (It's worth mentioning that Windows Vista™ allows for limited users to update apps, assuming the patch is signed by the original publisher.)
Windows Vista also helps games and other applications address file and registry access problems. By default, programs run by limited users have virtualization shims turned on that redirect misguided file and registry accesses to a user-specific cache. I've personally seen games designed in the Windows 9x era, (for example, The Neverhood) that don't run properly on Windows XP (due to permissions issues) work perfectly on Windows Vista with the default shims. I'm looking forward to testing some other problematic games on Windows Vista, but my hunch is that I'll be hard-pressed to find a game Windows Vista can't shim properly.
Fixing Firewall Issues The firewall problem is best solved when first installing the game. However, when the game setup isn't savvy enough to ask about and configure the requisite firewall tweaks, here's a method I've found that works well:
  1. Log on as an administrator.
  2. Open the Windows Firewall Control Panel.
  3. Choose to add a program to the firewall exception list.
  4. Select the game from the list or browse for the game executable when prompted.
By adding the game executable to the firewall exception, I ensure that the game will be allowed access to any and all ports it needs to function properly. Much carnage ensues!
Fixing Issues with Enterprise Clients The problems games encounter on enterprise clients will disappear in time. The number of multi-computer households with broadband is on the rise, and there's a growing community of users running SBS at home. But for now, a solution is still needed.
In my particular case, I found that a system local LUA worked around the redirected My Documents issue. Both Age of Empires III and Fable: The Lost Chapters work just fine as a limited user as long as the My Documents folder isn't redirected to a network folder.Resources
  • Quake 3 Buffer Overflow Advisory
  • Windows Vista Application Development Requirements for User Account Control Compatibility
  • Applying the Principle of Least Privilege to User Accounts on Windows XP
  • Aaron Margosis’ LUA Buglight tool
  • Standard User Analyzer
  • Master Your Own Domain: Build a Corporate Network at Home
  • Problems of Privilege: Find and Fix LUA Bugs
  • Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account

Conclusion
I highly recommend running as a limited user so you can take advantage of the benefits associated with not running as administrator. It's not always easy to game in an enterprise-connected, least privilege world, but it's far from impossible. Over the years, I've found plenty of games covering each genre that work properly as a limited user. And I've found some fixes that make a number of other titles work. Meanwhile, with the virtualization in Windows Vista, games that were impossible to play as a limited user on Windows XP work once again.

Matt Clapham, a Security Program Manager at Microsoft, is an active participant in the Seattle IT security community and a member of the risk management team on an IT incubation project.


 From the Editor: Under the Covers
From the Editor
Under the Covers

WINDOWS VISTA IS POISED to have a major impact on corporate IT departments in 2007. As reported in InformationWeek, a recent IDC report estimates that 100,000 IT jobs will be created in the U.S. this year as a direct result of the Windows Vista "bounce." About 90 million new machines worldwide will come with Windows Vista installed this year, and by next year 80 percent of new machines being shipped to businesses will have Windows Vista preinstalled. Meanwhile, you have to decide whether it’s time to deploy the OS in your organization. We can help.
This month’s issue of TechNet Magazine launches a series that will take an in-depth look at what makes Windows Vista tick—the kernel. True, Windows Vista has some nice new user experience features, but if that were the main reason to migrate, we’d be wary. The kernel represents the heart of the OS, and there are significant improvements in the way the Windows Vista kernel works.
Who better to write about such changes than Mark Russinovich, who knows as much about the Windows kernel as anyone on the planet? His book Windows Internals, coauthored with David Solomon, has become the top resource for anyone looking to understand what’s going on under the covers.
This month, Mark tells us about CPU allocation improvements, which will make desktop applications more responsive, then describes how Windows Vista enhances multimedia performance at the kernel level. The article also looks at important changes in the I/O model in Windows Vista, including file-based symbolic links, the new ability to cancel synchronous I/O operations (the top change, in my opinion), and the concept of I/O priority. Be sure to read Mark’s comprehensive article as you evaluate Windows Vista for your enterprise.
Of course, there are still the everyday tasks to get through and we can help you there as well. This issue covers a lot of Windows administration territory, with articles on delegating authority in Active Directory, new Group Policy templates in Windows Vista, Group Policy troubleshooting, and monitoring Active Directory with MOM.
Finally, if you like playing games and staying secure, you’ll want to take a look at our feature on gaming in a secure environment. You know what they say about all work and no play. —JOSHUA TRUPIN

Thank you to the following Microsoft technical experts: Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Mark Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Solomon, Jim Truher, Landy Wang, and Andy Zeigler.


 Toolbox: New Products for IT Pros
Toolbox
New Products for IT Pros
Greg Steen

Move Your Data
SQL Examiner Bundle
www.sqlaccessories.com
Whatever your role is within an organization—be it a DBA, a developer, an operational specialist, or a wearer of many hats—if you work with SQL Server™, you’ve probably had to move data between environments and ensure that the integrity of the data and the data structures remain intact. Of course, SQL Server has many built-in replication and synchronization features, but if you are checking to see if your QA database exactly matches your development database, a tool like TulaSoft’s SQL Examiner Bundle can be invaluable, saving you time and effort.
With a few mouse clicks, the application can sniff out discrepancies in either the database structure or the data itself between two database instances. You simply point the application to the databases you want to check and go. As the name suggests, SQL Examiner Bundle bundles two applications: SQL Examiner and SQL Data Examiner. SQL Examiner looks at the structure of your databases, while SQL Data Examiner looks at the all the data and highlights any differences.
SQL Examiner will look at and compare everything in your database instances, from tables and stored procedures, to full-text catalogs and XML schema collections. For those of you using SQL Server 2005, you can compare common language runtime (CLR) assemblies, as well. Once you compare databases, SQL Examiner lets you choose which database objects should be synchronized, plus the direction of the synchronization.
Look At and Compare Your Databases with SQL Examiner
Look At and Compare Your Databases with SQL Examiner
One really cool feature is that the application generates the SQL script that creates an object and will highlight the difference in that generated script between your databases. This would be a great way to highlight errors after a creation script or migration script fails on building the structure of your target database. ("Oh, that’s where I left out my clustered index!") You can run the generated scripts individually, save those scripts to run later, or you can just click the Synchronize button and have the application do all the work for you.
Another nice feature is the option to add exclusions to the comparison, such as ignoring comments, triggers, indexes, or extended properties of an object. After you look at the structure comparison, SQL Data Examiner allows you to look into the data and see any discrepancies. You can pick which tables you want to compare as well as pick which columns of those specified tables should be compared. Once the comparison of the data tables has completed, you can see which rows are identical, which are different, and which reside in only one database or the other.
As with SQL Examiner, SQL Data Examiner lets you click a button to synchronize the tables or you can selectively choose which data should be transferred as well as the direction of that transfer. Both applications let you save your setup as a project, so you won’t have to recreate the tasks every time. Each app can be purchased separately, but based on my experience, I bet you’ll want both.
Price: $299.95 for a single-user license.

Search For Duplicate Files
zsDuplicateHunter (Professional Edition)
Zizasoft
If you are involved in desktop management, you undoubtedly have come across the user who has "run out of space" on his machine. An investigation reveals that he has been copying his documents every time he makes an edit, even though you have a backed-up Network Attached Storage (NAS) system for your user base to store files. Or, you have a log server with batch processes that have managed to duplicate huge logs, taking up all the allocated server space. A possible solution to these problems is zsDuplicateHunter Professional Edition, a Java-based duplicate finder that can run on Windows®, Linux, or Mac OS X.
The application lets you easily search drives, directories, or network shares and sniff out possible duplicates. Going beyond name comparisons, the application allows you to group files by file size, file checksum, or even file digest calculation to ensure the files you are cleaning up are actually different. Also, you don’t have to permanently delete your duplicates. As a precaution, the app lets you move all the marked duplicates into a specified folder.
Another nice feature is the "Keep Files in this Folder, Delete Duplicates Elsewhere" option that lets you pick your clean source directory and wipe out any others that may be on the disk. Within the search results, you can also double-click any file to open it with an associated file viewer, sort them, and select them to get the exact results you need. A nice "IT pro" feature lets you tune how much memory the application is allowed to take up while hunting for duplicates. As an additional protection, you can also disable search hidden or system files to ensure you don’t delete anything you shouldn’t or delete any file that is being managed by the operating system or another application.
The Professional Edition also gives you a granular filter on your search resultsets, letting you apply a Regular Expression to find the exact files to eliminate.
Price: $39.95 for a single-user license.

Take Your Apps With You
MojoPac
www.mojopac.com
If you are traveling around from environment to environment and miss your favorite applications and desktop settings, or if you just don’t like leaving your footprints around someone else’s desktop, you might want to take a look at MojoPac from RingCube Technologies.
Silly names aside, MojoPac lets you carry your settings and applications to any Windows XP system (Home, Professional, Media Center, or Tablet) on a USB hard drive, personal media device that you can connect to the host system via USB 2.0, such as a Zune or iPod, or even a cell phone with enough storage space. At the time of this writing, Windows Vista™ and Windows 2000 hosts were not supported, but the documentation on the product Web site said an upgrade supporting those OSs would soon be available.
Carry Your Settings with MojoPac
Carry Your Settings with MojoPac
Currently, MojoPac requires Administrator privileges on the host system, but the 2.0 version in development will have support for limited user mode. The tool basically runs interference between the host OS and the storage devices, and, on the first launch after you install the application to your portable device, MojoPac triggers the initial Windows account set up to run, configuring your personal settings for your MojoPac user onto the MojoPac device.
Once you are up and running, switching between the host system and the Mojo system is easy: you simply click on the toolbar (which can be minimized) at the top of your screen. You install applications to your Mojo device as you would normally while your MojoPac is active. And as long as you heed the big warning in the readme documents about installing to the default directory, you should be set to go.
All in all, MojoPac has the potential to be a great asset to any IT pro who finds himself traveling yet wants his own setup. For example, you could have all your system utilities, packet sniffers, and traffic monitors on your MojoPac and troubleshoot from any PC in your organization, leaving no footprints behind.
Price: $49.99 for a single-user license.

Book Review
Administrator’s Guide to SQL Server 2005
www.aw-bc.com
More and more IT groups are realizing the potential power and breadth of functionality provided by SQL Sever 2005. From the extensive XML data support, to SQL Server Integration Services (SSIS), to the SQL Server 2005 Service Broker, the application adds tons of useful enhancements. To help you get going with your own upgrade path or administering your recently released SQL Server 2005 instance, Buck Woody has written an excellent reference guide—Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional, 2006).
The book gives you insight into practical administration practices as applied to the new server platform and, unlike many other references out there, does so concisely. The book starts out with a section on right-sizing your infrastructure to suit your application’s needs as well as a guide on which SQL Server version would be appropriate under different scenarios. Here, too, you’ll get an idea of how to architect your infrastructure to ensure you don’t end up with avoidable performance bottlenecks on your installation.
The guide then moves into delineations of the different tools provided with SQL Server such as the enhanced SQL Server Profiler and the new SQL Server Management Studio. You’ll also delve into maintenance and automation tasks and see how you can plan for growth based upon server profiling and how to come up with an appropriate maintenance plan for your implementation.
In the chapter on security, you’ll also explore how to secure your installation, from the network and hardware, through the OS and SQL Server instance. Here, too, you get a peek into the added encryption, certificate, and key management services provided by the new platform.
Another chapter explains the mechanisms that exist to ensure high availability of your system, based upon your implementations’ needs. You’ll investigate clustering, database mirroring, replication, and log shipping as methods of achieving your up-time requirements. And with virtualization becoming a great way to achieve high-availability without the overhead of physically distinct infrastructures, the book gives you a step-by-step guide to setting up a two-node cluster using Microsoft Virtual Server.
The chapter on SSIS shows you how to use the new tool (goodbye DTS!) to not only develop and deploy extract, transform and load (ETL) functions, but also how to use the services to create monitoring, e-mail notification, and backup tasks.
Finally the last few chapters delve into the Reporting and Analysis Services provided by the new SQL Server platform. Here you will touch on report design and creation, managing reporting systems, and what is involved in maintaining an analysis services deployment.
All in all, Administrator’s Guide to SQL Server 2005 is a great way to get up to speed on administering, monitoring, and upgrading to SQL Server 2005.
Price: $49.99.


 SQL Q&amp;A: Database Size, Mirroring, Marked Transactions, and More
SQL Q&A
Database Size, Mirroring, Marked Transactions, and More
Edited by Nancy Michell

Moving a Cluster
Q I need to move a SQL Server 2000 cluster to new IP addresses for both the physical servers underneath, as well as the Windows® cluster and SQL Server™ cluster. Will I need to rebuild the entire solution?
A No, all you need to do is run the SQL Server setup and modify the IP addresses. Here is a Knowledge Base article that explains how.

Database Size
Q I have SQL Server 2000 SP4 in production with a mission-critical database of almost 10GB, a SIMPLE recovery model, a primary file of 9,850MB, and a transaction log file of 88MB. The database backup is also almost 10GB. Should I reduce the size of the database for better performance? If so, should I use DBCC SHRINKDATABASE or DBCC SHRINKFILE? (Unfortunately, I don’t have non-peak hours available for this maintenance.)
A DBCC SHRINKDATABASE or DBCC SHRINKFILE will only help if the database experiences many deletions and updates that result in a smaller volume of data. But the real question is why do you care? Disk space of 10GB is worth maybe $20 today. Wouldn’t it make more sense to add another 100GB or so of disk space and let it run? Performance will deteriorate as the space gets more fragmented, but if you can’t do any maintenance you have little choice. Sometimes people use a second copy of the database in cases like this. They keep a backup copy up-to-date with replication, do maintenance of the backup copy, and then switch the applications to the backup. This obviously requires some code changes and moving off the SIMPLE recovery model (to either FULL or BULK_LOGGED) but it may be a good long-term solution.

Upgrading and Performance
Q I need to move two applications from SQL Server 2000 to SQL Server 2005. How can I avoid any performance hits during the upgrade?
A Generally, the following pitfalls can cause performance degradation when upgrading, so try to avoid them:
  1. You haven’t rebuilt the statistics after upgrading to SQL Server 2005.
  2. You have JOINS and WHERE clauses that compare two different data types, resulting in bad performance, especially if the server had been running SQL Server 2000 SP3 or earlier (see support.microsoft.com/kb/271566/).
  3. The SQL Server 2005 instance is not correctly configured; memory, address windowing extensions (AWE), drivers, and so on are configured incorrectly. The box running SQL Server 2000 has been tweaked, the person who did it left and did not document it, so it was never done on the SQL Server 2005 instance.
  4. The hardware is at fault. Often, new hardware is purchased because it looks good on paper, but doesn’t hold up in real life.
Before taking a SQL Server instance into production, a performance baseline should be established to confirm that the performance you expect will be realized. This can then rule out the infrastructure as a possible problem. You need to look at Perfmon counters such as Disk, I/O, and memory, and compare them between instances.

Database Mirroring
Q I am using database mirroring and want to enable the READ_COMMITTED_SNAPSHOT database option. When I try to enable it after the mirroring has been set up, I get an exception stating that the db is in a mirroring session, and the command cannot be run.
A This happens because setting the READ_COMMITTED_SNAPSHOT option requires a database restart in order to take effect. Therefore, you need to break the mirroring session, set the option, and restart the database. After those steps are complete, you can reestablish mirroring. The mirror database will pick up the option after the session is established and will use it if failover happens.

Q I’m trying to set up asynchronous mirroring and I’m getting a 1418 error. Running Netstat -ano shows that SQL Server is listening on the correct port on all servers. The error appears when I try to start mirroring. What’s going on?
A One possibility is that your firewall might be blocking the communication; this is a relatively common issue that you should investigate. Check out the following whitepapers for more help: Troubleshooting Database Mirroring Setup at and MSSQLSERVER_1418.
Just note that this issue is not specific to asynchronous mirroring. In fact, it can happen with synchronous mirroring as well.
The error you’re getting ("The server network address "%.*ls" cannot be reached or does not exist. Check the network address name and reissue the command") is correct. Often it’s not that the remote partner doesn’t exist, it’s that the remote partner simply can’t be reached.
This could happen if the remote partner is down, does not listen to the port, or even if the endpoint is down (this might happen if the partners can’t negotiate the same encryption mechanism or have some other authentication issues). It can also happen if the partner is blocked, which can be the result of the firewall on the partner initiating the command.
Some other problems you might want to rule out include data source name (DSN) and name resolution issues. The generic recommendation is to use fully qualified domain names. So while your firewall might frequently be the problem, just remember that there are many potential causes.

Q I want to use SQL Server 2005 mirroring; however, I have heard that mirroring isn’t recommended when multiple applications connect to multiple databases on the same SQL Server instance. Is this correct?
A The answer actually depends on whether each application has its own database or the applications use cross-database or Distributed Transaction Coordinator (DTC) transactions. If cross-database transactions are used, then mirroring may introduce logical inconsistencies in which transactions are not committed as expected. A good explanation of what happens under these circumstances can be found here.
If there are multiple databases used by multiple applications and each app has its own database, then mirroring will not cause these problems.

Marked Transactions
Q What exactly are Marked Transactions, and are they something that can be used if one database is SQL Server and one is Oracle?
A Marking a transaction is something the DBA does periodically to put a mark at the same place in all the logs. This action, combined with the ability to restore a table to a transaction mark, allows you to restore all the databases to the same point. Doing this can be very painful because you will have to restore all the databases involved and data will be lost in all databases, so you should avoid this by making sure that you don’t lose your log files. Marked Transactions are SQL Server-specific, so if your distributed transactions include databases other than SQL Server, they can’t participate in transaction marking. In general, very few distributed database systems use transaction marks. They just treat the loss of one of the transaction logs as a catastrophic event that will require a lot of manual work to recover from.

Access-To-T-SQL Conversion Tool
Q Is there an automated Access™-SQL to T-SQL conversion tool available for stored procedures?
A Try the SQL Server Migration Assistant (SSMA) for Access, which you can download. There you will also find the SQL Server Migration Assistant for Oracle, SQL Server Migration Assistant for Sybase, and Migrating Informix Databases to Microsoft® SQL Server 2000.
For upsizing from Access to SQL Server, you could use the Office Upsizing Wizard, but the SSMA for Access, shown in Figure 1, has more features, including conversion assessment reports and network scanning. SSMA for Access also fixes many issues currently not handled correctly by the Office Upsizing Wizard.
Figure 1 SQL Server Migration Assistant for Access
Figure 1 SQL Server Migration Assistant for Access

Non-Clustered Indexes
Q I have a table in which the primary key is made of two GUIDs (say GUID1 and GUID2). I already had my unique clustered index on GUID1 and GUID2. Now for performance reasons, I want to create the second non-clustered index on GUID2 and GUID1. Will there be any performance overhead if I declare the index as unique?
A There is no performance penalty to declaring the non-clustered index as unique. In fact, doing so may result in fewer levels in the index tree.
When a non-clustered index is declared as non-unique, the row locator is appended to the key portion of the index entries in the root and non-leaf pages. This is done to facilitate deletion and update of index entries, which avoids scanning a synonym chain when there are duplicates for a key—the specific entry to be changed can be located by a system seek operation on the key plus locator. The result is that those entries are longer (considerably so with the cluster key you have chosen). As a result, the root and non-leaf pages will naturally fill up faster. If the index is unique, you should declare it as such.
The point is, regardless of whether the table has a clustered index, any non-clustered index on the table that is not declared as unique will have the locator appended to the index entries in the root and other non-leaf pages.
Also, if you use an int identifier column as a surrogate key and then add two unique indexes (GUID1, GUID2) and (GUID2, GUID1), this will likely improve performance since indexes will have a 4-byte clustering key instead of a 32-byte clustering key.

Update Locks
Q I have a stored proc with the following structure:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
This stored proc allows only one caller to take the lock and will make any other callers wait. Can I achieve the same behavior by reducing the isolation level?
It seems like READ COMMITTED is the correct isolation level because this transaction has only one query, and if some other transaction is in the process of updating the same record, this transaction will wait on the other transaction. Is this correct?
A It’s not the serializable setting in your example that makes other callers wait—it’s the update itself. Yes, you can have isolation set at READ COMMITTED and the update will naturally take an update lock on whatever index it uses. This will cause problems for other processes executing the same statement, so they will block until the update is done. (You also don’t need the explicit transaction here if the update is the only statement; each statement is implicitly in its own transaction if it’s not in an explicit one.)
However, if there are no rows matching the WHERE clause in the UPDATE statement, then using the serializable isolation level would prevent such rows from being inserted or modified in other transactions. If you were to run the UPDATE in READ COMMITTED isolation, this would not happen and other transactions would be able to introduce rows that will qualify for the update. If the stored procedure code is like the code you showed, it may not make sense to take any of these actions (serializable or transaction); just perform the update.

Thanks to the following Microsoft IT Pros for their technical expertise: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip, and Frankie Yuen.


 Utility Spotlight: Group Policy Inventory
Utility Spotlight
Group Policy Inventory
Greg Steen
Download the code for this article: GPInventory.exe (150KB)

HOW DO YOU know what you have if you don’t keep track of it? Having inventory details at your fingertips can save you lots of headaches when budget allocation meetings and yearly audits roll around. And, of course, the powers-that-be always seem to want to know who has what and why, and what it will take to do that major upgrade.
A tool that can help you with all this is Group Policy Inventory (GPInventory.exe), included with the Windows Server® 2003 Resource Kit. This program lets you query and retrieve system information with Resultant Set of User Policy (RSOP) and/or Windows® Management Instrumentation (WMI) queries from multiple remote hosts, as the figure shows. Not surprisingly, the program easily retrieves Group Policy information, but it’s also an effective means for pulling out detailed system information such as applications that have been installed, the processor name and speed, or the list of installed hotfixes. But wait, there’s more! Since it’s part of the Windows Server 2003 Resource Kit, it’s 100 percent free.
Figure 1 Using GPInventory to Gather Information
Figure 1 Using GPInventory to Gather Information
There are many different ways to put GPInventory.exe to use. For example, if you need to verify warranty status, you can collect the serial or service numbers of the PCs on your network without having to truck out to every box. Or, if you have a lab environment and you want to see if a machine is currently in use, you could query the users currently logged onto the system without getting out of your chair. If you have a blade server set up where images are blown down to the blades on a routine basis (to clean out and restore your QA environment, for example), you could query the install date of the PC to verify when the last image was applied.
GPInventory is also quite easy to use. You point it to a file that has a list of computers you want to inventory, select which queries to run, and then process the list. The tool then reaches out and connects to each computer on the list and queries it. If you are doing a quick query, you can also select the target machines directly from Active Directory® and the query actions to perform from the Query menu.
To run an RSOP query on a machine, you’ll need to have the Generate Resultant Set of Policy (logging) permission (which domain admins and delegated admins have by default). WMI queries require Administrative rights on the remote machine unless you use the WMI Control MMC snap-in to grant Enable Account and Remote Enable rights on the root\cimv2 namespace to an alternate user.
Once you’ve run your query, you can save the results as a tab-delimited text file or as XML. Both varieties can be imported into Microsoft® Excel® for analysis. You can sort and then apply an auto-filter to find all the details.
GPInventory also supports command-line execution, so you could easily set up a scheduled task to query system information and save it to an XML file directly, without GUI intervention. This can be very useful for long-running queries that are better suited for off-hours execution.
The tool comes with a default set of RSOP and WMI queries, but you can add, edit, and update the query file with your own customized list if what you need isn’t there. The included help document shows you how to define a new query in the query-list XML file.
GPInventory.exe is a great way to gather information on the machines running Windows across your network, whether for inventory, group policy, or status information. You’ll find a link to the Group Policy Inventory tool in the downloads section of our Web site.

Greg Steen is a technology professional, entrepreneur, and enthusiast. He is always on the hunt for new tools and methods to help make operations and development easier for IT professionals.


 The Cable Guy: QoS Support in Windows
The Cable Guy
QoS Support in Windows
Joseph Davies
This article is based in part on a prerelease version of Windows Server "Longhorn." All information herein is subject to change.

Quality of Service (QoS) encompasses a set of technologies for managing network traffic in a cost-effective manner to enhance user experiences in home and enterprise environments. QoS technologies allow you to measure bandwidth, detect changing network conditions (such as congestion or availability of bandwidth),
and prioritize or throttle traffic. For example, QoS can be applied to prioritize the delivery of latency-sensitive traffic (such as voice or video applications) and to control the impact of latency-insensitive traffic such as bulk data transfers. Providing prioritized delivery for TCP/IP traffic requires support from hosts and network infrastructure devices. This column describes the methods for using QoS with Microsoft® Windows®-based hosts.
The central problem of defining QoS for TCP/IP networks is how to specify and provide for prioritized delivery of IP traffic. Although the original RFC 791 for IP defined the Type of Service (TOS) field with the ability to specify precedence, delay, throughput, reliability, and cost characteristics, IP is fundamentally a best-effort, datagram-based packet-switching technology that typically treats each packet the same and on a first-come, first-served basis.

Configuring Prioritized Delivery
To provide prioritized delivery service, there are a few things you can do. You can configure the network infrastructure to provide special handling for marked traffic, and then have the sending hosts mark their outgoing traffic. Alternatively, you can have the sending hosts dynamically program the network infrastructure to provide special handling based on the characteristics of their outgoing traffic (such as addresses and port numbers).
For TCP/IP traffic, you can use a few different methods to provide prioritized delivery. For example, at the Network Interface layer for Ethernet, IEEE 802.1p tagging will mark frames sent by a host for prioritized delivery using a 3-bit Priority field in the virtual local area network (VLAN) header of the Ethernet frame. The VLAN header is placed inside the Ethernet header, between the Source Address field and either the Length field (for an IEEE 802.3 frame) or the EtherType field (for an Ethernet II frame).
Implementing 802.1p tagging on a sending host requires that the network adapter and device driver support 802.1p and that the network adapter has 802.1p support enabled. You can typically enable 802.1p support on the Advanced tab from the properties of a network adapter driver. Ethernet switches also must have 802.1p support enabled.
At the Network Interface layer for IEEE 802.11 wireless, the Wi-Fi Alliance certification for Wi-Fi Multimedia (WMM) defines four access categories for prioritizing network traffic. These access categories are (in order of highest to lowest priority) voice, video, best-effort, and background. Host support for WMM prioritization requires that both wireless network adapters and their drivers support WMM. Wireless access points (APs) must have WMM enabled.
At the Internet layer, you can use Differentiated Services and set the value of the Differentiated Services Code Point (DSCP) in the IP header. As defined in RFC 2472, the DSCP value is the high-order 6 bits of the IP version 4 (IPv4) TOS field and the IP version 6 (IPv6) Traffic Class field.
Most modern enterprise routers support DSCP traffic differentiation, but it is typically disabled by default. During forwarding, DSCP-capable routers read the DSCP value and place the packet into a specific queue. For example, you can configure your routers to place forwarded packets into high priority, best-effort, or lower than best-effort queues based on DSCP values you define. By configuring queues and DSCP values, DSCP-marked traffic can have differentiated levels of service. For example, mission-critical network traffic gets forwarding preference and is not delayed by other lower-priority bulk data traffic. The WMM specification defines how the WMM access categories map to DSCP values. A WMM-capable wireless AP reads the DSCP value and handles the traffic based on its access category.
At the Internet layer, you can also use the Resource Reservation Protocol (RSVP), a signaling protocol defined in RFC 2205. Hosts can use this protocol to attempt to reserve bandwidth across a network to an endpoint. RSVP is not widely deployed on networks, however, and is not currently supported in Windows XP, Windows Server® 2003, Windows Vista™, or the next version of Windows Server code-named "Longhorn" (currently in beta).
To send packets marked for prioritized delivery, applications or operating system components must be able to specify the values of either the 802.1p priority or the DSCP value. The following sections describe how Windows components or Windows-based applications can specify the 802.1p priority for Ethernet frames or the DSCP value for TCP/IP traffic.

QoS in Windows XP and Windows Server 2003
Windows XP and Windows Server 2003 provide APIs for assigning QoS parameters to traffic. Application developers can use the Windows Sockets (Winsock) and Generic QoS (GQoS) APIs to apply QoS parameters at the application level on a per-socket basis. Network administrators can use traffic management tools written to call the Traffic Control (TC) API to apply QoS parameters at the host level.
You can use Winsock and the IP_TOS socket option to set the DSCP value for outgoing packets for a socket. However, by default the TCP/IP stack ignores the IP_TOS socket option. To use the IP_TOS socket option, you must first create and set the DWORD registry value DisableUserTOSSetting=0 under the following registry key (see Figure 1):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Figure 1 Setting the Registry Value of DisableUserTOSSetting
Figure 1 Setting the Registry Value of DisableUserTOSSetting
You must restart the computer for this registry setting to take effect.
To specify the DSCP value for traffic without having to use the IP_TOS socket option, you can use the GQoS APIs. GQoS is part of Windows Sockets 2.0 (Winsock2). Most QoS-enabled applications use the GQoS API to invoke QoS capabilities in Windows. GQoS in Windows XP Service Pack 2 (SP2) allows an application to set a DSCP value and throttle its outbound traffic. To set 802.1p priorities on computers running Windows XP SP2, you must use the TC API.
The TC API provides access to traffic control mechanisms that regulate network traffic on the local host. It allows direct control over DSCP values, 802.1p tags, and throttle rate. Network administrators can use traffic management programs to invoke the TC API directly on behalf of applications that are not QoS-aware. Because it is a lower-level API than the GQoS API, the TC API requires administrator-level privileges.
Unlike the GQoS API, the TC API allows traffic from multiple applications on the same sending host to be aggregated into a single QoS flow. As part of this aggregation, traffic can be identified by a combination of its source and destination IP addresses, source and destination ports, and protocol (TCP or UDP). For example, all of the traffic to a specific destination IP address can be included in a single QoS flow for any source port and destination port, regardless of the sending application on the host. The GQoS API, on the other hand, allows an application to define its own QoS treatment on the data that it sends over a socket.
To support QoS capability, Windows XP and Windows Server 2003-based computers must have the QoS Packet Scheduler component installed and enabled from the properties of network connections in the Network Connections folder (see Figure 2). The QoS Packet Scheduler component (Psched.sys) is installed and enabled by default for computers running Windows XP. The Packet Scheduler component can be installed on Windows Server 2003.
Figure 2 Configuring the QoS Packet Scheduler
Figure 2 Configuring the QoS Packet Scheduler

QoS in Windows Vista and Windows Server "Longhorn"
QoS support in Windows Vista and Windows Server "Longhorn" has been both enhanced and simplified. For IT staff, it is now possible to use Policy-based QoS to set DSCP values and control application sending rates without having to use APIs or modify existing applications. For developers, the GQoS and TC APIs are supported, though support for these APIs is not planned for future versions of Windows. Additionally, the IP_TOS Winsock option has been removed. To replace the GQoS and TC APIs and simplify QoS support in upgraded or future applications, Windows Vista and Windows Server "Longhorn" support the new QoS2 API, also known as Quality Windows Audio-Video Experience (qWAVE).
Policy-based QoS in Windows Server "Longhorn" and Windows Vista allows you to offer better end-user experiences, control bandwidth costs, or negotiate finer service levels with bandwidth providers or business departments. You can centrally manage the network bandwidth of computers running Windows Vista or Windows Server "Longhorn," regardless of the application and across an entire Active Directory® infrastructure. Because the traffic management is occurring below the application layer, existing applications do not need to be modified for Policy-based QoS traffic management.
Policy-based QoS settings in Windows Server "Longhorn" and Windows Vista allow you to prioritize or manage the sending rate for outgoing traffic based on the following conditions:
  • Sending application (executable path and name)
  • Source or destination IPv4 or IPv6 addresses or address prefixes
  • Protocol (TCP, UDP, or both)
  • Source or destination ports or port ranges (TCP or UDP)
QoS policies are applied to a user login session or a computer as part of a Group Policy object (GPO) that is linked to an Active Directory container such as a domain, site, or organizational unit (OU), or they may be applied to a security group. As part of Group Policy, QoS policies build on your existing Active Directory management infrastructure.
Policy-based QoS allows you to define the priority of traffic. You can configure a QoS policy to mark outbound IPv4 or IPv6 traffic with a specific DSCP value. You can also manage the use of bandwidth for outbound traffic. You can configure a QoS policy with a throttle rate for outbound traffic. With throttling, the QoS components limit the aggregate outgoing network traffic to a specified rate. For computers, you can manage the use of bandwidth for inbound traffic, configuring advanced settings to specify inbound throughput for TCP traffic by setting a maximum value for the TCP receive window size.
In Windows Vista and Windows Server "Longhorn," the QoS Packet Scheduler is installed and enabled by default. The Pacer.sys component is a new Network Device Interface Specification (NDIS) 6.0 lightweight filter driver that controls packet scheduling for Policy-based QoS and for the traffic of QoS-enabled applications. Pacer.sys replaces Psched.sys in Windows XP and Windows Server 2003.
To deploy Policy-based QoS on your intranet, configure user or computer-based QoS policies and apply them to the appropriate Active Directory container. Windows Vista or Windows Server "Longhorn"-based computers download and apply their Policy-based QoS settings when they update User Configuration or Computer Configuration Group Policy.
Because networks are increasingly being shared by both data and audio/video (AV) applications, a QoS solution is needed so that time-dependent AV traffic can be given preferential treatment over data traffic. Additionally, networks are increasingly becoming wireless, which introduces additional complications for latency and bandwidth-sensitive applications.
The qWAVE feature in Windows Vista provides a collection of QoS-related software modules that address the network challenges introduced by AV applications and wireless networks. qWAVE is integrated into the QoS subsystem and works with multiple Internet and Network Interface layer packet priority technologies. qWAVE supports multiple AV streams (real-time flows requiring QoS) and data streams (best-effort flows, such as e-mail or file transfers) simultaneously.
The collection of qWAVE technologies detect and monitor LAN bandwidth, discover the QoS capability of the network, and provide distributed admission control for fair and consistent usage of network bandwidth. These technologies enable advanced AV streaming techniques so that applications can dynamically adapt to changing network conditions, and are only available to developers through the QoS2 API.
The QoS2 API in Windows Vista and Windows Server "Longhorn" replaces the GQoS API and IP_TOS Winsock option and you should find it easier to use than the GQoS API.

For More Information
To learn more about QoS, there are a number of excellent sources available through TechNet. Start with the Microsoft Quality of Service Web site. Also check out the QoS section of the Windows Core Networking blog.

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written five books for Microsoft Press® and is the author of the monthly TechNet Cable Guy column.


 Windows PowerShell: Scripting One Line at a Time
Windows PowerShell
Scripting One Line at a Time
Don Jones

In past columns, I’ve stressed the fact that Windows PowerShell is a shell. It’s meant to be used interactively—not unlike the cmd.exe (or command prompt) shell you’re probably already familiar with. Still, Windows PowerShell does support a scripting language—one that’s more robust than the batch language of cmd.exe. And it
is as powerful as, if not more powerful than, languages like VBScript. However, the fact that Windows PowerShell™ is an interactive shell makes the scripting remarkably easy to learn. In fact, you can develop scripts interactively within the shell, making it possible to write scripts one line at a time, immediately seeing the results of your efforts.
This iterative scripting technique also makes debugging easier. Since you see the results of your script right away, you can quickly revise it when things don't go as expected.
In this column, I'll walk you through an example of interactive scripting in Windows PowerShell. I will create a script that reads service names from a text file and sets each service's startup mode to be Disabled.
What I want you to take away from this walkthrough is the concept of building Windows PowerShell scripts in small pieces, rather than trying to tackle an entire script in one big chunk. You can take whatever administrative task you need to accomplish and break it down into its component pieces and then figure out how to make each piece work independently. Windows PowerShell provides excellent ways to tie those pieces together, as you'll see. And you'll find that by working on small pieces at a time, you'll have an easier time developing the final script.

Reading Names from a File
Figuring out how to read text files in Windows PowerShell can be frustrating. If I run Help *file*, all I get is help for the Out-File cmdlet, which sends text to a file, rather than reading from it. No help at all! However, Windows PowerShell cmdlet names do follow a kind of logic I can use to my advantage. When Windows PowerShell retrieves something, the cmdlet name usually starts with Get. So I run Help Get* to display those cmdlets, and then scroll through the list and see Get-Content. Looks promising! So I run Help Get-Content to see more about what it does (see Figure 1), and it looks like it'll meet my needs.
Figure 1 Running Help Get-Content for More Information
Figure 1 Running Help Get-Content for More Information
Windows PowerShell treats nearly everything as an object, and text files are no exception. A text file is technically a collection of lines, with each line in the file acting as a sort of independent object. So, if I've created a text file named C:\services.txt, and filled it with service names (placing each name on its own line within the file), Windows PowerShell can read the names individually using the Get-Content cmdlet. Since the idea of this walkthrough is to show how scripts can be developed interactively, I'll start by just running Get-Content, giving it the name of my text file, and seeing what happens:
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
As expected, Windows PowerShell reads the file and displays the name. Of course, simply displaying the names isn't really what I want, but now I know that Get-Content works the way I expect it to work.

Changing a Service
The next thing I want to do is change a service's startup mode. Again, I start by trying to find the right cmdlet. So I run Help *Service*. This returns a short list, and the Set-Service cmdlet looks like the only one that will fit my needs. I want to test this cmdlet to make sure I understand how it works before I try incorporating it into a script. Running Help Set-Service shows me how the cmdlet should work, and a quick test confirms it:
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Combining the Parts
Now I need to combine the ability to read service names from a file with the Set-Service cmdlet, and that's where the powerful pipeline capabilities of Windows PowerShell come into play. With the pipeline, the output from one cmdlet can be passed as the input to a second cmdlet. The pipeline passes entire objects. In the event that a collection of objects is put into the pipeline, each object is passed through the pipeline individually. That means the output of Get-Content-which, remember, is a collection of objects-can be piped to Set-Service. Because Get-Content is passing a collection, each object-or line of text-in the collection is piped to Set-Service individually. The result is that Set-Service is executed once for each line in my text file. The command looks like this:
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
Here's what happens:
  1. The Get-Content cmdlet executes, reading the entire file. Each line in the file is treated as a unique object, and together they are a collection of objects.
  2. The collection of objects is piped to Set-Service.
  3. The pipeline executes the Set-Service cmdlet once for each input object. For each execution, the input object is passed to Set-Service as the first parameter of the cmdlet, which is the service name.
  4. Set-Service executes, using the input object for its first parameter and whatever other parameters are specified, the -startuptype parameter, in this case.
Interestingly, I've actually accomplished my task at this point-and I haven't even written a script yet. This same action would be difficult to achieve in the Cmd.exe shell, and it would take a dozen lines of code in VBScript. But Windows PowerShell handles all of this in one line. Still, I'm not entirely done. As you can see, my command isn't providing a lot of status output or feedback. Apart from the lack of errors, it's difficult to see if anything actually happened. Now that I've mastered the functionality needed to accomplish my task, I can start making it better-looking by getting into actual scripting.
Windows PowerShell Prompt Here by Michael Murgolo
One of the most popular Microsoft® PowerToys for Windows® (and one of my favorites) is the Open Command Window Here tool. Available as part of the Microsoft PowerToys for Windows XP or in the Windows Server® 2003 Resource Kit Tools, Open Command Window Here lets you right-click on a folder or drive in Windows Explorer to open a command window that points to the selected folder.
As I was learning Windows PowerShell, I found myself wishing it had the same functionality. So I grabbed Open Command Window Here’s setup .inf file, cmdhere.inf, from the Windows Server 2003 Resource Kit Tools and modified it to create a Windows PowerShell Prompt Here context menu. This .inf file is included with the original blog post upon which this sidebar is based (available at leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx). To install the tool, just right-click on the .inf file and select Install.
When creating the Windows PowerShell version of this tool, I discovered that the original had a bug—if Open Command Window Here was uninstalled, it would leave behind a dead context menu entry. As a result, I have provided an updated version of cmdhere.inf, also available from the original blog post.
Both of these PowerToys take advantage of the fact that these context menu entries are configured in the registry under keys associated with the Directory and Drive object types. This is done in the same way that context menu actions are associated with file types. For example, when you right-click on a .txt file in Windows Explorer, you get several actions (such as Open, Print, and Edit) at the top of the list. To understand how these items are configured, let’s look at the HKEY_CLASSES_ROOT registry hive.
If you open the Registry Editor and expand the HKEY_CLASSES_ROOT branch, you will see keys named for file types such as .doc, .txt, and the like. If you click on the .txt key, you’ll see that the (Default) value is txtfile (see Figure A). This is the object type associated with a .txt file. If you scroll down and expand the txtfile key, and then expand the shell key under that, you will see keys named for some of the context menu entries for a .txt file. (You will not see all of them because there are other methods for creating context menus.) Under each of these is a command key. The (Default) value under the command key is the command line that Windows executes when you select that context menu item.
The tools for both the cmd prompt and Windows PowerShell prompt use this technique to configure the Open Command Window Here and Windows PowerShell Prompt Here context menu entries. There are no file types associated with drives and directories, but there are Drive and Directory keys under HKEY_CLASSES_ROOT associated with those object.
Figure A Context Menu Entries Are Configured in the Registry
Figure A Context Menu Entries Are Configured in the Registry

Michael Murgolo is a Senior Infrastructure Consultant for Microsoft Consulting Services. He is focused in the areas of operating systems, deployment, network services, Active Directory, systems management, automation, and patch management.

Scripting Interactively
One thing I need to do is have multiple cmdlets execute for each service that's listed in C:\services.txt. That way, I can output the service name and any other information I like, so that I can track the script's progress.
Before, I used the pipeline to pass objects from one cmdlet to another. This time, however, I'm going to use a more script-like technique called a Foreach construct (which I introduced in last month's column). The Foreach construct can accept a collection of objects, and it will execute multiple cmdlets for each object in the collection. I designate a variable that represents the current object each time through the loop. For example, the construct might start like this:
foreach ($service in get-content c:\services.txt)
I'm still executing that same Get-Content cmdlet to retrieve the contents of the text file. This time, I'm asking the Foreach construct to loop through the collection of objects returned by Get-Content. The loop executes one time for each object, and the current object is placed in the variable $service. Now I just need to specify the code that I want executed within the loop. I'll start by attempting to duplicate my original one-line command (this will minimize complexity and ensure I don't lose any functionality):
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
There's some interesting stuff happening here. Notice that I ended the Foreach construct's first line with an opening curly brace. Everything within the opening and closing curly brace is considered to be inside the Foreach loop and will execute once for each object in the input collection. After I typed { and pressed Enter, notice that Windows PowerShell changed its prompt to >> (see Figure 2). This indicates that it knows I've begun a construct of some kind, and that it's waiting for me to finish. I then typed my Set-Service cmdlet. This time, I used $service as the first parameter, since $service represents the current service name read from my text file. On the next line, I conclude the construct with a closing curly brace. After pressing Enter twice, Windows PowerShell immediately executes my code.
Figure 2 Windows Powershell Knows a Construct Has Been Started
Figure 2 Windows Powershell Knows a Construct Has Been Started
That's right, immediately. What I've typed looks like a script, but Windows PowerShell is actually executing it live, and it isn't stored in a text file anywhere. Now I'll retype the entire thing, adding a line of code to output the current service name:
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Notice that I'm asking it to display something, and I've enclosed that something inside double quotation marks. The quotes tell Windows PowerShell that this is a string of text, not another command. However, when you use double quotes-as opposed to single quotes-Windows PowerShell scans the text string for any variables. If it finds any, it substitutes the variable's actual value for the variable's name. Thus, when it executes this code, you can see that the current service name is being displayed.
This Still Isn't a Script!
Up to now, I've been using Windows PowerShell interactively, which is a great way to immediately see results from what I'm writing. However, at some point retyping these lines of code will become tedious. This is why Windows PowerShell can also run scripts. In fact, Windows PowerShell scripts follow the most literal definition of the word script: Windows PowerShell basically just reads in the script text file and "types" each line it finds, exactly as if you were typing the lines manually. That means everything I've done to this point can be pasted into a script file. So, I'll use Notepad to create a file named disableservices.ps1, and paste the following into it:
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
I've placed this file in a folder named C:\test. Now I'll try to run it from within Windows PowerShell:
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
Whoops. What went wrong? Windows PowerShell is focused on the C:\test folder, but it didn't find my script. Why? Due to security constraints, Windows PowerShell is designed not to run any script from the current folder, thereby preventing any script from hijacking an operating system command. For example, I can't create a script named dir.ps1 and have it override the normal dir command. If I need to run a script from the current folder, I have to specify a relative path:
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
Now what? It's still not working. I've gotten the path right, but Windows PowerShell says it can't run scripts. That's because, by default, Windows PowerShell is not able to run scripts. Again, this is a security precaution designed to prevent the problems we've all had with VBScript. Malicious scripts can't execute under Windows PowerShell by default because no scripts can execute by default! In order to run my script, I need to explicitly change the execution policy:
PS C:\test> set-executionpolicy remotesigned
The RemoteSigned execution policy allows unsigned scripts to execute from the local computer-downloaded scripts still have to be signed in order to run. A better policy is AllSigned, which only executes scripts that have been digitally signed with a certificate issued by a trusted publisher. However, I don't have a certificate handy so I'm unable to sign my scripts, making RemoteSigned a rather good choice for this situation. Now I'll try running my script again:
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
I want to point out that the RemoteSigned execution policy we're using isn't a great choice; it's merely a good one. But there is a much better solution. It would be far more secure to obtain a code-signing certificate, use the Windows PowerShell Set-AuthenticodeSignature cmdlet to sign my scripts, and set the execution policy to the much safer AllSigned policy.
There's also another policy, Unrestricted, which you definitely should avoid. This policy allows all scripts-even malicious scripts from remote locations-to run unfettered on your computer, which can put you in a very dangerous position. Consequently, I don't recommend using the Unrestricted policy for any reason.

Immediate Results
The interactive scripting capabilities in Windows PowerShell enable you to quickly prototype scripts or even just small chunks of scripts. You get immediate results, so you can easily tweak your scripts to get exactly the results you want. When you're finished, you can move your code into a .ps1 file, making it permanent and easily accessible in the future. And remember: ideally, you should digitally sign those .ps1 files so that you can leave Windows PowerShell set to the AllSigned execution policy, the safest policy that allows script execution.

Don Jones is the lead Scripting Guru for SAPIEN Technologies and coauthor of Windows PowerShell: TFM (see www.SAPIENPress.com). Contact Don at don@sapien.com.


 Hey, Scripting Guy!: Chasing Cars... and XML
Hey, Scripting Guy!
Chasing Cars... and XML
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2007_02.exe (150KB)

"I DON’T KNOW why my dog chases cars," goes the old joke. "After all, what would he do with it if he ever actually caught one?"
Good question, and one that the Scripting Guys can’t answer. Well, unless it happens to be Lucy, the dog down the street, who catches the car. We have no doubt at all that that dog would go rob a liquor store and then use the car to make her getaway. And based on the condition of the front lawn, we’re willing to bet she wouldn’t visit any rest stops along the way, if you know what we mean.
If we had to update that old chestnut for today’s high-tech era, it might go something like this: "I don’t know why my system administrator keeps trying to learn XML. After all, what would she do with it if she ever actually learned it?"
Note In our defense, we only said we were going to update that tired old joke; we never said we were going to make it funny.
To be honest, XML might be a somewhat over-hyped technology, at least when it comes to system administration. The truth is, many system administrators have lived long and happy lives without ever writing a script that interacts with an XML file, and we don’t expect that to change any time in the near future.
That said, it’s also true that more and more applications are adopting XML as a standard for data storage. And why not? As nothing more than gussied-up text files, these XML data files are quick and easy to create, are portable across platforms, and require no complicated (not to mention expensive) database program. Got an operating system and a text editor? Then you can create an XML database.
Which means, of course, that there is at least one thing a system administrator can do with XML: write scripts that query an XML file as if that file were a full-fledged database. And, hey, who better than the Scripting Guys to give you a few pointers on doing that very thing?
Well, OK, good point. But if we had to venture a guess, we’d bet that Lucy is probably way too busy digging up someone’s flowerbed to write a column about XML.
To begin with, let’s take a look at a simple XML file (see Figure 1), a database file featuring four scripts found in the daily Hey, Scripting Guy! column.
Figure 1 Hey, Scripting Guy! Scripts in XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
As you can see, it’s a pretty simple little file. Each individual script is filed under a <Script> tag. From now on, we’ll refer to these scripts as records. Yes, you’re right—XML aficionados would never refer to those items as records. But that’s OK; our goal here is to show you how to apply something you already know—database querying techniques—to a new and different kind of data source. We thought we’d first focus on how to get things done, then maybe return to this topic in the future and supply you with the proper terminology.
OK, back to records. Each record contains the following fields: <Category>, <Subcategory>, <Keyword>, <Title>, and <URL>.
Hmm, you’re not quite as impressed as we thought you’d be. Maybe it would help if we showed you a script that could open up this XML file and echo back the contents:
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Note Be careful: these tag names are case-sensitive. It’s "/Repository/Script," not "/repository/script" or "/REPOSITORY/SCRIPT".
Granted, that’s not particularly impressive either. But that’s the point: this isn’t anywhere near as hard as you might expect.
As you can see in the code, we begin by creating an instance of the Microsoft.XMLDOM object, the COM object used for working with XML files. After that, we set the Async property to False; this helps ensure that the entire file is read into memory before control is returned to the script. We then use the Load method to read the file C:\Scripts\Scripts.xml:
xmlDoc.Load("C:\Scripts\Scripts.xml")
As soon as the file has been loaded into memory, we can use the selectNodes method to select the specified records from the database:
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Take a close look at the parameter passed to selectNodes. As it turns out, this represents the path within the XML file. Our XML file has the following structure:
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
Should you care about that? In a word, yes! When dealing with XML files, the structure is very important. For example, how do we get to the individual properties of a record? That’s easy: we access the <Repository> tag followed by the <Script> tag followed by the individual property tags. And guess what? That’s the same path we specify as the parameter to selectNodes. We simply follow that path with /*, which means "Select all the properties for these records." In other words, our returned collection will consist of all the properties for all the records in the database—akin to a "Select * From" query in Windows® Management Instrumentation (WMI).
Note Give the sample script a try and you’ll see exactly what we mean.
The rest of the script is easy; all we do is set up a For Each loop to walk through the collection and echo back the value of the Text property for each item and each property:
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Way easier than chasing cars.
But you’re right: if all we wanted to do was echo back the entire contents of the file, we could have bypassed all that XML stuff and just used the FileSystemObject. (It might have been a tad bit more complicated, but just a tad.) If our intention was to dazzle you and make you think "Wow, this XML stuff is pretty handy after all," well, we probably still have a ways to go.
So let’s see what we can do about that. In the first script, we got back all the property values for all the records. That’s fine, but suppose all we really wanted to get back was the script title? Can we do that? Um, just a second ...
OK, according to Lucy all we have to do is modify our selectNodes command, adding the property of interest to the end of the path. In other words:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
As it turns out, the only reason we got back all the properties the first time is because we used the * wildcard character. Now we get back only the Title property. Why? Because that’s the only property value we asked to get back.
Note Hmmm, look at that: XML gives you exactly what you ask for. No offense, Lucy, but we think XML is man’s new best friend!
And, sure, you can return more than one property. For example, this modified command returns values for both the Title and URL properties:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
Admittedly, the syntax is a bit awkward-looking, but once you get used to it, it’s not too bad. To begin with, we specify the parent portion of the path, just like we did before:
    /Repository/Script/
We then add in a set of parentheses and, inside those parentheses, specify the properties to be returned. (Notice that we use the pipe separator—the | character—to split up the individual properties.) In other words:
    (Title | URL)
Like we said, it’s maybe a little goofy, but it works.
And no, you’re not limited to returning just two properties. As long as you keep adding in pipe separators you can return all the information your heart desires. For example, the command that follows returns three properties (Title, URL, and Keyword):
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Cool, huh?
Well, we thought it was cool. You guys are a tough crowd. But, again, you have a good point: all we’ve done so far is retrieve information about all the records in our database. However, there’s nothing wrong with that. Oftentimes that’s exactly what you want to do. On the other hand, there will also be times (lots of times) when we want to retrieve information about only a subset of those records. For example, maybe we want to get back information only about the scripts that have a Keyword equal to databases. You know, by using a query similar to this:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
Again, the syntax is a little weird. On the bright side, however, the syntax is also easy and straightforward. After specifying the parent path we place our "Where" clause (for example, where x equals y) inside square brackets, like so:
/Repository/Script [Keyword = ‘databases’]
As you probably already figured out, our Where clause equivalent tells the script "Return only those items where the Keyword attribute is equal to databases." Notice that databases is enclosed in single quotation marks. Not only is that perfectly fine, it’s pretty much required. If the filter term is enclosed in double quotation marks, you’ll get a syntax error when you try running the script.
Note Why? Because, remember, the entire query string—"/Repository/Script [Keyword = ‘databases’]"—is enclosed in double quotes.
Of course, you aren’t limited to using the equals sign (=) when filtering data. You can use greater than (>) or less than (<) signs, as well as everyone’s favorites, the less than or equal to (<=) and the greater than or equal to (>=) signs. You can also negate any of these signs by placing an exclamation mark in front of it. For example, this command requests all the scripts where the Keyword is not equal to databases (note the !=):
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Wait a minute: who said, "Sure, you can set a filter, but I bet you can’t set a filter and specify the properties you want returned"? Of course you can:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
If all goes well, this command will return just the Title property for all the scripts that have the Keyword databases. Let’s see if it works:
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Let’s see if we can fit in one more command before we call it a day. Although we’re making progress, we might still be returning more records than we really want to return. After all, our preceding command returns a mixture of Microsoft® Access® scripts and Microsoft SQL Server™ scripts. (Why? Because all of these scripts use the Keyword databases.) What if we wanted to limit the returned data to scripts that have databases for a Keyword and that have Microsoft SQL Server as a Subcategory? Is it possible to filter on multiple criteria?
As if you had to ask:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
It’s the same basic syntax; we’ve just used two separate criteria (namely, Keyword = ‘databases’ and Subcategory = ‘Microsoft SQL Server’) and connected the two using the AND operator.
Note Yes, you’re right: with this simple little XML file we could have just requested all the scripts where the Subcategory was equal to Microsoft SQL Server. But that wouldn’t have been any fun, and nowhere near as educational.
You can also use OR clauses. For example, suppose we had a whole bunch of Microsoft Office scripts, including those with Subcategories equal to Microsoft Excel®, Microsoft PowerPoint®, Microsoft Outlook®, and so on. Is it possible to restrict the returned data to just those scripts from the subcategories Microsoft Word or Microsoft Access? You bet it is:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
Is that more like it? Granted, this might not qualify as a column that changed your life forever; still, there’s a good chance that, sooner or later, being able to query an XML file in this manner will come in handy. But the decision is yours: you can learn some basic XML techniques or you can chase cars. It’s up to you. (If you choose the latter and you happen to met up with Lucy, the dog down the street, tell her the Scripting Guys say hi. And tell her to stay out of our yard!)
Hey, Scripting Guy! - Every Day
You’ve just perused this month’s Hey, Scripting Guy! column and thought it was the greatest piece of technical material you’ve ever read. You might even go so far as to say it’s the greatest piece of written material ever. What’s more, you’re eagerly standing by your mailbox in anticipation of your next issue of TechNet Magazine, just so you can read more articles like this.
What in the world are you waiting for? Want to know more about Lucy the neighborhood dog, or read about the latest exploits of the Scripting Son? Did you hear how the annual Turducken Bowl went last year? Stay abreast of all these important issues by reading the daily—yes, we said daily—Hey, Scripting Guy! columns. Every Monday through Friday (minus major holidays and Scripting Guy vacations), you can read all about high school baseball, college football and basketball, and occasionally get a local weather report. (Admittedly, it’s only local if "local" means Redmond to you, but who doesn’t want to know what’s going on with the weather in Redmond?)
Not only that, but you’ll actually learn something new about scripting each day. Yes, embedded amidst all this riveting content is actual scripting information. In each column, the Scripting Guys answer real questions submitted by what they assume to be real people. You can read the daily column online at microsoft.com/technet/scriptcenter/resources/qanda. Also, since they’ve already answered hundreds of questions, the archives are quite extensive and thus a great source of scripting information (see microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
Do you have a question for the Scripting Guys? You stand a slim chance of getting your question answered by submitting it to scripter@microsoft.com. (In contrast, you stand no chance if you don’t submit it, so what have you got to lose? Unlike a lottery ticket, it’s free, and your odds are slightly better.)

The Microsoft Scripting Guys work for—well, are employed by—Microsoft. When not playing/coaching/watching baseball (and various other activities) they run the TechNet Script Center. Check it out at www.scriptingguys.com.


 Security Watch: Deploying EFS: Part 1
Security Watch
Deploying EFS: Part 1
John Morello

By now, everyone has heard reports about personal or sensitive data being lost because of laptop theft or misplacement. Laptops go missing on a regular basis. With identity theft on the rise and regulatory compliance more critical than ever, the thorough protection of data on mobile computing systems is essential.
One answer is to use Encrypting File System (EFS), included in Windows® since Windows 2000, which provides built-in, high-performance, disk-based encryption. EFS integrates seamlessly with Windows Explorer so end users often won't even know when a file they're using is encrypted. Additionally, EFS works equally well with native Windows authentication and access-control technologies so that users don't need to remember separate passwords to access their data. Finally, EFS provides manageable options for recovering data in cases where a user may lose access to his encryption keys (such as if his user profile is deleted or damaged or his smart card is lost.)
EFS uses the built-in cryptography technology in Windows to generate, store, and deploy strong encryption keys to protect data. In Windows XP Service Pack 1 (SP1) and later versions, EFS utilizes the Advanced Encryption Standard (AES) algorithm with a 256-bit key to encrypt data on disk. These symmetric keys are then protected with an asymmetric (RSA) key pair. EFS encrypts each file with its AES key, then encrypts this key with the user's RSA key and stores the result in the file. For more information on EFS cryptography, see the "EFS Resources" sidebar. For now, I'll focus not on the technical underpinnings of EFS but rather on how to deploy it and make it viable in your environment. For this reason, the article assumes a prior knowledge of EFS cryptography concepts.

A Note on EFS Security
There are some applications that claim to be able to crack or break EFS encryption. None of these applications actually decrypt the AES (or Data Encryption Standard, DES, or Expanded Data Encryption Standard, DESX) encrypted ciphertext, but rather gain access to the user's EFS private key by brute-forcing the user's password. The important thing to keep in mind about EFS encryption is that the private keys used to generate and protect the encrypted data utilize the Data Protection API (DPAPI). DPAPI uses derivatives of a user's logon credentials to protect data so the end result is that data protection with EFS is only as good as the user's password. With Windows Vista™, you can now store EFS encryption certificates on smart cards, which changes this paradigm and greatly increases the relative security of EFS protected data.
How long does a password need to be to be resistant to these attacks? Given today's hardware capabilities and modern password attack algorithms, an 11-character or greater password (or, more correctly, passphrase) is recommended. An 11-character or longer passphrase is highly resistant to today's most advanced methods, including precomputed hash attacks (such as Rainbow Table; see the blog posting "Why you shouldn't be using passwords of any kind on your Windows networks" listed in the "Resources" sidebar for more information).

To PKI or Not to PKI?
One of the most common misconceptions about EFS is that it requires a public key infrastructure (PKI) to work. While EFS can easily integrate with and take advantage of a PKI should your organization already have one, it is by no means a requirement. That said, the decision regarding whether or not to use a PKI in your EFS deployment will impact many future deployment decisions, so it should be examined first.
The primary advantage of using a PKI with EFS is the ability to perform key archival and recovery. Whereas EFS alone will allow administrators to perform data recovery, automatic key recovery is only available with a PKI, and even then, only when running Windows Server® 2003 Enterprise Edition as your Certificate Authority (CA). Data recovery is the process in which a user who loses access to his encryption key can provide his encrypted data to a designated administrator known as a Data Recovery Agent (DRA), who can then either decrypt that data and return it to the user or re-encrypt it for use with a new private key. The DRA works as a shadow to the user's encryption process whereby everything that the user encrypts with his key is also encrypted with a copy of the DRA key. Thus, when the user's key is lost, the DRA can step in, get the ciphertext data, apply the DRA key to it for decryption (or re-encryption), and then return the data to the user. The DRA approach works well, but can be difficult to manage if the user has encrypted large amounts of data or does not have local IT staff to act as DRAs.
Key recovery, on the other hand, requires that the CA make a copy of the user's encryption key during the key creation process and securely store the copy of that key in the CA's database. Then, when a user loses access to encrypted files, the CA administrator only needs to go into this database and retrieve the user's key. At that point, the user will immediately have access to his data again without having to have a DRA recover it for him. When done this way, key recovery can be faster and more efficient. Note, however, that a best practice is to always have DRAs in place, even when using key recovery, to provide a backup mechanism for key loss events. This also allows large organizations to have a distributed recovery system where local IT administrators can recover users' data without having to ever involve the PKI administrators group.
Another potential benefit of using a PKI with EFS is to facilitate easier sharing of encrypted files. Recall that EFS is not limited solely to laptop systems; it can be equally valuable in any situation where the physical security of a computer cannot be guaranteed. In these situations, there may be a need for multiple users to access the same encrypted data. While Windows support for sharing encrypted files is somewhat limited because it only allows for sharing individual files, not directories, it can be a useful tool. To facilitate sharing of EFS files, the user who is sharing the file must have access to the public keys of the users he is sharing with (which is easiest if those users have a valid EFS certificate published to their account in Active Directory®). While it is possible to perform this publishing manually, using a Windows CA installed in Enterprise (Active Directory-integrated) mode makes the process fully automated.

EFS Key Management
If you have a Windows Server 2003-based PKI available to use, generating users' EFS certificates is a simple process. A Windows Server 2003 CA comes with a default set of certificate templates, including one called Basic EFS. However, this template is a version 1 template and does not support key archiving. So, before making it available on your CA, you will want to duplicate the template to create a new version 2 template (for example, you could call it EFS with Key Archive, as shown in Figure 1). On this new template, go to the Request Handling tab and select the option to archive the user's encryption key. Note that you'll need to have key archiving properly configured on the CA before enabling this option. The resources section includes an excellent walkthrough of the process. You should also set this template to supersede the Basic EFS template to ensure that clients will use this new version (see Figure 2).
Figure 1 EFS with Key Archive
Figure 1 EFS with Key Archive
Figure 2 Supersede the Basic EFS Template
Figure 2 Supersede the Basic EFS Template
Next, you'll need to set the proper permissions on the template to allow the right set of users to have enroll access to it. Because the EFS component in Windows will automatically request a certificate the first time EFS is used, you do not typically need to allow users to autoenroll against the EFS template. In fact, I'd recommend against enabling autoenrollment for EFS certificates unless you're sure that all autoenrolled users will be using EFS. Figure 3 shows the EFS enrollment settings. By issuing certificates to users who may never use EFS, you're increasing the size of your CA database for no benefit. Though the CA database itself isn't limited in size, it can become more difficult to manage (particularly through the Microsoft Management Console, or MMC) as you increase the number of certificates issued.
Figure 3 Setting EFS User Permissions
Figure 3 Setting EFS User Permissions
Finally, if you need to support the sharing of encrypted files, you may want to have the CA automatically publish the user's certificate to Active Directory.
Once you have configured the template properly on your CA, the first time a user goes to encrypt a file with EFS, he will get his certificate from your CA and your CA will automatically archive his private key.

DRA Key Management
The next question to consider if you have a PKI in place is whether or not to utilize CA-generated DRA certificates. Why would you not want to use DRA certificates from your PKI? Consider a scenario where you have an issuing CA with a fairly short certificate validity period (two years or less). That CA will not be able to issue any certificates with validity lifetimes longer than its own, which would mean that your DRA certificates would have (at most) a two-year lifespan. This can result in a significantly more complex data recovery scenario. This hypothetical example is illustrated in the following scenario.
  1. A user encrypts a file in January 2006; the DRA certificates that are pushed down to her machine via Group Policy have a two-year span (they expire in January 2008).
  2. The user continues working with EFS, encrypting new files.
  3. In January 2008, the DRA certificates expire and the administrator then pushes down new certificates via Group Policy.
  4. Any encryption operations from here on utilize the new DRA certificates (including any files she opens that were encrypted with the old DRAs; when they're saved, they'll utilize the new DRAs) but any files she does not touch going forward will still be protected only with the old DRAs.
  5. The user accidentally damages her profile and requires data recovery.
  6. The IT administrator must now have two sets of DRA certificates: the new ones for any files touched since Step 3 and the old one for any files not touched since then.
While it is possible for the IT administrator to run a script after Step 3 to update all files with the new DRA (using cipher.exe /u), this can be a time-consuming process. Also, to be clear, the DRA keypairs aren't useless after they've reached their expiration date, although the EFS component will not allow any new encryption operations if an expired DRA certificate is included in its recovery policy. Old files encrypted with expired DRA keypairs can, of course, still be recovered by them. Thus, DRA keypairs should never be discarded, even after their validity lifetime has expired; you simply don't know when you'll need to use them.
For these reasons, I recommend that environments that have CAs with short certificate lifespans employ self-signed DRA certificates with longer lifespans. The cipher utility includes a switch (cipher.exe /r) that automatically creates EFS recovery agent keypairs with a lifetime of 100 years (see Figure 4). The certificate from this keypair can then be attached to Group Policy Objects (GPOs) and used as a DRA throughout your organization. Because the EFS component does not check the trust chain of DRA certificates, these self-signed certificates will work without having to make any changes to the list of Trusted Root Certificate Authorities on your systems. Regardless of the lifespan of an organization's CA, I always recommend creating at least one long-lived DRA certificate and attaching it to a domain-wide GPO. This is the fallback data recovery option to use in case all other options fail. This is particularly vital if you're using CA-generated DRA keys in the absence of a CA key archive. Should a DRA certificate ever be compromised you can update the GPO with a new certificate and use cipher.exe /u as discussed earlier to update your files.
Figure 4 Running Ciquer /R
EFS Resource
You can get lots more information on EFS particulars and best practices by visiting the following sites.
  • Why you shouldn’t be using passwords of any kind on your Windows networks
  • Implementing Key Archival Walkthrough
  • Encrypting File System in Windows XP and Windows Server 2003

KRA and DRA Deployment
Key archiving provides the ability for CA administrators to recover escrowed encryption keys on the user's behalf. Obviously, this is a very sensitive and powerful capability because it can allow a CA administrator to decrypt any data in the organization that utilizes a key signed by the CA. Thus, key archiving and recovery should be treated carefully and only a small number of trusted security personnel should be given this permission. Because of the sensitive nature of key recovery, if you'd like to rely on it as your primary mechanism for regaining access to EFS-encrypted data, it's important to have a clearly defined escalation process for recovery requests to be sent to your CA administration team. Only after the request has been carefully vetted should the recovery process be initiated. Then, once the key is actually recovered, it should be provided to the user via a secure method (in other words, not through e-mail) since the recovered key provides access to all the user's EFS-protected data.
Key Recovery Agent or KRA keys are generated and held by CA administrators and are not advertised via Group Policy. In fact, EFS itself can't determine whether or not a key it utilizes has been archived; it simply performs its encryption operations as it normally would. Additionally, the KRA keys created on the CA are not specific to EFS in any way. A CA using key archiving will have n number of KRA keys attached to it at the CA level that will be used to protect any key archived by the CA. These keys can include those used with EFS, secure e-mail, or any other certificate purpose that includes encryption. KRA keys should be securely stored by the individual key recovery agents and there should be at least two KRAs used to provide a fallback in case one of the keys is lost.
The first time an administrator logs on to the domain controller in a newly created domain, a default recovery policy will be created at the domain level using a self-signed certificate and keypair stored in the administrator's profile on the DC. This DRA certificate will have a validity lifetime of three years. The recommended approach is to remove this default certificate and replace it with longer-lived self-signed certificates or certificates issued from your PKI. If you do not remove this default self-signed certificate, three years after its creation EFS will stop encrypting new files throughout your domain. This is because the certificate will have expired and EFS will prevent the encryption of any further data when an expired DRA certificate is included in its recovery policy. While it is possible to operate Windows XP and later systems with no recovery agent policy in place, this is strongly discouraged. Doing so means that if a user loses access to his encryption key for any reason and key recovery isn't possible, all his data will be irrevocably lost.
As I've said, DRA keys can be either self-signed or issued from a CA. In most cases, a hybrid approach is best, with at least two long-lived, self-signed DRAs used enterprise-wide as a recovery agent of last resort. Because DRA certificates are deployed via Group Policy Objects, they possess the same inheritance capabilities as other GPOs. In other words, the standard Local, Site, Domain, organizational unit (OU) GPO accumulation and application algorithm that controls the application of other GPO settings also applies to DRAs. Thus, an organization can easily implement a tiered approach to DRAs, where the central IT group has DRA access to every part of the enterprise, but where local IT groups also maintain the ability for their specific areas of responsibility. This is a particularly valuable asset in large, geographically dispersed organizations since it alleviates the need to transfer large amounts of encrypted data over WAN links to facilitate data recovery. Figure 5 illustrates a typical DRA deployment with multiple tiers.
Figure 5 Multitier DRA Deployment
Figure 5 Multitier DRA Deployment
In this case, a user in the Baton Rouge OU would end up with six DRAs for each encrypted file: two from his local administrators, two from the North America IT group, and two from the domain level. Thus, if the user was to lose access to his encrypted data, he could have it recovered by a local DRA in Baton Rouge or by the North America IT group. As a final fallback, if these four DRAs were unavailable or lost, the domain-level DRAs could take over and recover the data as well. Regardless of which DRA performed the recovery, the process would be essentially the same. The user would first make the data available to the DRA. It's important that the DRA take the necessary steps to ensure that the request is legitimate and coming from the true owner of the data. Once that is done, the DRA would load the DRA certificate, decrypt (and preferably re-encrypt) the data, and then send the data back to the end user. Some organizations also choose to perform local recovery, where the DRA would physically visit the problem user, load his DRA keypair into the profile, then decrypt the data and remove the keypair. The user would then have access to the data in plaintext form and could re-encrypt it with a new key. It should be noted that this approach is far less secure because the DRA keypair is copied (though temporarily) to the local machine, but it can save some time, particularly if a great deal of data must be recovered.
Note that if recovery were to be provided to the user through key archiving and recovery, the recovery request would be handled entirely separately from this process. Instead of utilizing a DRA at all, the user's key recovery request would go to the CA administrators, who must vet the request, then go into the archive and retrieve the user's private key. They would then make this private key available to the user securely, such as by placing it on a secure Web site for download. (If the user was taking advantage of a smart card to store his EFS key, available with Windows Vista, then that key should also be reissued.) The user would load this key into his profile and would then have immediate access to all his encrypted data.
Because the DRA and KRA keypairs can be used to decrypt sensitive data, it's important that they be properly protected. DRA and KRA keypairs should not be stored in the normal desktop profiles of administrators (the profiles in which they do their normal daily tasks). Rather, these keypairs should be safely stored offline on floppy, optical, or flash media kept in a physically secure location. Then, when recovery is needed, the recovery agent can load the keypair onto a recovery workstation from this media, perform the recovery operation, then remove the keypair. In some particularly security-sensitive organizations, dedicated workstations are designated for recovery to further increase the security of these keypairs, but this is not a requirement for all organizations.

Next Time
Now that I've examined the key management, data recovery, and Active Directory sides of EFS planning, I'll focus on client-side deployment questions in Part 2 of this topic, coming next month. There I will cover topics such as controlling EFS usage through Group Policy, choosing what to encrypt, automatically encrypting data through logon scripts, and client-side enhancements for Windows Explorer to make working with EFS-protected data even easier.

John Morello graduated summa cum laude from LSU and has been with Microsoft for six years in a variety of roles. As a Senior Consultant, he has designed security solutions for Fortune 100 enterprises and Federal civilian and defense clients. He’s currently a Program Manager in the Windows Server group working on security and remote access technologies.


 The Desktop Files: Extending Windows PE
The Desktop Files
Extending Windows PE
Wes Miller

Even before we released Windows PE over five years ago, eager customers were already asking for more features. Unfortunately, Windows PE wasn’t designed to be easily extended the way that, say, Windows XP Embedded can be—by adding in additional layers of the operating system. Of course, Windows PE had to have rudimentary
Win32® support (so most Windows® applications would work), and networking and mass-storage support (to communicate over the network and be able to install Windows). But even from the start the shell was something we wanted to constrain; by using cmd.exe instead of the traditional Windows Explorer shell, we limited what the Windows PE environment could do and, more importantly, we made it so the default environment was easily scriptable for all automation tasks.
Still, you can extend Windows PE—you just have to remember that it is limited. You can expect that your application may not work or may behave incorrectly if it requires any of the technologies listed in Figure 1 (this list is not comprehensive).
Figure 1 Missing Windows APIs (Close Figure 1)

.NET Framework (any version)
Active Directory® Services Interfaces (ADSI)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (pre-.NET versions included)
Any executable type that requires a framework that isn't installed with Windows natively.
Windows Explorer or Internet Explorer
Windows Media® Player
SAPI, MAPI, TAPI (Windows Speech, Mail, Telephony APIs, respectively)
If you don’t know what your application depends on, you need to find out. But how? When we were trying to get the ADO, HTML Applications (HTA), and Windows Script Host (WSH) components to work under Windows PE before we released it, we faced the same issue. It should be noted however, that while this article will describe ways for you to track down these dependencies, adding any Windows binaries to your Windows PE image beyond what the MKIMG command includes is not covered by the End User License Agreement (EULA). You’ll need to acquire a licensing addendum from Microsoft in order to implement changes of that nature in your environment.

Understanding Dependencies
If you open up an application’s .inf file in Notepad and carefully examine it, you can learn a great deal. In fact, this is often the easiest way to make sense of an application and see what dependencies it has. The important thing to know about Windows PE is that generally it’s so pared down that you’ll have to debug multiple levels of dependencies—both your application’s own direct dependencies and the dependencies that each of those may bring in—in order to get your application running reliably. In essence, a pretty big cascade of dependencies can occur if you aren’t careful. With a few accidental (or purposeful) component additions, your image can grow considerably in size and complexity.
If you do have a .inf file that describes the application, you can get clues about dependencies by finding registry keys and files that the .inf adds to your system. Look for the CopyFiles and AddReg sections. These entries will point to apps, DLLs, and other files that your application depends on. Of the three add-ins for Windows PE (ADO, HTA, and WSH), WSH was the simplest to create. Because a redistributable version of WSH was still available for older Windows versions, and because there is a .inf built into Windows today that performs the file associations for WSH (at %windir%\inf\wsh.inf), installing it into Windows PE was relatively easy.

Orca and Snapshotting
If the application in question is distributed as a Microsoft® Installer (MSI) file, you can do two things to locate dependencies. If you’re an MSI guru, you can use Orca (a tool for editing Windows Installer files that is distributed as a part of the Windows Server® 2003 R2 Platform SDK: go.microsoft.com/fwlink/?LinkId=77941) to view it. You can also install the MSI for the components you want, performing a before-and-after analysis of the files and registry keys that have changed. You can do a dump of the registry, install the app, export the registry again, and then run WinDiff against it (see the "Using WinDiff" sidebar). The result can then be used as a template for changes that need to be made to the registry. The problem is that the number of changes can be mind-numbing. Nevertheless, it may be the best option if you don’t have a .inf (or the application’s author) handy.
You may be familiar with the process of application snapshotting. In essence, it’s that same before-and-after analysis you perform to get your application to run. Microsoft used to distribute (with Windows 2000) a tool that did this but that tool doesn’t work with any newer version of Windows. A number of commercial applications (installation repackagers) can do it, but so do some free utilities. For one solution, install the Platform SDK (see the link in the previous paragraph), which includes WinDiff. Note that to perform the WinDiff comparison, you ideally want to install the application on Windows Server 2003, Service Pack 1 (SP1) because that’s the version of Windows PE you should be using—Windows PE 1.6 as built from Standard Edition or Enterprise Edition (with SP1). By performing this task on Windows Server 2003 you’ll have the environment closest to what you would get on Windows PE (where obviously you can’t execute an MSI). Follow the steps in the "Using WinDiff" sidebar.
This will show you a fair amount of information that has changed. Regrettably, there isn’t an easy way to export the changed information from registry or file captures to create a manifest of some type to install your application. You need to incorporate the changes manually. This is where we encountered some of our toughest issues with the first version of Windows PE. Getting the HTA components working at all was complex since there was no definition for them (outside of Internet Explorer®) within Microsoft. By using differencing, we were able to hand-stitch enough HTA support so it would function. While you can manually add these keys into the Windows PE registry, you may want to add the keys after Windows PE has started. You can look at the OC.bat and OC2.bat files used to install HTA, WSH, and/or ADO support into Windows PE via the buildoptionalcomponents.vbs script included in the Windows PE build tools.

Helpful Tools
Even after isolating the direct dependencies, you often can’t find every binary your application depends on. You won’t know, for example, if it requires another DLL or OCX to perform some task. So, how can you tell? Mark Russinovich of Sysinternals fame (now a Technical Fellow at Microsoft) wrote a handy utility called listdlls that does exactly that. Listdlls can be downloaded from microsoft.com/technet/sysinternals/utilities/ListDlls.mspx. To use the utility, run the command listdlls.exe > dlls.txt and then examine the output. Figure 2 shows the output of listdlls run on itself. You can compare this list to the DLL and OCX files included in Windows PE to determine whether all of your application’s dependencies are in place or not (in the case of listdlls, they’re already present). For HTA support in Windows PE, listdlls was critical for identifying some dependencies that could not be identified otherwise.
Figure 2 Output of Lisdlls Run on Itself
Figure 2 Output of Lisdlls Run on Itself
But just because a DLL is listed doesn’t necessarily mean the application requires it to function. If you load Notepad, for example, you’ll see it loads uxtheme.dll. Under Windows PE, this DLL isn’t available and, in fact, since Windows themes aren’t used, it will never be loaded. Learning which of the DLLs listdlls shows you are actually required versus which are loaded on demand by Windows is, unfortunately, a dark art that will require either a fair amount of trial and error or that you become very familiar with low-level aspects of Windows (For this, I recommend Mark Russinovich and David Solomon’s book, Microsoft Windows Internals, Fourth Edition (Microsoft Press®, 2004).
In fact, Mark also includes the same functionality in the freely available Process Explorer replacement for Windows Task Manager. The difference is that listdlls creates output that, in my opinion, is more easily scripted and used for finding and collecting missing dependencies.
Note that even once you add a DLL to your image, you may still have some work to do. That is, there are two types of DLLs: those that require registration and those that do not. Unfortunately, there isn’t an easy way to tell them apart, short of trying to register each one. In order to register a DLL (or an OCX), you run regsvr32 dllname.dll. If it works correctly, you receive a dialog telling you the DLL was registered. If not, you may not receive a message or more likely you’ll see a dialog box informing you either that the DLL failed to register or that it couldn’t be registered. While developing the HTA and ADO optional components for Windows PE, we discovered that DLLs require writable storage when performing their registration, either to temporarily write a .inf file for installation or to record some other dependency (say, a specific directory they require). In Windows PE, this used to mean failure. Thankfully, with Windows PE 2.0, tasks like these will just work, since there is scratch space available by default.
A third tool Mark created and recently released is called Process Monitor. Process Monitor can be viewed as a superset of Regmon and Filemon, yet provides significantly more detail than either while adding a whole new layer of interprocess communication. This incredibly powerful tool can help you troubleshoot applications in Windows as well as help you answer questions about what’s really happening with DLL interdependencies. Process Monitor can be downloaded.

Removing Windows PE files
Along with the ability to add things to Windows PE, another frequent request was for instruction on how to make Windows PE smaller. There are steps you can take to reduce the size of Windows PE a bit. Your licensed copy of Windows PE should include a collection of build tools and some documentation. One of the documents is a help file named winpe.chm. If you open this file and explore the Windows Preinstallation Environment User’s Guide section, you should see a topic entitled Reducing the Size of Windows PE. This section lists a collection of files you can safely remove (assuming you don’t need them). You’ll find three sections regarding the removable files:
  • Font files can always be safely removed.
  • Networking-related .inf files and utilities can be removed, but only do this if you don’t plan to use your build on the network at all.
  • Command-line utilities should not be removed. I don’t recommend removing any of these unless you explicitly know what it does and what might happen if you remove it.
Once you’ve determined which files you can safely exclude, you can simply write a batch file or other script and remove them from your Windows PE build once mkimg.cmd has completed the build.

Modifying the Windows PE Registry
You can see that we made a conscious choice to not install the optional components at build time. Though this meant a bit more time at run time, it also meant we didn’t have to engineer a completely new way to stitch these components back into Windows PE—something we didn’t have time to do and that would have most likely meant omitting them entirely. But what if you want to make a registry change, such as adding in the delta of registry changes for your application, or you simply want to edit a key that might be keeping the application working? This is accomplished easily, using regedit, which is shown in Figure 3. Follow these steps:
  1. Run regedit and select the HKEY_LOCAL_MACHINE hive.
  2. Select File | Load Hive, then browse to the location of your Windows PE build. Select setupreg.hiv under I386\System32\ (or MiniNT\System32, if this is an image you are putting on a hard drive).
  3. Enter a temporary name for the hive, such as WinPE, and browse to that node under HKLM.
  4. Modify this key accordingly. Interestingly, note that this node is effectively the same as the node HKLM\System would be on a normal Windows installation.
  5. Once you’ve made your modifications, select the key under HKLM you created in Step 3 (it is very important to do this correctly or you could damage your system).
  6. Select File | Unload Hive... and confirm the Yes | No dialog, and ensure you dismount the registry every time, as having it locked will prevent a successful build of Windows PE.
Figure 3 Opening the Windows PE Registry
Figure 3 Opening the Windows PE Registry
By following these steps you can modify HKLM\System. There are also two other keys located under I386\System32 that let you modify other areas of the registry: DEFAULT is the default hive for users (even SYSTEM, which you run as while using Windows PE), and SOFTWARE, which is the same as HKLM\Software. As always, modify the registry with care and only as required.
Now you have some insight that should help you get started moving your favorite troubleshooting or recovery tool onto Windows PE. Next month, I’ll discuss the PSTools suite—which is a collection of very useful system management tools also written by Mark Russinovich.
Using WinDiff
WinDiff can help you find your application’s dependencies. Just follow these steps for successful installation and execution:
  1. Get your system prepared for the installation—you want to minimize the time and any file or registry changes between the initial and final snapshot.
  2. Open a command prompt and run reg export HKLM C:\HKLM1.reg to perform a complete export of the HKEY_Local_Machine registry hive.
  3. Run dir C:\*.* /S > C:\C1.txt to perform a compete dump of all files on the C: drive (assuming C: is your system drive).
  4. Install your application and configure any post-install settings.
  5. Run reg export HKLM C:\HKLM2.reg.
  6. Run dir C:\*.* /S > C:\C2.txt.
  7. Open WinDiff, and select File | Compare Files... and select HKLM1 .reg in the first File Open dialog, and HKLM2.reg in the second.
  8. You should see a message in red denoting which is newer. Be patient; this may take some time as the HKLM exports can be quite large.
  9. Double-click the text in red to expand the differences.
  10. You may want to configure what is shown in the comparison by checking Options | Show Right-Only Lines. This will enable only newly added lines in the second compared file to show up (so only new files and new registry keys will appear).
Note that you may need to use the Find function to locate keys related to your application. In Figures A and B, you can see file and registry changes for a fictional application I created. Happily, copy and paste are available in WinDiff. To use these functions simply click on the !> line and select the desired lines.
Figure A WinDiff Entries
Figure A WinDiff Entries
Figure B Specific Key in WinDiff
Figure B Specific Key in WinDiff

Wes Miller is Development Manager at Pluck www.pluck.com in Austin, Texas. Previously, Wes worked at Winternals Software in Austin, and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.


 Field Notes: It Just Stops Working
Field Notes
It Just Stops Working
R'ykandar Korra'ti

"I DUNNO, I just keep getting dropped."
"Any time of day? Anything specific you're doing when it happens? Any particular machine you're connecting from?"
"Nope. I'm on, and then I'm not. Poof! Gone."
"That doesn't give me a lot to work with, y'know. C'mon, gimme something. A hint, a clue, anything."
"I've told you all I know. Sometimes I just get dropped. Can you fix it?"
I tell her I'll work on it. There's not much in the router logs, but occasionally our traffic really does drop away, indicating that something is going wrong-but only for a minute or two at a time, after which everything returns to normal. No errors, no pattern, just every so often-no traffic. It's strange. Then we get lucky:
Ring Ring goes the telephone attached to the DSL.
Thunk Die goes our IP connection.
You are kidding me, think I. And yet, it reproduces: if someone calls the DSL phone number-the one nobody uses and no one's supposed to know about-our connectivity dies. The telephone company's number-one service selling point, the major calamity they claim you'll never have to worry about, happens-in flashy, blinky detail.
And yet, we're only 900 feet from the substation. This shouldn't be happening. I check cables, reset everything, and even clean the connections to see if that helps. But, of course, it doesn't. So I call the telephone company. "You know how you guys promise you'll never have your connection interrupted by incoming phone calls? Guess what's happening? We can be DoSed by telemarketers."
Maybe It's the Copper ...
Maybe It's the Copper ...
A tech comes out the next day and finds that, inexplicably, we test as over 3,000 feet away from the substation, far enough away that a cranky squirrel could cut us off with a small compass magnet. Eventually, we discover that back when our neighborhood was wired, all the phone lines were bundled together and every line sent to every building on the block, the idea being to avoid ever needing to run new cable. That's fine if your entire world is analog voice, but from a DSL standpoint, every linear inch of those branches counts as distance from substation, dropping your signal strength.
Happily, the problem had a quick and easy fix. All the side branches of the line were disconnected, and a note was added saying, "DO NOT RECONNECT. DSL PORTION IN USE." Ta-da! A distance of only 900 feet, a much stronger signal, and most importantly, no carrier loss on rings.
The moral of the story: don't assume that a connection problem is esoteric or even caused by software. Sometimes it's just a matter of the copper. Always, always have the telephone company guys check the actual DSL signal strength upon install, even if they're sure they don't need to; you never know what else might be hooked up there, just waiting to confuse you later. And don't take their word for it on distance-to-substation. You have no idea where those wires might be going, and neither do they. Find out. They have the tools; they have the technology-make them use them. You'll be glad you did. Particularly once telemarketers find your DSL number.

R'ykandar Korra'ti, postmaster for a small co-op ISP, lives near Seattle with her partner Anna. Having previously shipped mail products at Microsoft, she is now looking at grad school in a field so esoteric it doesn’t really have a name. Potential faculty advisors can reach her a darako@murkworks.net.


 Windows Confidential: A &quot;Mixed&quot; Blessing
Windows Confidential
A "Mixed" Blessing
Raymond Chen

When you insert a CD or DVD , the shell "sniffs" the disk to determine what type of content resides on it. This determination then guides the shell in deciding which autoplay action it should perform. The precise details of how the sniffing is done are not documented because they are heuristics that can change in the future if a better algorithm is found.
Formally documenting the algorithm would make it contractual, thereby preventing the algorithm from being tweaked in subsequent releases. Officially, therefore, the details of the algorithm are left unspecified.
If you've never written documentation for an SDK, you may not have realized that documentation leads to contract. Once you go on record that something behaves a certain way, you can't change it. If you do, people who were relying on that behavior will say, "Hey, that's not what the documentation says. You're changing the rules after the game has started."
With that caveat out of the way, here's a quick, incredibly oversimplified description of how Windows® XP Service Pack 2 (SP2) categorizes the contents of data CDs and data DVDs that lack an autorun.inf file. (Future service packs and future versions of Windows may behave differently.) I say "incredibly oversimplified" because the actual algorithm is a 61-step decision table that takes into account all sorts of information like whether the foreground application responded to the "Query cancel autoplay" notification, whether a full-screen program is running, and even whether the computer is a laptop that was recently docked or undocked. But I'm going to look only at the content-sniffing step.
First, the shell checks whether the user specified "Take no action" as the action for all content types. If so, then there's no point sniffing. The decision is simply "Take no action."
Otherwise, the shell has something to do. It looks at each file on the disk-up to four directories deep-and puts them into one of the following categories based on their perceived type: image, music, movie.
Files that don't fit into one of the these categories are ignored. If only one category is represented among all the files that were checked (say, for instance, all the files on the disk are music files), then that establishes the type of disk. If more than one of the three categories is represented, then the disk is deemed mixed content.
This means that album art on your CD full of music files will cause the CD to be treated as mixed content by Windows XP SP2. This is one of those things that could probably stand some tweaking. But suppose this algorithm did get tweaked, and we decided that an occasional picture on a CD full of MP3s should not tip the balance to mixed content. Some company might have a CD with a lot of audio files and just a few pictures on it. The company does, indeed, rely on the CD being detected as mixed content. But when the algorithm changes, the CD gets miscategorized as music. Now that company is upset. But who is to blame for this problem? Can the company be blamed for relying on the details of the sniffing algorithm? Or is Windows to be blamed since it is responsible for changing the algorithm?
Lo and behold, in Windows Vista™, the algorithm has changed-albeit only slightly. In Windows Vista, several checks are made up front to short-circuit the algorithm for certain well-known disk layouts. For example, if a DCIM folder is present in the root of the disk, then it is assumed to consist of digital pictures. Now we'll wait to see if anybody notices.

Raymond Chen’s Web site, The Old New Thing, and his identically titled book (Addison-Wesley, 2007) deal with both Windows history and Win32 programming. Raymond wonders what the sun looks like.