 TechNet Magazine April 2007

TechNet Magazine April 2007

Windows Administration: Inside the Windows Vista Kernel: Part 3

In this issue, we wrap up our in-depth discussion about what’s new in the Windows Vista kernel. In this final installment, we look at changes and new features pertaining to reliability, recovery, and security.

Mark Russinovich Windows Administration: Disaster Recovery: Active Directory Users and Groups

Data recovery in Active Directory can be very complex, yet it’s essential that you have a recovery plan in order. We show you how Active Directory stores, deletes, restores, and replicates objects so you can be prepared the next time a user or group membership is accidentally deleted.

Gil Kirkpatrick Windows Administration: Why Windows XP Embedded Matters to You

Though you may not know it, Windows XP Embedded could be a great fit for your organization’s IT lineup. Find out how Windows XP Embedded can lower your administrative overhead, save you money, and improve security.

Don Jones Management: Plan Ahead with System Center Capacity Planner

Insufficient hardware leads to poor response times while too much hardware is a waste of budget and administration resources. Learn how you can use the System Center Capacity Planner to model your network and accurately estimate your infrastructure needs.

John Savill Management: Advanced Client Inventories with SMS

Out of the box, Microsoft Systems Management Server 2003 collects a lot of information, but it doesn’t collect nearly as much as you may need. Find out how the right combination of scripting, WMI, and SMS knowledge can help you expand SMS inventories to collect and report almost any morsel of information.

Wes Dobry Management: Deploying Custom Software Updates with SMS 2003 R2

Systems Management Server 2003 R2 lets you use managedupdate features to deploy custom updates. Explore two new tools—the Inventory Tool for Custom Updates and the Custom Updates Publishing Tool—and see how they can help you deploy your own updates as well as updates from thirdparty developers.

Steve Rachui From the Editor: We May Be Wrong…

Joshua Trupin Toolbox: New Products for IT Pros

Greg Steen SQL Q&A: Rebuilding Indexes, Disk Queue Length, and More

Edited by Nancy Michell Utility Spotlight: Autoruns

The vast number of apps that run automatically at system start up can be a source of endless headaches. But with Autoruns, you can investigate every app that runs automatically, letting you troubleshoot conflicts, track down malware, and free up system resources.

Lance Whitney The Cable Guy: Wireless Group Policy Settings for Windows Vista

Discover how you can use Group Policy to centrally configure and distribute wireless network settings to all the computers in your Active Directory network.

Joseph Davies Windows PowerShell: Filtering and Formatting Data

Windows PowerShell provides easy access to a wide range of data. In its raw state, however, this data isn’t ready for typical business purposes. Learn how to customize the data you gather by filtering, specifying properties, and applying formatting.

Don Jones Hey, Scripting Guy!: Naively Taking on Local Users and Groups

It seems everybody has been asking about it. And now the Scripting Guys (finally) show you how to use scripts to manage local users and groups.

The Microsoft Scripting Guys Security Watch: The Security Configuration Wizard

The Security Configuration Wizard provides an efficient way to secure thousands of servers spread across numerous geographic locations. Here's everything you need to know to start hardening your servers and reducing their attack surface based on the roles they perform.

John Morello The Desktop Files: When I’m x64

Take a look at an implementation of Windows XP and Windows Server 2003 on x64 systems, examining some of the deployment benefits and hurdles you can expect to run into. And get familiar with Windows Vista x64 support, migration, and deployment.

Wes Miller Inside Microsoft.com: Using Active Directory Federation Services

Microsoft provides an extranet for its business partners, and this extranet requires that each external user have a unique domain account. Find out how Microsoft is planning to use Active Directory Federation Services to make a better user experience while streamlining the management involved.

Jim Guthrie Field Notes: The Joy (and Pain) of Learning

When the joy of being an early adopter begins to fade remember that Knowledge makes technology easier to use and easier to support. As IT professionals, we need to stay out there experimenting with new products. You just might be surprised with what you find.

Mark D. Scott Windows Confidential: The Power of Bugs

Why would you want to turn on a bug? Some applications actually rely on a bug in the OS. When the bug is fixed, the app breaks.

Raymond Chen


 Windows Administration: Inside the Windows Vista Kernel: Part 3
This article is the last part of a three part series. Click here to read Part One. Click here to read Part Two.

Windows Administration Mark Russinovich

Inside the Windows Vista Kernel: Part 3
At a Glance:
  • Reliability
  • Recovery
  • Security

This series has so far covered Windows Vista kernel enhancements related to processes, I/O, memory management, system startup, shutdown, and power management. In this third and final
installment, I take a look at features and improvements in the areas of reliability, recovery, and security.
One feature I'm not covering in this series is User Account Control (UAC), which comprises several different technologies, including file system and registry virtualization for legacy applications, elevation consent for accessing administrative rights, and the Windows® Integrity Level mechanism for isolating processes running with administrative rights from less-privileged processes running in the same account. Look for my in-depth coverage of UAC internals in a future issue of TechNet Magazine.
Windows Vista™ improves the reliability of your system and your ability to diagnose system and application problems through a number of new features and enhancements. For example, the kernel Event Tracing for Windows (ETW) logger is always active, generating trace events for file, registry, interrupt, and other types of activity into a circular buffer. When a problem occurs, the new Windows Diagnostic Infrastructure (WDI) can capture a snapshot of the buffer and analyze it locally or upload it to Microsoft support for troubleshooting.
The new Windows Performance and Reliability Monitor helps users correlate errors, such as crashes and hangs, with changes that have been made to system configuration. The powerful System Repair Tool (SRT) replaces the Recovery Console for off-line recovery of unbootable systems.
There are three areas that rely on kernel-level changes to the system and so merit a closer look in this article: Kernel Transaction Manager (KTM), improved crash handling, and Previous Versions.

Kernel Transaction Manager
One of the more tedious aspects of software development is handling error conditions. This is especially true if, in the course of performing a high-level operation, an application has completed one or more subtasks that result in changes to the file system or registry. For example, an application's software updating service might make several registry updates, replace one of the application's executables, and then be denied access when it attempts to update a second executable. If the service doesn't want to leave the application in the resulting inconsistent state, it must track all the changes it makes and be prepared to undo them. Testing the error recovery code is difficult and consequently often skipped, so errors in the recovery code can negate the effort.
Applications written for Windows Vista can, with very little effort, gain automatic error recovery capabilities by using the new transactional support in NTFS and the registry with the Kernel Transaction Manager. When an application wants to make a number of related changes, it can either create a Distributed Transaction Coordinator (DTC) transaction and a KTM transaction handle, or create a KTM handle directly and associate the modifications of the files and registry keys with the transaction. If all the changes succeed, the application commits the transaction and the changes are applied, but at any time up to that point the application can roll back the transaction and the changes are then discarded.
As a further benefit, other applications don't see changes made in a transaction until the transaction commits, and applications that use the DTC in Windows Vista and the forthcoming Windows Server®, code-named "Longhorn," can coordinate their transactions with SQL Server™, Microsoft® Message Queue Server (MSMQ), and other databases. An application updating service that uses KTM transactions will therefore never leave the application in an inconsistent state. This is why both Windows Update and System Restore use transactions.
As the heart of transaction support, KTM allows transactional resource managers such as NTFS and the registry to coordinate their updates for a specific set of changes made by an application. In Windows Vista, NTFS uses an extension to support transactions called TxF. The registry uses a similar extension called TxR. These kernel-mode resource managers work with the KTM to coordinate the transaction state, just as user-mode resource managers use DTC to coordinate transaction state across multiple user-mode resource managers. Third parties can also use KTM to implement their own resource managers.
TxF and TxR both define a new set of file system and registry APIs that are similar to existing ones, except that they include a transaction parameter. If an application wants to create a file within a transaction, it first uses KTM to create the transaction, then passes the resulting transaction handle to the new-file creation API.
TxF and TxR both rely on the high-speed file system logging functionality of the Common Log File System or CLFS (%SystemRoot%\System32\Clfs.sys) that was introduced in Windows Server 2003 R2. TxR and TxF use CLFS to durably store transactional state changes before they commit a transaction. This allows them to provide transactional recovery and assurances even if power is lost. In addition to the CLFS log, TxR creates a set of related log files to track transaction changes to the system's registry file in %Systemroot%\System32\Config\Txr, as seen in Figure 1, as well as separate sets of log files for each user registry hive. TxF stores transactional data for each volume in a hidden directory on the volume that's named \$Extend\$RmMetadata.
Figure 1 System registry hive TxR logging files
Figure 1 System registry hive TxR logging files

Enhanced Crash Support
When Windows encounters an unrecoverable kernel-mode error—whether due to a buggy device driver, faulty hardware, or the operating system—it tries to prevent corruption of on-disk data by halting the system after displaying the notorious "blue screen of death" and, if configured to do so, writing the contents of some or all of physical memory to a crash dump file. Dump files are useful because when you reboot from a crash, the Microsoft Online Crash Analysis (OCA) service offers to analyze them to look for the root cause. If you like, you can also analyze them yourself using the Microsoft Debugging Tools for Windows).
In previous versions of Windows, however, support for crash dump files wasn't enabled until the Session Manager (%Systemroot%\System32\Smss.exe) process initialized paging files. This meant that any critical errors before that point result in a blue screen, but no dump file. Since the bulk of device driver initialization occurs before Smss.exe starts, early crashes would never result in crash dumps, thus making diagnosis of the cause extremely difficult.
Windows Vista reduces the window of time where no dump file is generated by initializing dump file support after all the boot-start device drivers are initialized but before loading system-start drivers. Because of this change, if you do experience a crash during the early part of the boot process, the system can capture a crash dump, allowing OCA to help you resolve the problem. Further, Windows Vista saves data to a dump file in 64KB blocks, whereas previous versions of Windows wrote them using 4KB blocks. This change results in large dump files being written up to 10 times faster.
Application crash handling is also improved in Windows Vista. On previous versions of Windows, when an application crashed it executed an unhandled exception handler. The handler launched the Microsoft Application Error Reporting (AER) process (%Systemroot%\System32\Dwwin.exe) to display a dialog indicating that the program has crashed and asking whether you wanted to send an error report to Microsoft. However, if the stack of the process's main thread was corrupted during the crash, the unhandled exception handler crashed when it executed, resulting in termination of the process by the kernel, the instant disappearance of the program's windows, and no error reporting dialog.
Windows Vista moves error handling out of the context of the crashing process into to a new service, Windows Error Reporting (WER). This service is implemented by a DLL (%Systemroot%\System32\Wersvc.dll) inside a Service Hosting process. When an application crashes, it still executes an unhandled exception handler, but that handler sends a message to the WER service and the service launches the WER Fault Reporting process (%Systemroot%\System32\Werfault.exe) to display the error reporting dialog. If the stack is corrupted and the unhandled exception handler crashes, the handler executes again and crashes again, eventually consuming all the thread's stack (scratch memory area), at which point the kernel steps in and sends the crash notification message to the service.
You can see the contrast in these two approaches in Figures 2 and 3, which show the process relationship of Accvio.exe, a test program that crashes, and the error reporting processes highlighted in green, on Windows XP and Windows Vista. The new Windows Vista error handling architecture means that programs will no longer silently terminate without offering the chance for Microsoft to obtain an error report and help software developers improve their applications.
Figure 2a Application error handling in Windows XP
Figure 2a Application error handling in Windows XP
Figure 2b
Figure 3a Application error handling in Windows Vista
Figure 3a Application error handling in Windows Vista
Figure 3b

Volume Shadow Copy
Windows XP introduced a technology called Volume Shadow Copy to make point-in-time snapshots of disk volumes. Backup applications can use these snapshots to make consistent backup images, but the snapshots are otherwise hidden from view and kept only for the duration of the backup process.
The snapshots are not actually full copies of volumes. Rather, they are views of a volume from an earlier point that comprise the live volume data overlaid with copies of volume sectors that have changed since the snapshot was taken. The Volume Snapshot Provider driver (%Systemroot\%System32\Drivers\Volsnap.sys) monitors operations aimed at volumes and makes backup copies of sectors before allowing them to change, storing the original data in a file associated with the snapshot in the System Volume Information directory of the volume.
Windows Server 2003 exposed snapshot management to administrators on the server and to users on client systems with its Shadow Copies for Shared Folders. This feature enabled persistent snapshots that users could access via a Previous Versions tab on the Explorer properties dialog boxes for their folders and files located on the server's file shares.
The Windows Vista Previous Versions feature brings this support to all client systems, automatically creating volume snapshots, typically once per day, that you can access through Explorer properties dialogs using the same interface used by Shadow Copies for Shared Folders. This enables you to view, restore, or copy old versions of files and directories that you might have accidentally modified or deleted. While technically not new technology, the Windows Vista Previous Versions implementation of Volume Shadow Copy optimizes that of Windows Server 2003 for use in client desktop environments.
Windows Vista also takes advantage of volume snapshots to unify user and system data protection mechanisms and avoid saving redundant backup data. When an application installation or configuration change causes incorrect or undesirable behaviors, you can use System Restore, a feature introduced into the Windows NT® line of operating systems in Windows XP, to restore system files and data to their state as it existed when a restore point was created.
In Windows XP, System Restore uses a file system filter driver—a type of a driver that can see changes at the file level—to make backup copies of system files at the time they change. On Windows Vista, System Restore uses volume snapshots. When you use the System Restore user interface in Windows Vista to go back to a restore point, you're actually copying earlier versions of modified system files from the snapshot associated with the restore point to the live volume.

BitLocker
Windows Vista is the most secure version of Windows yet. In addition to the inclusion of the Windows Defender antispyware engine, Windows Vista introduces numerous security and defense-in-depth features, including BitLocker™ full-volume encryption, code signing for kernel-mode code, protected processes, Address Space Load Randomization, and improvements to Windows service security and User Account Control.
An operating system can only enforce its security policies while it's active, so you have to take additional measures to protect data when the physical security of a system can be compromised and the data accessed from outside the operating system. Hardware-based mechanisms such as BIOS passwords and encryption are two technologies commonly used to prevent unauthorized access, especially on laptops, which are most likely to be lost or stolen.
Windows 2000 introduced the Encrypting File System (EFS) and, in its Windows Vista incarnation, EFS includes a number of improvements over previous implementations, including performance enhancements, support for encrypting the paging file, and storage of user EFS keys on smart cards. However, you can't use EFS to protect access to sensitive areas of the system, such as the registry hive files. For example, if Group Policy allows you to log onto your laptop even when you're not connected to a domain, then your domain credential verifiers are cached in the registry, so an attacker could use tools to obtain your domain account password hash and use that to try to obtain your password with a password cracker. The password would gain them access to your account and EFS files (assuming you didn't store the EFS key on a smart card).
To make it easy to encrypt the entire boot volume (the volume with the Windows directory), including all its system files and data, Windows Vista introduces a full-volume encryption feature called Windows BitLocker Drive Encryption. Unlike EFS, which is implemented by the NTFS file system driver and operates at the file level, BitLocker encrypts at the volume level using the Full Volume Encryption (FVE) driver (%Systemroot%\System32\Drivers\Fvevol.sys) as diagrammed in Figure 4.
Figure 4 BitLocker FVE filter driver
Figure 4 BitLocker FVE filter driver
FVE is a filter driver so it automatically sees all the I/O requests that NTFS sends to the volume, encrypting blocks as they're written and decrypting them as they're read using the Full Volume Encryption Key (FVEK) assigned to the volume when it's initially configured to use BitLocker. By default, volumes are encrypted using a 128-bit AES key and a 128-bit diffuser key. Because the encryption and decryption happen beneath NTFS in the I/O system, the volume appears to NTFS as if it's unencrypted and NTFS does not even need to be aware that BitLocker is enabled. If you attempt to read data from the volume from outside of Windows, however, it appears to be random data.
The FVEK is encrypted with a Volume Master Key (VMK) and stored in a special metadata region of the volume. When you configure BitLocker, you have a number of options for how the VMK will be protected, depending on the system's hardware capabilities. If the system has a Trusted Platform Module (TPM) that conforms to v1.2 of the TPM specification and has associated BIOS support, then you can either encrypt the VMK with the TPM, have the system encrypt the VMK using a key stored in the TPM and one stored on a USB flash device, or encrypt the key using a TPM-stored key and a PIN you enter when the system boots. For systems that don't have a TPM, BitLocker offers the option of encrypting the VMK using a key stored on an external USB flash device. In any case you'll need an unencrypted 1.5GB NTFS system volume, the volume where the Boot Manager and Boot Configuration Database (BCD) are stored.
The advantage of using a TPM is that BitLocker uses TPM features to ensure that it will not decrypt the VMK and unlock the boot volume if the BIOS or the system boot files have changed since BitLocker was enabled. When you encrypt the system volume for the first time, and each time you perform updates to any of the components mentioned, BitLocker calculates SHA-1 hashes of these components and stores each hash, called a measurement, in different Platform Configuration Registers (PCR) of the TPM with the help of the TPM device driver (%Systemroot%\System32\Drivers\Tpm.sys). It then uses the TPM to seal the VMK, an operation that uses a private key stored in the TPM to encrypt the VMK and the values stored in the PCRs along with other data BitLocker passes to the TPM. BitLocker then stores the sealed VMK and encrypted FVEK in the volume's metadata region.
When the system boots, it measures its own hashing and PCR loading code and writes the hash to the first PCR of the TPM. It then hashes the BIOS and stores that measurement in the appropriate PCR. The BIOS in turn hashes the next component in the boot sequence, the Master Boot Record (MBR) of the boot volume, and this process continues until the operating system loader is measured. Each subsequent piece of code that runs is responsible for measuring the code that it loads and for storing the measurement into the appropriate register in the TPM. Finally, when the user selects which operating system to boot, the Boot Manager (Bootmgr) reads the encrypted VMK from the volume and asks the TPM to unseal it. Only if all the measurements are the same as when the VMK was sealed, including the optional PIN, will the TPM successfully decrypt the VMK.
You can think of this scheme as a verification chain, where each component in the boot sequence describes the next component to the TPM. Only if all the descriptions match the original ones given to it will the TPM divulge its secret. BitLocker therefore protects the encrypted data even when the disk is removed and placed in another system, the system is booted using a different operating system, or the unencrypted files on the boot volume are compromised.

Code Integrity Verification
Malware that is implemented as a kernel-mode device driver, including rootkits, runs at the same privilege level as the kernel and so is the most difficult to identify and remove. Such malware can modify the behavior of the kernel and other drivers so as to become virtually invisible. The Windows Vista code integrity for kernel-mode code feature, also known as kernel-mode code signing (KMCS), only allows device drivers to load if they are published and digitally signed by developers who have been vetted by one of a handful of certificate authorities (CAs). KMCS is enforced by default on Windows Vista for 64-bit systems.
Because certificate authorities charge a fee for their services and perform basic background checks, such as verifying a business identity, it's harder to produce anonymous kernel-mode malware that runs on 64-bit Windows Vista. Further, malware that does manage to slip through the verification process can potentially leave clues that lead back to the author when the malware is discovered on a compromised system. KMCS also has secondary uses, like providing contact information for the Windows Online Crash Analysis team when a driver is suspected of having a bug that's crashing customer systems, and unlocking high-definition multimedia content, which I'll describe shortly.
KMCS uses public-key cryptography technologies that have been employed for over a decade by Windows and requires that kernel-mode code include a digital signature generated by one of the trusted certificate authorities. If a publisher submits a driver to the Microsoft Windows Hardware Quality Laboratory (WHQL) and the driver passes reliability testing, then Microsoft serves as the certificate authority that signs the code. Most publishers will obtain signatures via WHQL, but when a driver has no WHQL test program, the publisher doesn't want to submit to WHQL testing, or the driver is a boot-start driver that loads early in system startup, the publishers must sign the code themselves. To do so, they must first obtain a code-signing certificate from one of the certificate authorities that Microsoft has identified as trusted for kernel-mode code signing. The author then digitally hashes the code, signs the hash by encrypting it with a private key, and includes the certificate and encrypted hash with the code.
When a driver tries to load, Windows decrypts the hash included with the code using the public key stored in the certificate, then verifies that the hash matches the one included with the code. The authenticity of the certificate is checked in the same way, but using the certificate authority's public key, which is included with Windows.
Windows also checks the associated certificate chains up to one of the root authorities embedded in the Windows boot loader and operating system kernel. Attempts to load an unsigned 64-bit driver should never occur on a production system, so unlike the Plug and Play Manager, which displays a warning dialog when it's directed to load a driver that doesn't have a signature confirming that it's been through WQHL testing, 64-bit Windows Vista silently writes an event to the Code Integrity application event log, like the one shown in Figure 5, anytime it blocks the loading of an unsigned driver. 32-bit Windows Vista also checks driver signatures, but allows unsigned drivers to load. Blocking them would break upgraded Windows XP systems that require drivers that were loaded on Windows XP, and also allows support for hardware for which only Windows XP drivers exist. However, 32-bit Windows Vista also writes events to the Code Integrity event log when it loads an unsigned driver.
Figure 5 Unsigned driver load attempt events
Figure 5 Unsigned driver load attempt events
Because code signing is commonly used to label code as a rigorously tested official release, publishers typically don't want to sign test code. Windows Vista therefore includes a test-signing mode you can enable and disable with the Bcdedit tool (described in my March 2007 TechNet Magazine article), where it will load kernel-mode drivers digitally signed with a test certificate generated by an in-house certificate authority. This mode is designed for use by programmers while they develop their code. When Windows is in this mode, it displays markers on the desktop like the one in Figure 6.
Figure 6 Windows Vista test-signing mode
Figure 6 Windows Vista test-signing mode

Protected Processes
Next-generation multimedia content, like HD-DVD, BluRay, and other formats licensed under the Advanced Access Content System (AACS), will become more common over the next few years. Windows Vista includes a number of technologies, collectively called Protected Media Path (PMP), that are required by the AACS standard for such content to be played. PMP includes Protected User-Mode Audio (PUMA) and Protected Video Path (PVP) that together provide mechanisms for audio and video drivers, as well as media player applications, to prevent unauthorized software or hardware from capturing content in high-definition form.
PUMA and PVP define interfaces and support specific to audio and video players, device drivers, and hardware, but PMP also relies on a general kernel mechanism introduced in Windows Vista called a protected process. Protected processes are based on the standard Windows process construct that encapsulates a running executable image, its DLLs, security context (the account under which the process is running and its security privileges), and the threads that execute code within the process, but prevent certain types of access.
Standard processes implement an access control model that allows full access to the owner of the process and administrative accounts with the Debug Programs privilege. Full access allows a user to view and modify the address space of the process, including the code and data mapped into the process. Users can also inject threads into the process. These types of access are not consistent with the requirements of PMP because they would allow unauthorized code to gain access to high-definition content and Digital Rights Management (DRM) keys stored in a process that is playing the content.
Protected processes restrict access to a limited set of informational and process management interfaces that include querying the process's image name and terminating or suspending the process. But the kernel makes diagnostic information for protected processes available through general process query functions that return data regarding all the processes on a system and so don't require direct access to the process. Accesses that could compromise media are allowed only by other protected processes.
Further, to prevent compromise from within, all executable code loaded into a protected process, including its executable image and DLLs, must be either signed by Microsoft (WHQL) with a Protected Environment (PE) flag, or if it's an audio codec, signed by the developer with a DRM-signing certificate obtained from Microsoft. Because kernel-mode code can gain full access to any process, including protected processes, and 32-bit Windows allows unsigned kernel-mode code to load, the kernel provides an API for protected processes to query the "cleanliness" of the kernel-mode environment and use the result to unlock premium content only if no unsigned code is loaded.
Identifying a Protected Process
There are no APIs that specifically identify protected processes, but you can indirectly identify them based on the limited information available for them and the inability to debug them even from an administrative account. The Audio Device Graph Isolation process (%Systemroot%\System32\Audiodg.exe) is used to play Content Scramble System (CSS)-encoded DVDs and is identifiable as a protected process in the Task Manager pane by the fact that Task Manager can’t obtain its command line, virtualization, and Data Execution Prevent status even when it is run with administrative rights.
Task Manager viewing the audiodg protected process
Task Manager viewing the audiodg protected process

Address Space Load Randomization
Despite measures like Data Execution Prevention and enhanced compiler error checking, malware authors continue to find buffer overflow vulnerabilities that allow them to infect network-facing processes like Internet Explorer®, Windows services, and third-party applications to gain a foothold on a system. Once they have managed to infect a process, however, they must use Windows APIs to accomplish their ultimate goal of reading user data or establishing a permanent presence by modifying user or system configuration settings.
Connecting an application with API entry points exported by DLLs is something usually handled by the operating system loader, but these types of malware infection don't get the benefit of the loader's services. This hasn't posed a problem for malware on previous versions of Windows because for any given Windows release, system executable images and DLLs always load at the same location, allowing malware to assume that APIs reside at fixed addresses.
The Windows Vista Address Space Load Randomization (ASLR) feature makes it impossible for malware to know where APIs are located by loading system DLLs and executables at a different location every time the system boots. Early in the boot process, the Memory Manager picks a random DLL image-load bias from one of 256 64KB-aligned addresses in the 16MB region at the top of the user-mode address space. As DLLs that have the new dynamic-relocation flag in their image header load into a process, the Memory Manager packs them into memory starting at the image-load bias address and working its way down.
Executables that have the flag set get a similar treatment, loading at a random 64KB-aligned point within 16MB of the base load address stored in their image header. Further, if a given DLL or executable loads again after being unloaded by all the processes using it, the Memory Manager reselects a random location at which to load it. Figure 7 shows an example address-space layout for a 32-bit Windows Vista system, including the areas from which ASLR picks the image-load bias and executable load address.
Figure 7 ASLR's effect on executable and DLL load addresses
Figure 7 ASLR's effect on executable and DLL load addresses
Only images that have the dynamic-relocation flag, which includes all Windows Vista DLLs and executables, get relocated because moving legacy images could break internal assumptions that developers have made about where their images load. Visual Studio® 2005 SP1 adds support for setting the flag so that third-party developers can take full advantage of ASLR.
Randomizing DLL load addresses to one of 256 locations doesn't make it impossible for malware to guess the correct location of an API, but it severely hampers the speed at which a network worm can propagate and it prevents malware that only gets one chance at infecting system from working reliably. In addition, ASLR's relocation strategy has the secondary benefit that address spaces are more tightly packed than on previous versions of Windows, creating larger regions of free memory for contiguous memory allocations, reducing the number of page tables the Memory Manager allocates to keep track of address-space layout, and minimizing Translation Lookaside Buffer (TLB) misses.

Service Security Improvements
Windows services make ideal malware targets. Many offer network access to their functionality, possibly exposing remotely exploitable access to a system, and most run with more privilege than standard user accounts, offering the chance to elevate privileges on a local system if they can be compromised by malware. For this reason, Windows started evolving with changes made in Windows XP SP2 that reduced the privileges and access assigned to services to just those needed for their roles. For example, Windows XP SP2 introduced the Local Service and Network Service accounts that include only a subset of the privileges available to the account in which services always previously ran, Local System. This minimizes the access an attacker gains when exploiting a service.
Seeing ASLR in Action
You can easily see the effects of ASLR by comparing the DLL load addresses for a process in two different boot sessions using a tool like Process Explorer from Sysinternals. In these two screenshots, taken from two different sessions, Ntdll.dll loaded into Explorer first at address 0x77A30000 and then at address 0x77750000.
Different base addresses for ntdll.dll
Different base addresses for ntdll.dll
Different base addresses for ntdll.dll
Different base addresses for ntdll.dll

In my previous article, I described how services run isolated from user accounts in their own session, but Windows Vista also expands its use of the principle of least privilege by further reducing the privileges and access to the files, registry keys, and firewall ports it assigns to most services. Windows Vista defines a new group account, called a service Security Identifier (SID), unique to each service. The service can set permissions on its resources so that only its service SID has access, preventing other services running in the same user account from having access if a service becomes compromised. You can see a service's SID by using the sc showsid command followed by the service name, as seen in Figure 8.
Figure 8 Viewing a service SID
Figure 8 Viewing a service SID
Service SIDs protect access to resources owned by a particular service, but by default services still have access to all the objects that the user account in which they run can access. For example, a service running in the Local Service account might not be able to access resources created by another service running as Local Service in a different process that has protected its objects with permissions referencing a service SID, however, it can still read and write any objects to which Local Service (and any groups to which Local Service belongs, like the Service group) has permissions.
Windows Vista therefore introduces a new restricted service type called a write-restricted service that permits a service write access only to objects accessible to its service SID, the Everyone group, and the SID assigned to the logon session. To accomplish this, it uses restricted SIDs, a SID type introduced back in Windows 2000. When the process opening an object is a write-restricted service, the access-check algorithm changes so that a SID that has not been assigned to a process in both restricted and unrestricted forms cannot be used to grant the process write access to an object. You can see if a service is restricted with the following command:
sc qsidtype [service]
Another change makes it easy for a service to prevent other services running in the same account from having access to the objects it creates. In previous versions of Windows, the creator of an object is also the object's owner, and owners have the ability to read and change the permissions of their objects, allowing them full access to their own objects. Windows Vista introduces the new Owner Rights SID, which, if present in an object's permissions, can limit the accesses an owner has to its own object, even removing the right to set and query the permissions.
A further enhancement to the service security model in Windows Vista enables a service developer to specify exactly what security privileges the service needs to operate when the service registers on a system. For example, if the service needs to generate audit events it could list the Audit privilege.
When the Service Control Manager starts a process that hosts one or more Windows services, it creates a security token (the kernel object that lists a process user account, group memberships, and security privileges) for the process that includes only the privileges required by the services in the process. If a service specifies a privilege that is not available to the account in which it runs, then the service fails to start. When none of the services running in a Local Service account process need the Debug Programs privilege, for example, the Service Control Manager strips that privilege from the process's security token. Thus, if the service process is compromised, malicious code cannot take advantage of privileges that were not explicitly requested by the services running in the process. The sc qprivs command reports the privileges that a service has requested.

Conclusion
This concludes my three-part look at Windows Vista kernel changes. There are features and improvements I didn't cover or mention, like a new worker thread pool for application developers, new synchronization mechanisms such as shared reader/writer locks, service thread tagging, support for online NTFS disk checking and volume resizing, and a new kernel IPC mechanism called Advanced Local Procedure Call (ALPC). Look for more information on these and other features in the next edition of Windows Internals, scheduled for publication by the end of 2007.
Viewing Write-Restricted Service
Only one service-hosting process on Windows Vista hosts restricted services and you can identify it with a process-viewing tool like Process Explorer as the one that has the command line:
svchost -k LocalServiceNoNetwork
Services configured to run in this process include Base Filtering Engine, Diagnostic Policy Service, Windows Firewall, Performance Logs and Alerts, and Windows Media® Center Service Starter.
This screen shows the textual form of the Base Filtering Engine’s service SID, NT SERVICE\BFE, listed once with the Restricted flag and again without it, so the process has access to resources accessible to that account. It doesn’t necessarily have access to other objects normally accessible to the Local Service account, however. For instance, because the NT AUTHORITY\SERVICE account doesn’t appear in the process token with the restricted flag, the process can’t modify objects that grant write access only to that account but not to other accounts in the token that have the restricted flag.
The services running in this process also limit their privileges, because the privileges listed at the bottom of the properties dialog are a subset of those available to the Local Service account.
SID flags on a service
SID flags on a service

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


 Windows Administration: Disaster Recovery: Active Directory Users and Groups
Windows Administration Gil Kirkpatrick

Disaster Recovery: Active Directory Users and Groups
At a Glance:
  • Mechanics of replication and object linking
  • Using NTDSUTIL to back up and restore
  • Authoritative and non-authoritative restores

Active Directory is one of the most critical services in a Windows network. To avoid downtime and loss of productivity, it’s essential that you have effective disaster recovery plans in place for problems related to Active Directory. This point may sound obvious, but it’s
amazing how many administrators don’t have a plan for one of the most common Active Directory® failure scenarios: accidental deletion of data.
Accidental deletion of objects is one of the most common root causes of service failure. When I do seminars and conferences, I often ask who has had an Active Directory failure due to accidental deletion of data. And every time, nearly everyone raises his hand.
To understand why data recovery is so complex, you first need to understand the following: how Active Directory stores and replicates objects, how it deletes objects, and the mechanics of authoritative and non-authoritative restores.

Storing Objects
Active Directory is a specialized object database that implements the X.500/LDAP data model. The data store (called the Directory Information Tree or DIT) is based on the Extensible Storage Engine (ESE), an indexed sequential access method (ISAM) database engine. Conceptually, Active Directory stores the DIT in two tables: the data table (which contains the actual Active Directory objects and attributes), and the link table (which contains the relationships between objects).
Each Active Directory object is stored in a separate row in the data table, with one column per attribute. The data table contains all the entries for all of the replicas stored on the domain controller (DC). On a normal DC, the data table contains entries from the domain NC (naming context), the configuration NC, and schema NC. On a global catalog, the data table contains entries for each object in the forest.
Active Directory uses the distinguished name tag (DNT)—a 32-bit integer—to uniquely identify each row in the data table. The DNT, used to refer to objects internally, is much smaller than other identifiers like the distinguished name (DN) and the objectGUID (a 16-byte binary structure). But unlike the objectGUID, the DNT is a local identifier, and is different on each DC.

How Active Directory Links Objects
Active Directory manages two kinds of relationships between objects in the DIT: the parent-child relationship (also referred to as the container relationship) and the reference relationship (also referred to as the link relationship). To implement the parent-child relationship, Active Directory stores an additional column in the data table called the parent distinguished name tag, or PDNT. This column always contains the DNT of the object’s parent.
Each attribute in Active Directory is defined by an attributeSchema object in the Active Directory Schema container. Certain attributes in Active Directory are defined as link attributes, as determined by an even, non-zero value in the linkID attribute of the attributeSchema object. Link attributes establish a relationship between objects in the directory and can be single-valued or multi-valued. The member attribute of a group object is an example of a multi-valued link attribute—it establishes a link between the group object and its member objects.
Even though it appears that the member attribute of a group contains the DNs of the members (as displayed by the Active Directory Users and Computers snap-in, for instance), this is not how Active Directory stores them. When you add the DN of a member object to a group’s member attribute, Active Directory stores the object’s DNT, not its DN. Since the DNT doesn’t change, even when an object is renamed, you can rename a user object and Active Directory won’t have to sort through all the groups in the system to update the DN in each of the member attributes. This is how Active Directory maintains referential integrity within the DIT. Figure 1 shows a representation, though greatly simplified, of how the data table and link table relate to each other. These tables show that the three user objects—Molly Clark, Alexander Tumanov, and Makoto Yamagishi—are all members of the Senior Engineers group.
Figure 1 How data and link tables relate (Close Figure 1)

Data Table |  |  |
DNT | PDNT | Object Class | Cn
14529 | 14401 | organizationalUnit | Engineers
14530 | 14529 | Group | Senior Engineers
14531 | 14529 | User | Molly Clark
14532 | 14529 | User | Alexander Tumanov
14533 | 14529 | User | Makoto Yamagishi
Link Table |  |  |
Attribute | DNT | Forward Link |
Member | 14530 | 14531 |
Member | 14530 | 14532 |
Member | 14530 | 14533 |
These links are called forward links. Similarly, Active Directory also provides backward link attributes. These provide a reference from the linked-to object back to the object that refers to it, meaning the object with the forward link. The memberOf attribute for users and groups is an example of a back link attribute. The attributeSchema object that describes a back link attribute has a linkID value that is one greater than the even-numbered linkID value of the corresponding forward link attribute. For instance, the member attribute in the Windows Server® 2003 R2 schema has a linkID value of 2; the memberOf attribute that serves as the back link has a linkID value of 3. For more information Figure 2 provides a list of the linked attributes defined by default in the Windows Server 2003 R2 schema.
Figure 2 Link attributes in the Windows Server 2003 R2 schema (Close Figure 2)

Forward Link Attribute | linkID | Back Link Attribute | Linked
member | 2 | memberOf | 3
manager | 42 | directReports | 43
owner | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
Back link attributes are always multi-valued and they’re maintained automatically by Active Directory. In fact, you can’t directly modify a back link attribute. Even though it appears that you can modify the memberOf attribute of a user or group through the Active Directory Users and Computers MMC snap-in, the snap-in is actually modifying the member attribute of the corresponding group, and Active Directory updates the memberOf attribute behind the scenes. This is why you don’t need permissions on the user object to add the user to a group; you are really only modifying the member attribute of the group object. Because each DC manages its back link attributes locally, changes to back links are never replicated. Only the change to the forward link attribute, such as the member attribute of a group, is replicated.
On a normal DC, the data table contains entries for domain objects as well as objects from the Configuration and Schema containers. But some group types can contain references to objects that reside in another domain. How does Active Directory store a DNT for an object that is not in its data table? The answer lies with the Infrastructure Master FSMO (Flexible Single Master Operations) role owner and something called a phantom object.

Phantom Objects
When you add a member from one domain to a group in another domain, Active Directory automatically creates a special object in the data table called a phantom, which contains the objectGUID, objectSid, and DN of the new member. This provides a DNT that can be stored in the member attribute of the group. If a domain controller is a global catalog, it will not need to create a phantom because it already has an entry in its data table for each object in the forest.
The DC that holds the Infrastructure FSMO role periodically checks the entries in its data table against a global catalog and when it finds that an object has been moved, renamed, or deleted, it updates the phantoms in the data table and replicates the change to the other DCs in the domain. And by virtue of a reference count, the infrastructure master can also remove phantoms that are no longer referred to by any forward link attribute in the domain.
Phantoms allow DCs to manage references to objects in other domains within the forest, but forward link attributes can also refer to objects that are outside the forest—for instance, in a trusted domain. In this case, Active Directory creates an object called a foreign security principal (FSP) in the CN=ForeignSecurityPrincipals container in the domain NC. The FSP contains the foreign object’s Security Identifier (SID) and other attributes that identify the object in the foreign domain, but there is no process to ensure that the FSP is kept up to date. For the purposes of data recovery, we treat FSPs as we would any other Active Directory object.

Deleting Objects
Here, I focus primarily on restoring users and their group memberships. However, the same principles apply to recovering other linked attributes.
When Active Directory deletes an object, it doesn’t physically delete the object from the DIT. Instead, it marks the object as deleted by setting its isDeleted attribute to true, which renders the object invisible to normal directory operations. Active Directory removes all attributes that are not designated to be saved, as defined by the schema, and changes the relative distinguished name (RDN) of the object to <old RDN>\0aDEL:<objectGUID>. It then moves the object to the CN=Deleted Objects container for the NC. (There are some classes of objects in the Configuration NC that Active Directory does not move to the Deleted Objects container.) Active Directory removes any forward links to other objects that the deleted object holds—which reduces their reference count in the link table. If there are other objects that contain forward links to the now deleted object, Active Directory removes those links as well.
The resulting object is a called a tombstone. Active Directory replicates this tombstone to other DCs, where the same changes are made. Note that Active Directory does not replicate the changes made to forward links that refer to the deleted object. Each DC makes the equivalent change locally, so there is no need to replicate it. This has consequences for recovering group memberships, as I will discuss later in the article.
Active Directory maintains tombstoned objects in the DIT as determined by the tombstoneLifetime attribute of the CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> object. The garbage collection process on each DC removes tombstones that are older than the configured tombstone lifetime. By default, the tombstone lifetime is 60 days for Windows® 2000, Windows Server 2003, and Windows Server 2003 R2. It is 180 days for Windows Server 2003 SP1.
The tombstone lifetime has a significant bearing on the restore process. You cannot restore from a backup that is older than the tombstone lifetime. Because objects that have been deleted and then garbage collected from the domain no longer have tombstones, the deletion operation will never re-replicate to the restored DC. The deleted objects will then remain on the restored DC as lingering objects and the restored DC will never properly converge with the other DCs in the domain.

Replicating Objects
Whenever a domain controller performs an update operation of any sort—for instance adding an object or modifying an attribute—the DC assigns a unique 64-bit number to the update operation, called an update sequence number (USN). Active Directory tags the objects and attributes that are updated with the USN to help determine whether they need to be replicated.
Active Directory replicates objects on an attribute-by-attribute basis. That is, if you modify an attribute of an object, Active Directory will replicate just that attribute, not the entire object. To do this, Active Directory keeps track of the changes it makes to each attribute with replication metadata. The replication metadata for an attribute includes:
  • The local USN, which identifies the change operation on the local DC.
  • The invocationID of the DC that originated the change (specifically, the invocationID attribute of the DC’s corresponding nTDSSettings object), which identifies a particular generation of the DIT on a domain controller.
  • The USN of the original operation as it exists on the originating DC.
  • A time stamp that contains the DC system time for when the originating change was made.
  • A 32-bit sequential version number that is incremented each time the value is changed.
When a destination DC requests changes from its source DC partner, it sends the USN of the last successfully replicated change to the source DC along with an up-to-dateness vector that includes the largest originating USN the destination DC has seen from each DC that has a replica of the NC being replicated. The source DC uses this information to send only those updates that the destination DC has not already seen.
As the destination DC processes the incoming attribute updates, it checks the version number of each attribute. If the version number of an incoming attribute is greater than the version the DC already has for that attribute, the DC stores the incoming value. If the incoming version number is equal to the version the DC already has, the DC compares the timestamps and uses the attribute with the latest timestamp. If the timestamps are the same, the destination DC chooses the value with the largest invocationID. This guarantees that every DC will eventually settle on the same value for every replicated attribute.

Linked Value Replication
In Windows 2000, Active Directory replicated multi-valued attributes in the same fashion as single-valued attributes. This caused problems for large, dynamic group objects whose multi-valued member attribute could change frequently on different DCs. If an administrator added a user to a group on one DC and a different administrator added a different user to the group on another DC within the replication latency window, Active Directory would choose the later addition and completely lose the earlier addition. Microsoft addressed this problem in Windows Server 2003 with a process called linked value replication (LVR).
With Windows Server 2003 forest functional level or interim forest functional level, Active Directory replicates the individual values of multi-valued forward link attributes separately, with each value having its own replication metadata. This effectively solves the problem found in Windows 2000 where nearly simultaneous updates of group membership on different DCs could cause data to be lost.
There is one point to be aware of, however. Raising the forest functional level does not automatically fix up existing multi-valued link attributes with the new replication metadata. Only values that are added after raising the forest functional level will have the new metadata. This will have a significant effect on recovering group memberships, as you’ll see in a moment.

Backing Up
Windows includes the very basic NTBACKUP utility, which can be used to perform a system state backup of a DC. The system state of a domain controller includes its registry, SYSVOL, Active Directory DIT files, and critical system files. Most third-party backup utilities also have the ability to backup and restore the system state of a DC.
To perform a system state backup to a disk file, use the following command:
NTBACKUP backup systemstate /F “<filename>”
Here, <filename> is the name of the backup file to be created and should use the .bkf extension.

Performing a Non-Authoritative Restore
Restoring deleted Active Directory objects from backup is a two-step process. First, you reboot the DC into Directory Services Restore mode (DSRM) and then you restore the entire Active Directory DIT from the system state backup using the Windows NTBACKUP utility or an equivalent third-party product. This process will overwrite the entire DIT.
There are two ways to boot a DC into DSRM. If you have access to the system console of the DC, shut down and restart the DC and press F8 when prompted to bring up the Windows boot menu. Select Directory Services Restore from the menu and enter the DSRM password.
If you are managing the server remotely, you won’t be able to access the Windows boot menu. Instead, you can change the system boot options by selecting Properties from My Computer, clicking the Advanced tab, and pressing the Settings button located under Startup and Recovery. Press the Edit button in the System startup section to edit the boot.ini file, and add the switch /SAFEBOOT:DSREPAIR to the end of the line, as shown in Figure 3. (For more information about boot.ini switches, see microsoft.com/technet/ sysinternals/information/bootini.mspx.)
Figure 3 Setting boot options for DSRM
Figure 3 Setting boot options for DSRM
When you reboot the server, it will come up in DSRM. Remember that you have to remove the /SAFEBOOT switch from boot.ini when you want to restart the DC in normal mode.
Once you’ve logged in using the DSRM password, restore the system state backup using the NTBACKUP command again, but without specifying any parameters. (You can’t perform a restore using NTBACKUP from the command line.) When the wizard comes up, select Restore files and settings and click Next. Then select the backup file and check the System State box as shown in Figure 4.
Figure 4 Using the Backup or Restore Wizard to restore system state
Figure 4 Using the Backup or Restore Wizard to restore system state
If you were to boot the DC back into normal mode at this point, the Active Directory replication process would bring the restored domain controller back into sync with the other DCs in the domain, and all of the restored data would be overwritten with current data. Clearly, this isn’t your goal. Instead, you need a way to force the objects being restored to replicate out to the other domain controllers in the domain.

Performing an Authoritative Restore
NTDSUTIL also increases the version number of each attribute by 100,000 for each day between the date of the backup and the date of the restore. Unless there are attributes that are being updated more than 100,000 times a day (a pretty unlikely scenario), the version number of the restored attributes will be much greater than the version numbers held by other DCs, and the authoritatively restored object will replicate to the other DCs. The other objects that were restored non-authoritatively from backup will be ultimately overwritten by the existing data from the other domain controllers.
After you’ve completed the non-authoritative restore, but before you reboot into normal mode, you use the NTDSUTIL program to perform an authoritative restore of the objects you want to recover. Despite the name, authoritatively restoring an object does not "restore" it; it simply ensures that Active Directory will replicate the object to the other DCs. To do this, NTDSUTIL assigns the next available USN to the local USN of the attributes of the object. This causes the object to be sent to replication partners the next time they synchronize. To restore a single object, make sure the DC is booted in DSRM, and follow these steps:
  1. Open a command window and type:
    ntdsutil
  2. At the ntdsutil prompt, type:
    authoritative restore
  3. At the authoritative restore prompt, type:
    restore object “<DN of object to be restored>”
    For example, if you want to restore the Molly Clark account from the Eng OU in the DRNET domain, you would enter:
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    If you want to authoritatively restore an entire directory subtree, for instance an OU, you would instead enter:
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    (NTDSUTIL also provides a restore database command that authoritatively restores the entire domain as well as the configuration and schema NCs. Restoring the entire domain is fraught with peril and I don’t recommend you use that option. If you need to restore an entire domain, you should restore one domain controller and repromote the other DCs in the domain as described in "Planning for Active Directory Forest Recovery",
  4. When prompted, confirm that the authoritative restore should increase the version numbers of the respective objects and their attributes.
  5. Exit ntdsutil (you’ll need to type quit two times).
  6. Reboot the DC into normal Active Directory mode.
The next time the DC replicates with its partners, the user you restored will replicate out. But restoring the user object is only half the problem. When you introduce object links like those between a group and its members, the situation is more complicated. There are a few fundamental problems you may face during and after the restore, which I will describe in the next few sections.
First, let’s review what happens when you delete an object that has back links. Say you delete a user object that is a member of one or more groups. Each domain controller that has a copy of the user object will convert it into a tombstone and remove any references from the link table, thereby removing the user object from any group memberships in the user’s domain. (Remember that removing the user from group memberships is not a replicated change since each DC updates the group membership locally. The version number and local USN of the group’s member attribute remain unchanged.) A short time later, the phantom objects will be removed from the link tables in other domains, again without updating the replication metadata of the group’s member attribute.
When you non-authoritatively restore the DIT on a domain controller in the user’s domain, you recover the user object along with all of the group memberships in groups in the domain, so the restored DC is self-consistent. And after you use the NTDSUTIL utility to authoritatively restore the user, the user object replicates out to all the other DCs in the domain.
But because the replication metadata of the current groups in the domain is unchanged, the member attributes of the groups on the restored DC are inconsistent with those on the other DCs. And there is nothing to make them converge on a common state. Thus, the user’s memberships will not be restored on the other DCs in the domain.

Problem: Group Memberships within the Domain Don’t Restore
Authoritatively restoring the user object does not recover the user’s group memberships. Why not? Because the membership relationship is stored and replicated using the member attribute of the group objects (the forward-links), not the memberOf attribute of the user (the back-link). The problem is how to find the user’s old group memberships and, once you know them, how to recover them properly.
Microsoft has made incremental improvements to the process of recovering a user’s group memberships, so the technique you use depends on the version of Active Directory you are running. The following section applies primarily to Windows 2000 Active Directory.
Determining the user’s old group memberships is pretty easy: simply inspect the backlink attribute on the restored DC—in this case, the memberOf attribute of the user object. The memberOf attribute will contain all of the memberships to local and global groups in the user’s domain. You can use the Active Directory Users and Computers MMC snap-in (ADUC), or you can use the LDIFDE utility, which is included with Windows Server, to list the restored user’s group memberships.
The following LDIFDE command line will list the groups in the DRNET domain that Molly Clark is a member of, storing the results in the output.ldf file:
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Note that you must boot the DC into normal mode to use any LDAP tools and, again, you must disable inbound replication; otherwise the data you restored would be overwritten. The easiest way to disable inbound replication is to use the REPADMIN command:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Here, <dcname> is the name of the DC you are restoring to. And don’t forget to re-enable replication using –DISABLE_INBOUND_REPL when you are finished.
If you are recovering only a few users, simply adding the user back to the groups manually using ADUC is pretty easy. If you are recovering more than a few users, there are some tools that can automate some of the process. The Microsoft GROUPADD utility (available from Microsoft Product Support Services) can accept the LDIF file you created to list the user’s old group memberships, and in turn generate an LDIF file that recreates those memberships. For instance, you would use this GROUPADD command to process the LDIF file we created in the earlier example for Molly Clark:
C:\> groupadd /after_restore output.ldf
This command will create a new LDIF file for each domain that Molly Clark had group memberships in with the name groupadd_<domain>.ldf (where <domain> is the fully qualified domain name of the domain whose groups will be updated). You would import the LDIF file created above with the following command:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
With Windows Server 2003, Microsoft improved NTDSUTIL to take advantage of the additional metadata that is present in the member attribute to support link-value replication (LVR). If the restored user object had been a member of any groups in the domain, and the user’s group membership was stored with LVR metadata, then NTDSUTIL increases the version number of the corresponding value of the member attribute, which then causes the restored membership to replicate out.
The Windows Server 2003 SP1 version of NTDSUTIL incorporates the GROUPADD functions and will automatically create LDIF files as it performs the authoritative restore of the user object. Figure 5 shows the new version of NTDSUTIL, and Figure 6 shows the contents of the automatically created LDIF file.
Figure 6 Contents of LDIF file created by NTDSUTIL (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Figure 5 New NTDSUTIL with GROUPADD capabilities built in
Figure 5 New NTDSUTIL with GROUPADD capabilities built in
If you are restoring an entire OU that contains a number of users and groups, adding the users back to their groups manually is quite tedious. Another way to recover the restored group memberships is to authoritatively restore the groups themselves.
There are two problems with authoritatively restoring groups, though. The first problem is fairly obvious: if you restore a group, the membership in that group will revert to its state as of the time of the backup. This means that any changes you have made to the group since the last backup will have to be reapplied to the group. The second problem is a little more subtle and has to do with the way Active Directory replication works. After an authoritative restore of both users and groups, there is no guarantee in which order they will replicate out. If a group object replicates to a DC before the restored user object, the replicating domain controller will automatically remove the user reference from the group because the user object does not yet exist on that DC. When the user object replicates in later, it will not be added to the group.
The easiest solution to this problem is to perform the authoritative restore of the groups a second time. After you perform the first authoritative restore, reboot into normal mode and make sure that replication takes place properly. Then reboot back into DSRM and run NTDSUTIL to perform an authoritative restore of the groups the user was a member of. This guarantees that when you boot back into normal mode, the user object will have replicated out before the group objects referring to it replicate.

Problem: Group Memberships in Other Domains Don’t Restore
The "which groups was this user a member of" problem is actually more difficult than I’ve described. The user you’re restoring may have been a member of domain local and universal groups in other domains and those group memberships will not be restored when you do the non-authoritative restore. So how do you know what groups the user belonged to in other domains? The answer is in the global catalog. Along with its own domain’s data, the global catalog contains a read-only copy of the data from the other domains in the forest.
To take advantage of the global catalog’s forest-wide data, you must perform the non-authoritative restore on a global catalog, which means you must have backed up a global catalog to begin with. Now, when you run LDIFDE to identify the user’s group memberships, you can find out the user’s universal group memberships from other domains.
When you list the group memberships of the user you are recovering, connect to the global catalog port 3268 instead of the default 389, and specify the root domain of the forest as the base of the search. LDIFDE will display the recovered user’s group memberships, including membership in universal groups in all the domains in the forest. Here’s how to do this:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
If you run GROUPADD or the new NTDSUTIL on a global catalog, you will produce one LDIF file for the user’s domain, and one LDIF file for each domain in which the restored user was a member of a universal group. When you import these LDIF files, you will restore all the group memberships for the user. Well, almost all—which brings us to the next problem.

Problem: Recovering Domain Local Group Memberships in Other Domains
There are three kinds of groups in a Windows Active Directory environment. Global groups can only contain members in the same domain, but can be used as a member within domain local groups in its own domain and other domains in the forest. The member attribute of global groups does not appear in the global catalog, but this is not an issue because global groups only contain members from their own domain. Universal groups can contain members from any domain and can be used as members in other universal groups in the forest and in domain local groups in its own domain and other domains in the forest. The member attribute of universal groups is replicated to global catalogs. Domain local groups can contain members from any domain in the forest, but cannot be used as members in groups in other domains. More importantly, the member attribute of domain local groups, like that of global groups, does not appear in the global catalog. The result is that there is no easy way to recover the user’s membership in domain local groups in other domains.
Before Windows Server 2003 SP1, the only way to recover domain local group memberships in foreign domains was to restore a DC in each domain, manually search the domain data for any domain local groups that contained the restored user, and then add the user back to the groups you identified. In a large environment with lots of domains, this approach is prohibitively time-consuming.
The Windows Server 2003 SP1 version of NTDSUTIL can help. When you run NTDSUTIL on a domain controller, the utility creates a text file that contains the DN and GUID of the restored user objects. Then for each foreign domain, you can non-authoritatively restore a single DC, copy the text file to the DC, and run NTDSUTIL to generate a new domain-specific LDIF file that adds the recovered user back to the domain local groups it was a member of.
To do this, perform the following steps on a DC in each foreign domain:
  1. Boot the DC in the foreign domain into DSRM.
  2. Use NTBACKUP to restore a copy of the DIT that contains the restored user’s group memberships.
  3. Copy the .txt file created by NTDSUTIL to the current DC.
  4. Open a command window and type ntdsutil.
  5. Type authoritative restore.
  6. Type create LDIF file(s) from <file name> (where <file name> is the name of text file).
  7. Type quit two times to exit ntdsutil.
  8. Reboot the DC to normal Active Directory mode.
  9. Type ldifde –i –f <ldif filename> (where <ldif filename> is the name of the LDIF file you just created).
And now you have restored all the deleted user’s group memberships.

Step-by-Step
Recovering Active Directory users and their group memberships, particularly in a multi-domain environment, is complicated. The specific steps required to properly recover group memberships depend on the version of Windows you are running.
If you are running Windows 2003 SP1, you would take the following steps:
  1. Boot a GC into DSRM and perform a system state restore using a backup that contains the deleted user.
  2. Use NTDSUTIL to perform an authoritative restore of the deleted user. NTDSUTIL will create a text file containing the restored object DNs and GUIDs, and one or more LDIF files to restore the user’s group memberships.
  3. Use LDIFDE –i –f <LDIF filename> (where <LDIF filename> is the name of the LDIF files created in step 2) to import the group memberships in the current domain and other domains.
  4. Reboot the global catalog into normal mode.
  5. On a DC in each foreign domain, boot into DSRM and perform a system state restore using a backup that contains the group memberships of the restored user.
  6. Run NTDSUTIL using the create ldif files command.
  7. Reboot the DC into normal mode.
  8. Using LDIFDE –i –f <filename> (where <filename> is the name of the LDIF file you created in step 6) to restore the group memberships in the foreign domain.
  9. At this point you can optionally force replication with REPADMIN /syncall.
If you are running a version of Windows Server 2003 without SP1 installed, or if you are running Windows 2000, there are some additional steps involved. Since the older version of NTDSUTIL doesn’t create LDIF files, use the GROUPADD utility to create them. The process is:
  1. Boot a global catalog into DSRM and perform a system state restore using a backup that contains the deleted user.
  2. Disable the NIC or unplug the cable to prevent inbound replication.
  3. Reboot the global catalog in normal mode.
  4. Use LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf to dump the membership of the user with the distinguished name <dn>.
  5. Use GROUPADD /after_restore membership.ldf to create LDIF files.
  6. Use LDIFDE –i –f <filename> (where <LDIF filename> is the name of the LDIF file created by GROUPADD in Step 5) to import the group memberships in the current domain and other domains.
  7. Re-enable inbound replication using REPADMIN /options <dcname> -DISABLE_INBOUND_REPL.
  8. On a DC in each foreign domain, boot into DSRM and perform a system state restore using a backup that contains the group memberships of the restored user.
  9. Reboot the DC into normal mode.
  10. Using LDIFDE –i –f <filename> (where <filename> is the name of the LDIF file created by GROUPADD in step 5) to restore the group memberships in the foreign domain.
  11. At this point, you can optionally force replication with REPADMIN /syncall.
The only thing left now for the pre-Windows Server 2003 SP1 environment is to recover the foreign domain local group memberships for the restored user. Your only choices are to manually restore the domain local group memberships or to restore a DC from backup and authoritatively restore the domain local groups.

Summary
Even though it’s quite easy to accidentally delete users or even OUs from Active Directory, properly recovering the deleted users and their group memberships can be surprisingly complex, time-consuming, and error-prone. To ensure that you can recover from these sorts of disasters as quickly as possible, you have to understand the mechanics of object linking, replication, deletion, and authoritative restores.
Do you think you can get all the steps right the first time you try this in your production environment? To make sure you’re ready the next time you have to recover the CEO’s user object, have a written plan prepared for recovering deleted objects. And be sure to practice the plan at least once or twice before you have to try it on real data. Your boss (and your CEO) will appreciate it.
Additional Resources
  • How to Restore Deleted User Accounts and Their Group Memberships in Active Directory
  • Microsoft Product Support Services
  • Step-by-Step Guide to Managing Active Directory

Gil Kirkpatrick is the CTO at NetPro and has been developing software for Active Directory since 1996. Along with Guido Grillenmeier from HP, he delivers the popular Active Directory Disaster Recovery workshops. Gil is also the founder of the Directory Experts Conference (www.dec2007.com).


 Windows Administration: Why Windows XP Embedded Matters to You
Windows Administration Don Jones

Why Windows XP Embedded Matters to You
At a Glance:
  • What's inside Windows XP Embedded
  • Special hardware options
  • Customizing Windows XP Embedded

Windows XP Embedded is the componentized version of Windows you often associate with consumer electronics devices such as set-top boxes or appliances. But Windows XP Embedded may have a place in your organization’s information technology lineup as well. While it may not be the best
solution for every one of your users, there are some specific scenarios where it offers lower administrative overhead, potentially less-expensive and smaller hardware, and greater security.

What is Windows XP Embedded?
Windows® XP Embedded is one of three small-footprint versions of Windows, along with Windows Embedded CE and Windows Embedded for Point of Service. Of the embedded Windows operating systems, only Windows XP Embedded offers the full functionality—or at least the potential for full functionality—of a Windows XP Professional client computer. It’s based on Windows XP Professional Service Pack 2 (SP2); however, Windows XP Embedded is different from the regular Windows XP in its extreme level of modularization. Windows XP Embedded doesn’t have what you might call a standard installation image. Instead, you use a toolkit called the Windows Embedded Studio to create a customized Windows XP Embedded environment for whatever device you’re building, and that environment includes only the functionality your device will need. If you don’t need DirectX® or Windows Explorer, then simply don’t install them. This modularization means that each Windows XP Embedded image you build and deploy will have fewer moving parts, so to speak, which means less administrative effort and greater security, as well as the ability to run on lower-cost hardware. Some of the options available can be seen in the Target Designer (part of the Windows Embedded Studio), as shown in Figure 1.
Figure 1 Selecting components in Target Designer
Figure 1 Selecting components in Target Designer

A Place in the Enterprise
A growing number of user scenarios are ideal for a Windows XP Embedded-based device. For example, consider companies that maintain large customer service call centers. In many cases, call center representatives need one or two internally developed applications and perhaps a Web browser. They’re only using a fraction of their computer’s capabilities, so Windows XP Embedded lets you trim down those capabilities to just what’s needed. Less functionality means that less surface area is exposed to mistakes or possible security attacks.
Because Windows XP Embedded devices have limited functionality, they can be run on less-powerful, often less-expensive hardware. A number of manufacturers, produce motherboards that use low-power, Intel-compatible processors. These motherboards are extremely small, use very little power, and often don’t even use a fan since they run so cool. They work quite well for a small-footprint, embedded device capable of running only a limited set of applications.

The Special Superpowers of Windows XP Embedded
Windows XP Embedded offers some very valuable options that aren’t available in the full version of Windows XP. Enhanced Write Filter (EWF) and Hibernate Once, Resume Many (HORM) both can simplify your Windows administration tasks. EWF is an optional component you can add into a Windows XP Embedded deployment that makes a given disk volume read-only. Any write activity directed to the disk is diverted to an overlay, which can be located on another disk or even in memory. The operating system itself views the EWF overlay and its parent volume as a single unit, meaning it looks just like a normal disk volume. Behind the scenes, however, the parent volume isn’t actually changing; changes are only made to the EWF overlay. There are a few ways this can be beneficial. Imagine deploying a Windows XP Embedded image to a Compact Flash (CF) card (Windows XP Embedded images can be as little as 5MB, and often check in at around 200MB, so CF would have plenty of storage). That CF card can plug into an adapter and connect to a motherboard’s IDE connector, making the CF card look like a normal fixed disk. Today’s CF cards have limited write capability (about 100,000 writes), so EWF would be used to make the CF volume read-only. Imagine putting the EWF overlay in RAM: if the user makes a mistake, just turn off the machine. The EWF overlay and any changes made to the machine are lost immediately. When you reboot, you’re back to the starting point stored on the CF card. You can use the same set-up for a CD- or DVD-based image; since those media types are inherently read-only, EWF captures any write activity to an overlay. Even if the overlay is stored on a small internal hard disk, you’re assured that the original boot volume (on CD or DVD) isn’t ever changed; if you need to reset the machine to its original configuration, simply wipe out the EWF overlay.
HORM, as the name implies, allows you to hibernate a machine one time and then resume from that hibernate point over and over again. The computer turns on almost instantly. Simply configure the computer and get all the needed applications running, and then hibernate it. From then on, each time you turn on the machine, you’ll only need to wait a few seconds to have everything up and running again.

Building a Windows XP Embedded Image
Microsoft has an Embedded Partner program consisting of companies that specialize in working with Windows XP Embedded (you can find lists of them on the Windows XP Embedded home page at microsoft.com/embedded). However, with just as many companies providing their normal PC manufacturers with prebuilt images (which include corporate applications and specific configurations), you might want to build your own Windows XP Embedded images that you can then share with an Embedded Partner who is providing you with complete, small-footprint systems. The Windows Embedded Studio, which installs on Windows XP Professional, can be used to build and manage Windows XP Embedded images.
To use the toolkit, first install the full version of Windows XP Pro on the hardware you plan to use for your Windows XP Embedded system. This lets you use the full Windows XP setup routine to get all the hardware working properly. Then, install the Windows Embedded Studio. This normally installs a database that’s used to manage embedded images but the database can actually be installed elsewhere, providing a central repository. Next, you’ll run a command-line utility called Tap.exe, which creates a special new component that can be used by Windows XP Embedded. Normally, components encapsulate functionality such as a media player, a file system, or other custom applications; in this case you’ll be creating a component that contains the hardware device drivers needed for your particular system. This step must be completed on the target hardware so that the tool can detect and include the appropriate hardware drivers.
In the next step, you run the Windows XP Embedded Component Designer and import the component package created by the Tap.exe utility. As shown in Figure 2, the Component Designer reads the device information and assembles a complete Windows XP Embedded component, which can become the basis for a new Windows XP Embedded image. This greatly simplifies the process determining exactly which device drivers a given platform will need. After creating the component, you use the Component Database Manager to import the new component into the Windows XP Embedded component database, a repository where all known Windows XP Embedded components are stored. Having the component in the database makes it available for use in Windows XP Embedded images.
Figure 2 Component Designer
Figure 2 Component Designer
Now you’re ready to begin creating a new target configuration, using the Windows XP Embedded Target Designer, the tool where most of your actual work will take place. As you saw in Figure 1, you’ll add whatever components you need to create the set of functions your device requires. You’ll also need to add some Windows core components, such as Windows Explorer (if your device requires a graphical shell), the NTFS file system (or FAT32), NT Loader, support for a language, the user interface core, and so on. More than ten thousand components are available by default.
You can also preconfigure each component’s settings. For example, the User Interface Core component can be customized to display specific items on the Windows Start menu, Desktop, and other locations. Customizing the settings for each component ensures that each device will be preconfigured to suit your needs (see Figure 3).
Figure 3 Customize settings
Figure 3 Customize settings
The trickiest part to a Windows XP Embedded image is the dependencies. For example, you can’t add a DirectX component to your image without also adding several components that provide Windows with its core graphics-handling capabilities. Keeping track of all the dependencies can become quite difficult, especially for larger, more complex images that may have literally thousands of dependencies. This is the job of the Component Database. Simply press F5 within the Target Designer and it’ll scan through every component you’ve added, automatically adding any dependencies your listed components require. Figure 4 shows the scan in progress; this is a critical step and is what allows Windows XP Embedded to be so highly modularized. Without this intelligence built into the Target Designer, it would be very difficult to successfully create images that contained all the correct dependencies.
Figure 4 Dependency check
Figure 4 Dependency check
When all of your components and their dependencies have been added, you can build your Windows XP Embedded image. Images are simply the files that need to be copied to the boot volume of your Windows XP Embedded device. You don’t need any special tools to deploy them (although the Windows XP Embedded toolset includes a remote boot server similar in functionality to Remote Installation Services; it permits deployment of Windows XP Embedded images to bare-metal hardware). After completing these steps, you can see how big your image actually is. I created a very basic image that included the Explorer shell and a few applications, such as Notepad and Paint, and created an image of less than 90 megabytes. Sure, you probably won’t find many users interested in a device that just runs Notepad and Paint, but it illustrates how small a task-specific image can be.

Windows XP Embedded vs. Windows XP
Windows XP Embedded isn’t at all a stripped down operating system option. Microsoft makes prepackaged components available that allow a computer running Windows XP Embedded to have much of the same functionality as a full version of Windows XP. This includes options to install DirectX 9.0c, the Microsoft® .NET Framework, Windows Media® Player 10, and more. You’ll also find plenty of developer documentation that describes how to build custom components, such as a custom shell to replace Explorer, allowing you to create a tailored environment for your specific Embedded device.
Windows XP Embedded does not, however, offer every single feature included in the full version of Windows XP Pro. For example, Windows File Protection (WFP) isn’t included in Windows XP Embedded; nor does it include some of the user-friendly features such as Windows XP Tour, the initial welcome screens and wizards that help a new user configure his computer, or Windows Setup. Windows XP Embedded doesn’t utilize Windows Product Activation (Windows XP Embedded images are activated by using a runtime product key from within the Windows Embedded Studio tools). Most notably, Windows XP Embedded doesn’t use Windows Update at all, although it can use a Microsoft Software Update Services server in your environment. Finally, Windows XP Embedded also lacks MSN® Explorer, which is included in Windows XP Pro.
Looking ahead, Windows XP Embedded continues a rich development cycle: Feature Pack 2007 is now available, adding new features such as USB-based boot, an enhancement to EWF that allows new files to be committed to the parent volume without committing the entire overlay, support for NTFS compression, and more. These enhancements continue to add flexibility and options to the Windows XP Embedded operating system, while bringing it more on par with the feature set in Windows XP Professional.

Going Embedded
Embedded systems may take a bit more work to build than a traditional Windows XP system, but they offer significant advantages in certain scenarios. Although reduced in functionality, Windows XP Embedded systems can support smaller, lower-powered hardware that’s easier to care for, easier to repair, and can cost significantly less. Lower power consumption also helps reduce utility bills and heat generation, allowing for more flexibility in designing compact workspaces. Aside from the expected uses for Windows XP Embedded—consumer devices, healthcare devices, kiosks, and other places where you might not even realize that Windows XP Embedded is under the hood, this embedded operating system may just have a place in your enterprise, too.

Don Jones is the Director of Projects and Services for SAPIEN Technologies and coauthor of Windows PowerShell: TFM (SAPIEN Press). Contact Don through his Web site at www.ScriptingAnswers.com.


 Management: Plan Ahead with System Center Capacity Planner
Management John Savill

Plan Ahead with System Center Capacity Planner
At a Glance:
  • SCCP basics
  • Creating a new model
  • Fine-tuning the model
  • Simulating actual usage

Today’s infrastructure components are critical to the businesses they support. However, as the number of users increases and companies become more diverse, accurately estimating the size and
number of servers to run the components on becomes a challenge. Insufficient hardware leads to poor response times for end users and too much hardware is simply a waste of budget and entails additional management. For this reason Microsoft created System Center Capacity Planner (SCCP) 2006.
At a high level, SCCP allows you to enter information about network topology (locations, link speeds, latency), software and hardware to be used, and usage profiles (such as number of messages sent). SCCP then runs simulations of different usage levels and details the utilization of hardware and network components. This modeling helps ascertain whether the proposed configuration would be adequate in meeting your service requirements if implemented.
SCCP does not need to run on any specific server or perform network testing; it is essentially a simulation tool that can run test scenarios against a modeled environment. The actual system requirements for SCCP are minimal: Windows® XP with Service Pack 2 (SP2), Windows Server® 2003 or Windows 2000 with SP4, plus Microsoft® .NET Framework 2.0. The next generation of SCCP can be expected to interface more closely with Systems Management Server (SMS) and Microsoft Operations Manager (MOM), and to automate some of the information gathering since MOM already collects information about server utilization and SMS maintains information about hardware configuration.
The installation of the SCCP 2006 is simple; a standard installation wizard only requires license agreement acceptance and confirmation of the installation folder. Once the product is installed, a shortcut will be added to the All Programs menu. When you start SCCP for the first time, the Microsoft Capacity Planner Welcome screen provides access to three of the four components of the capacity planner as shown in Figure 1.
Figure 1 Starting the capacity planner tool
Figure 1 Starting the capacity planner tool
The Model Wizard asks you questions about the desired environment in order to create a System Architecture Model (SAM). The SAM includes detailed locations, users, network, usage patterns and hardware.
The Model Editor allows for fine-tuning and modifications to SAMs previously created via the wizard or editor. This is where you can validate models, display simulated usage, and test other scenarios such as additional load on mail servers or the presence of remote users.
The capacity planner comes with a number of hardware types predefined for use in SAMs. However, if your needs differ, the Hardware Editor supports custom definition of hardware configurations.
When a model is selected, the Capacity Planner Simulation allows various tests to be performed against the selected model in order to determine its viability for actual real-world implementation.
The best way to look at the components and how they operate with each other is to actually use the tool. I’ll start with the wizard, run a simulation, and then fine-tune an architecture model by adding custom hardware. In this walkthrough, I will deal with an Exchange environment, but the process works in a similar manner for MOM.

Creating a New Model
Before you can perform validation or "what-if" scenarios on a planned infrastructure, or even if you just want to run scenarios about your currently deployed infrastructure, the environment must be described to SCCP. Unfortunately, you cannot simply scan the network in the current version. Instead, you must detail your infrastructure in terms of physical locations and types of connectivity between them, placement of servers, mailboxes, and users, and details about how the users will employ the environment.
There are a few limitations to the tool, which are explained in the user guide in detail. For example, in an Exchange model, only a single forest is supported. This means domains in external forests are not modeled, and any front-end servers are assumed to have both a Global Catalog and Mailbox store in the same site. Only 100 sites can be modeled of which up to 10 can be hub sites, a maximum of 300 server computers, and only Outlook® 2003 clients (Web or local) are supported. The good news is that SCCP supports up to 49,999 clients in central/hub locations, and up to 10,000 in branch locations. Exchange features such as ActiveSync® and Outlook Mobile Access connections are not supported, nor are legacy connectivity options such as POP and IMAP. Utilization caused by backup and restore operations are not accounted for and neither are cluster configurations; however, the capacity planner has the required options to accurately model typical day-to-day mail usage.
To begin the walkthrough from the Welcome page, select "Create a model with the Model Wizard" and describe the infrastructure to be modeled. I’m going to create a company that has three locations—a central location in Dallas and branch offices in Houston and Austin—each of which has a number of local e-mail users. Each location does not necessarily have its own servers, so I provide information on the number and type of e-mail users; SCCP will calculate in which locations local Exchange servers should exist and where users will access their Exchange server remotely.
After creating a basic model of the enterprise infrastructure, the wizard asks for the number of central and branch sites, the connectivity between sites, and the percentage of bandwidth that can be used for messaging purposes. The wizard takes a broad approach to get things running; later on I can fine-tune the model created by the wizard to configure individual links with more granularity. In this example, I can confirm the one central office and two branch sites (see Figure 2). There are T1 connections between the branches and the central site and half the bandwidth can be used for messaging. I do not need to configure the speed between central sites since I only have one.
Figure 2 Configuring WAN topology and connection bandwidth
Figure 2 Configuring WAN topology and connection bandwidth
The next window of the wizard asks for the average number of users at the branch locations, the e-mail client (Outlook 2003 in cached mode or Outlook Web Access), and the number of users at the central site. Again this is very high-level information and can be fine-tuned later using the Model Editor. In this case I’ll say that each branch has 200 users and the central office has 500, all of which are using Outlook in cached mode.
The wizard has three default mail usage levels: High, Medium and Low. Each level assumes a different average mailbox size, number of messages sent and received, and average size per e-mail message. If none of the built-in types match the usage patterns expected in your organization, individual values can be configured for each of four separate usage characteristics.
The next step is to configure the hardware preferences as shown in Figure 3. SCCP allows up to three possible CPU configurations to be specified, and these will be used to model hardware for the various server roles. CPU configurations range from a single processor 1 GHz Pentium III Xeon all the way up to quad processor 3.66 GHz Xeon MP. Exchange 2003 consists of a number of roles, namely Mailbox Store, Bridgehead, and Front End, plus an additional Active Directory® Global Catalog role. If utilization permits, the option is available to consolidate roles onto fewer servers. If server consolidation is not specified, then separate servers will be configured for each of the roles even if utilization does not require it. Allowing SCCP to consolidate will provide the best results.
Figure 3 Configuring hardware profiles for servers
Figure 3 Configuring hardware profiles for servers
Finally, the type of disks available can be selected based on the interface, size, and speed. The number of disks is not required; the capacity planner will calculate it for me. The planner can also specify a Storage Area Network (SAN), although the ability to create clusters is not currently available.
The next step in the wizard is a summary of the calculated model, which shows the number of servers SCCP calculates as optimum, the roles of each of the servers, and details such as processor, memory, and disk configurations. If a SAN had been selected, it would also be displayed.
Note that just because I selected multiple locations, it is quite possible that servers are only displayed for a subset of the locations. This is because SCCP ascertained that local Exchange servers at some locations are not optimal and instead mailboxes are better served via a remote Exchange mailbox server which is the case in my example as shown in Figure 4. In this case, the 400 branch office users have no local Exchange mailbox store, but instead have been consolidated onto the single Exchange mailbox store server in the Dallas location which now shows 500 users.
Figure 4 A summary of the initial capacity planning evaluation
Figure 4 A summary of the initial capacity planning evaluation
Up to this point in the wizard I can click the Back and Next buttons to modify answers and fine-tune the model summary (or directly click on wizard pages via the left-hand navigation pane). When satisfied with the configuration, I click the Finish button on the Model Summary page. This opens the model in the Model Editor, which is where more granular configuration is possible.

Fine-Tuning the Model
The Model Wizard is a great tool for creating a foundation model. However, unless the various locations are all the same and averaged out, some customization will likely be required for the model to be truly useful as a basis for calculating utilization. It’s not unusual for locations to have different numbers of users, or perhaps a combination of the various messaging clients such as some Outlook 2003 cached and some Outlook Web Access (OWA). While it’s not possible to get to this level of detail in the Model Wizard, it is configurable via the Model Editor. This tool is also useful when trying to ascertain the effect of modifying aspects of the environment, for example by adding additional locations or types of users.
The Model Editor, shown in Figure 5, saves and retrieves models in .sam files, which are a proprietary format to the tool. It is good practice, as with all work, to save models to file before major changes are made, and to use a descriptive name to ensure no working models are lost. The File menu provides an Export menu that generates a detailed summary report in Excel® format and as a Visio® topology diagram of the model.
Figure 5 Tweaking a SAM configuration in the Model Editor
Figure 5 Tweaking a SAM configuration in the Model Editor
In the left-hand pane of the Model Editor is a basic navigation area with options to see the global topology, site topology, or a model summary. Global Topology shows the architecture model from a site perspective with additional networks such as the Internet. The Site Topology view displays information about a selected site or network. Model Summary displays a textual summary of the environment, which is the same format as what you’ll see displayed at the end of the Model Wizard.
Whichever option is selected, the details are displayed in the center pane of the Model Editor. The right-hand pane—in the spirit of the new version of the Microsoft Management Console (MMC) that shipped with Windows Server 2003 R2—is an "actions" area that is split into two sub-areas: the top part provides context-sensitive actions that change depending on the current view or object selected, while the bottom part contains general actions that always apply. These latter actions let me add a new site, edit usage profiles of users, and (the fun bit) run a simulation.
When working in the Model Editor center pane, all of the items are selectable. After selecting an item, in addition to the current item actions changing based on the selected object, I can drill down into more detail about the object. For example, double-clicking on a site will switch to the Site Topology view and give details of the objects modeled for that site. Thus, a locally served site would show one or more servers, networks and the users at the location. This makes it possible, in turn, to double-click the selected object to view its detailed properties of and then modify them as needed.
The lines that connect the sites represent the networks between the locations and can be edited to allow exact configuration of the network. For example, I can specify different uplink and downlink bandwidth speeds and the percentage of the bandwidth that is available. I can also configure connection latency, which can be a very important attribute for stable communication. Other common changes include adding additional user types. In this instance, let’s say that I have a mixture of Outlook Web Access and Outlook 2003 clients serviced by the central location. After opening Dallas in its Site Topology view, I would select "Add a client profile" and add information for the OWA-based users that would include the server that the OWA clients will use, the network the users will connect from and the bandwidth that will be available to them, as shown in Figure 6.
Figure 6 Adding and modifying elements in a model is easy
Figure 6 Adding and modifying elements in a model is easy
Once the SAM reflects the existing or planned infrastructure as closely as possible, save and name it accordingly to ensure that it is easily identifiable as the starting point for any future modifications. At this point, I like to run a simulation to get a benchmark of how the model will perform under the configured settings. Based on that benchmark I can modify the model to test various "what if" scenarios such as adding a new site and users, adding or removing servers, adding new users to locations, or changing the type of connection or e-mail client. Once the model has been updated with these new elements, I can run another simulation to see how the new configuration holds up.

Simulating Actual Usage
Running the simulation is as simple as clicking the Run simulation general action or toolbar button. A sanity check of the model happens first: any flaws in the model are displayed before the simulation is performed. For example, if a number of OWA clients are added to a model that previously had no OWA clients and no Front End server was configured, an error message will notify you that no Front End server exists. If no such flaws exist, status will be displayed as the simulation is performed.
Once the simulation is complete, a report with detailed information about the usage of all components is generated and the Simulation Results view will open. It initially displays a summary view giving details of highest CPU, storage and connection link utilizations (which are common bottleneck causes) as well as longest transaction and latency times, which may affect end-user experience. Details about exact utilization of the servers, SAN, local and external connections can be viewed by selecting links in the left-hand pane of the simulation results as shown in Figure 7.
Figure 7 Simulation results summary for a simple model
Figure 7 Simulation results summary for a simple model
Holding the mouse over the various graphical displays, such as the Bottleneck analysis, shows the server and the attribute of the server that is causing that bottleneck. Notice the Threshold settings in the left-hand pane. This category allows me to set what I consider reasonable usage before raising warnings, a useful feature.
The detailed simulation reports are great not just for helping to inform hardware purchase decisions but also to show the amount of network resources that will be used by the messaging applications. For example, for users connecting via slower WAN links, the report provides an indication of whether the link is fast enough. If it’s not, I can find out if the speed of the link between locations should be upgraded or if a local mailbox store server should be added, simply by modifying the model and re-running the simulation to get results that fit specific criteria. Likewise, if the servers are all running at 5 percent CPU utilization, I can drop the specification of the servers. By allowing for easy model modification and the ability to re-run simulations, I’m actually free to experiment with different solution options. With accurate metrics from all of the tested scenarios, I can walk into budget and planning meetings with confidence.

Summary
I just gave you an overview of how SCCP enables you to simulate and analyze Exchange deployment. Keep in mind that SCCP performs the same level of modeling and simulation for MOM as well. SCCP can currently be downloaded as part of MSDN® Premium downloads or TechNet Plus. ¦

John Savill is Director of Technical Infrastructure for Geniant. He is a CISSP, a Security and Messaging MCSE on Windows Server 2003, an eight-time MVP, and a Krav Maga instructor. He is also the author of Windows Server 2003 Active Directory Design and Implementation from Packt Publishing.


 Management: Advanced Client Inventories with SMS
Management Wes Dobry

Advanced Client Inventories with SMS
At a Glance:
  • Using the SMS 2003 Hardware Inventory Agent
  • Expanding inventorying with MIF files
  • Dynamic vs. static MOF files
Download the code for this article: DobrySMSInventory2007_04.exe (152KB)

There comes a time in every administrator’s life when his boss asks for some information that can’t be collected without arduous amounts of work. But imagine being a proactive administrator
who was already collecting this data. You could supply your boss with the information instantaneously, thereby preventing unnecessary down time, avoiding overtime hours, and possibly even saving the company a lot of money. You could be a hero.
Out of the box, Microsoft® Systems Management Server (SMS) 2003 collects a vast amount of information. But it doesn’t collect everything. For instance, SMS 2003 does not report by default on local groups and their members or local users and their attributes. Not having this information can be a problem if, say, a technician is putting Domain Users or, even worse, Everyone into the local administrators group on each system they work on. Or, say a company has no way of knowing what the local file and folder exclusion lists are on their corporate antivirus/anti-spyware solution. This may not seem like a major problem—until someone in IT realizes that users are putting c:\*.* in the exclusion list.
With the proper combination of scripting, Windows® Management Instrumentation (WMI), and SMS knowledge, you can expand SMS inventories to contain almost any morsel of information. This is made possible through the use of MIF (Management Information Format) and MOF (Management Object Format) files.

Taking Inventory
With SMS, organizations can perform customized deployments, monitor the targets, and maintain the deployed systems. By expanding SMS inventories, you can create and manage a much more customized target. For example, you can enforce corporate local security policies by deploying your security policies to systems that have had the policies modified by a user. You can also disable non-approved local user accounts and remove extraneous local administrators.
Of course, organizations also rely on SMS for getting timely, detailed information about client systems. Expanding the inventories allows you to create reports that contain completely custom information that isn’t readily available when relying solely on the default inventories. And the information can be very granular. For instance, you might create a report that contains the count of systems that have a specific registry key that points to a particular server farm. This would allow the administrators to assess approximately how many clients are pointed to each farm at any given time. Similarly, the security team can check to see which systems on the network are running a specific process that is known to be spyware.
The value of MIF and MOF files comes from the ability to input information from almost any source with a bit of translation. As long as the information is text-based, the information can be manipulated and placed into WMI with a MOF file, or collected in the form of a MIF file, and sent on the next hardware inventory cycle. Implementing an inventory expansion requires knowledge of VBScript or JScript®, as well as knowledge about what is to be collected. Considering that just about anything can be collected, this required knowledge can range from WMI to advanced SQL knowledge. Of course, SQL comprehension is a must no matter what type of information you are gathering, since you’ll need this knowledge when it comes to reporting on the collected data.

How Inventories Work
SMS contains two types of inventory processes: hardware and software. Software inventories only have information about files, such as where they are located, what versions they are, their size, and other file attributes. However, the software inventory process also allows you to collect files and store them on the site server.
Expansion of hardware inventorying is easily done since hardware inventories contain the largest array of information about a system. The information in hardware inventories is derived predominantly from WMI, the registry, and the system BIOS.
Hardware inventories are collected on a schedule, which is set in the Hardware Inventory Agent site settings on SMS 2003. Collections can be set to occur as often as once every minute to as infrequently as once every several months. Typically, you want to find a balance that collects this information at the fastest rate required by management but without taxing the network, site servers, management points, or clients.
When the Hardware Inventory Agent is first installed, it compiles the sms_def.mof file. This contains all the information that SMS initially collects. When this file is compiled, all the SMS namespaces and associated classes required for the Hardware Inventory Agent are created in WMI. Most of these are located in the \\.\root\CIMv2\SMS namespace. After installation, the Hardware Inventory Agent looks through most of these classes to build the information that is then sent to the management point and eventually the site database.

MIF Files
In addition to pulling information from these WMI classes, the Hardware Inventory Agent looks for MIF files in the NOIDMIF and IDMIF collection folders. Any MIF files the agent finds in these locations are processed into the next hardware inventory.
MIF files provide the easiest way to expand the SMS Hardware Inventory. There are two types of MIF files—NOIDMIF and IDMIF files. These files are static, XML-like files that can contain almost any information a user could want to put into the SMS database. They can be created by any means used to create ordinary text files. Thus, these files can be created by most scripting languages, or just by hand.
Typically, MIF files are used in situations where the information is not contained in the registry or WMI, or when the information needs to be entered manually. These files can be created, for example, when your hardware deployment team delivers a new system. The deployment technician can navigate to an HTML application on the system and input all the asset information to be used to update an asset management database. That application then dynamically creates a NOIDMIF file and allows the technician to download the file to the NOIDMIF file collection folder. This NOIDMIF file can contain all the information entered by the technician and it is incorporated into the SMS database.
NOIDMIF and IDMIF files have only a few differences. An IDMIF file contains a unique header that provides architecture information and a unique ID. IDMIF files can be used to incorporate non-system devices into SMS as their own entities. For instance, a script can be used to create systems in SMS that are actually printers and write information about them into the SMS database.
NOIDMIF and IDMIF files are stored in standard locations, which are dictated by registry keys. Most of the time, they are %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF and ...\IDMIF, assuming that the SMS agent was installed in the default location. If the agent was installed in a custom location, the MIF directories should be in %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF and ...\IDMIF. But if there is any doubt as to the locations of these directories, you can find the locations listed in the following registry keys:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
MIF files always have the same format, regardless of the information collected. Looking at the MIF file shown in Figure 1, you’ll see that the file is comprised of a single component that contains multiple groups and a single attribute in each group. All of the sections are required, though you do not need to have more than one group or attribute entry. You can look at it as if each group in the MIF file is a row in the data of the named section in the hardware inventory and that every attribute in the group is a column of that row.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
The sample LocalAdmin.vbs, which is shown in Figure 2, is a fairly simple VBScript. It looks up the NOIDMIF directory, deletes the temporary MIF file if it exists, creates the temporary MIF file, writes information collected via a simple WMI query recursively to the file, deletes the MIF file that exists in the NOIDMIF collection folder, and then finally moves the temporary NOIDMIF into the NOIDMIF collection folder.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
While MIF files provide an easy way to expand the SMS Hardware Inventory, there are some issues to consider when using them. MIFs are processed in every hardware inventory cycle. But since these files are created, collected, analyzed, and then finally put into inventory, the information contained in a MIF can be delayed from showing up in the inventory by up to one hardware inventory cycle. This means that if a company has one-day hardware inventory cycles, the data in their site database could be up to two days behind. Therefore, you must carefully consider when the programs that create MIF files are advertised and when the hardware inventory cycle runs.
Say a company named Contoso has one-day inventory cycles that run at midnight. On Monday at 1:00 AM, a VBScript runs, creating a NOIDMIF file that contains the output of a rootkit scanner. This output is collected at midnight and reported to the management point. The Contoso SMS administrator then looks at the information on Wednesday evening at about 10:00 PM and finds that the information is 45 hours old. This is because the SMS administrator didn’t put thought into when to advertise the program used to create the NOIDMIF file.

MOF Files
MOF files are more complicated than MIF files. And they have an advantage over MIFs in that they input their information directly into WMI and become part of the hardware inventory agent’s standard data collection process. Thus, you may not have to advertise a VBscript over and over to get information, saving you time and hassle. You can instead advertise the MOF once per computer and it is then compiled.
MOF files also have the advantage of the information being just as current as the rest of the information in the hardware inventory. Every time the Hardware Inventory Agent goes through its cycle, the classes and providers detailed in the MOF file are queried and the information is returned quickly. When you need information quickly, you can execute a package that contains your MOF file and a VBScript, kicking off a hardware inventory. The information you need is then acquired in as little as one advertised program policy cycle.
There are three classifications of MOF files: MOF files for an existing WMI class and namespace, MOF files for an additional class with an existing WMI provider, and MOF files for an additional class that does not have a WMI provider.
MOF files contain two parts. The first part is the namespace definition section. This is where the WMI provider information is identified. The second section contains SMS reporting attributes. This section tells the Hardware Inventory Agent where to look for and process the information contained in the WMI classes mentioned. Since MOF files deal directly with WMI, I recommend that you take some time and look into the Microsoft WMI Software Development Kit (SDK) if you plan to work with these files (see go.microsoft.com/fwlink/?LinkID=83121 for more information).
Each of the aforementioned classifications of MOF files can be either static or dynamic. For example, you would have a static MOF file if you had the company’s build procedure compile a MOF file that contained information regarding who built the system, what build of servers they used, what the initial build versions were, the date on which the machine was built, and so on. This information never needs to be updated and therefore the information can be put directly into the MOF file and compiled into WMI using mofcomp.exe. After this occurs, the area in which the Hardware Inventory Agent is looking needs to be expanded by adding the group and class information into the sms_def.mof file on the site server.
A dynamic MOF file is similar to a static MOF file except that instead of writing collected information directly into WMI, data is collected via a WMI provider. A WMI provider is a plug-in that allows an application or service to directly input information into WMI. This provider allows dynamic access into other areas of WMI and the system, such as the registry, file locations, and Windows Installer information
In terms of working with MOF files, the easiest way to enhance the hardware inventory is to have the inventory catalog more information that already exists in WMI. This can be done by extending the sms_def.mof or turning on additional reporting classes that are currently disabled. The sms_def.mof file is located in the \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv folder. All the devices in the company will pull the new sms_def.mof on their next machine policy cycle and begin collecting and reporting the information.
Next in line, in terms of difficulty, is using an existing WMI provider but creating a new class. An example of this approach is shown in Figure 3. In this example, by using the built-in registry provider, the class CU_Desktop is created with a dynamic property querying HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper on the local device. After this MOF file is compiled on the client, the information contained in SMS_Def_Extension.mof (see Figure 4) needs to be appended to sms_def.mof. The file contains information regarding whether SMS should report on it, the group name, the class ID, what class the Hardware Inventory Agent should look in WMI to find the information to report on, and finally, the actual values.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
MOF files also have the ability to access information provided by WMI providers that are not included by default on systems. In order to use these providers, the WMI provider must first be distributed and installed before the MOF file is compiled on the client and sms_def.mof extended.

Wrapping Up
MIF and MOF files are powerful tools for quick and substantial information collection. These file formats provide the framework for easily introducing information into the SMS database without directly modifying the tables. With enough imagination, almost anything can be inventoried and reported on. Even better, problem situations can be avoided, as administrators can act proactively to gather vital information.
Understanding MIF and MOF files takes some time. However, there are helpful resources available that can assist you in learning how to make use of these files. For starters, check out the WMI documentation and SDK, as well as the Systems Management Server 2003 Operations Guide. If you put the effort into understanding these concepts, what you get out of expanded SMS inventorying will far outweigh what you put into it.

Wes Dobry is located in the Orlando, Florida area where he works as a consultant and as a Network Administrator for a large healthcare firm. Contact him at wesdobry@wesdobry.com.


 Management: Deploying Custom Software Updates with SMS 2003 R2
Management Steve Rachui

Deploying Custom Software Updates with SMS 2003 R2
At a Glance:
  • New update management features in SMS 2003 R2
  • The Custom Updates Publishing Tool
  • The Inventory Tool for Custom Updates

When you need to deploy custom updates for your systems, say for specialized hardware or line-of-business applications, you don’t have the advantage of a managed, automated process as you have with Windows updates. At least you never did before. Now, thanks to Systems Management
Server (SMS) 2003 R2, you can use those same managed-update features to deploy your own custom updates. SMS 2003 R2 includes a number of new features, including an update to the Device Management Feature Pack, links to the Operating System Deployment (OSD) feature pack, and many features that enhance security monitoring. The product has a scan tool for Vulnerability Assessment, which is key to understanding potential system and network vulnerabilities such as weaknesses in OS configuration, user passwords, IIS and SQL Server™ configurations. It also includes an Inventory Tool for Custom Updates (ITCU) and a Custom Updates Publishing Tool (CUPT). These are the two tools I will focus on in this article to help you deploy your own custom updates easily and efficiently.

Custom Updates Publishing Tool
Before you can install and use SMS 2003 R2, the hierarchy, including clients, must be updated to SMS 2003 Service Pack 2 (SP2). To use the CUPT, you need to upgrade to the Microsoft® Management Console (MMC) 3.0. You do not have to install CUPT on the SMS Site Server, but it must be installed on at least Windows® XP, and it requires SQL Server 2005 for hosting its database; SQL Server Express Edition must be installed if SQL Server 2005 is not already available. The CUPT is the key to introducing and managing custom updates in the SMS system and it also has features to test created catalogs prior to publishing them in SMS.
Custom updates can take two forms—updates that are provided by third-party vendors for software they produce, and updates created internally that are unique to a particular environment. CUPT is the tool to use to manage both types. It’s easiest to use custom updates provided by a third party, so let’s start there. At the time of this writing, three companies are producing update catalogs that can be used to scan for and distribute appropriate patches in SMS—Adobe, 1e, and Citrix. Participating companies may be viewed by selecting the custom updates partner catalogs, as shown in Figure 1.
Figure 1 CUPT in action
Figure 1 CUPT in action
Using partner-supplied updates is a simple matter of downloading the catalogs and adding them to SMS. First download the updates you need and then choose the option on the Action menu to import the updates. A wizard will ask for the location of the .cab files you just downloaded. When the wizard has completed, the new updates will be visible in the CUPT for further configuration and publication to the SMS site server. Note, however, that each update needed must be flagged for publication. If an update is not flagged, it will not be included when the request to publish is made. You can do this in bulk, as shown in Figure 2. Note that the far right-hand column must have the flag enabled in order for the update to be published.
Figure 2 Setting the publish flag
Figure 2 Setting the publish flag
You can further customize each downloaded update if required. To do so, simply select the update and choose Edit. Take care when customizing an update, however, as improper configuration can lead to unexpected and unsatisfactory results.
After flagging the updates, it’s time to publish them. You can accomplish this either by publishing to an external .cab file for later use or by synchronizing selected updates with the SMS site database for immediate use. In order to synchronize with the SMS site database, you need to supply configuration information such as the Site Server name and package source path (see Figure 3).
Figure 3 Synchronization information
Figure 3 Synchronization information
You can find this screen by highlighting the Custom Updates node and then choosing Settings from the Action menu. After you supply an accessible site server name and the path pointing to source directory for the Inventory Tool for Custom Updates, the site code and status will be updated.
With the synchronization options set, CUPT is now ready to synchronize with the SMS Site Server. To perform the synchronization, select the publish updates option from the Action menu. This will initiate the publishing wizard. In order to publish the updates to the SMS database for immediate use, ensure that the option to synchronize with Site Database of Systems Management Server is selected. Happily, this step comes with some visual assistance: this option will be gray if the synchronization settings haven’t been configured.
After the wizard completes, the custom updates are available for action in the SMS administration console. Starting the Distribute Software Updates Wizard provides an option to work with any available custom updates.
Now that you’ve seen the process for consuming and using vendor-produced updates for third-party products, what about custom updates for vendor-supplied software when there are no prepackaged updates available? This is where CUPT really shines. With CUPT, you can create custom updates complete with full targeting criteria to cover almost any situation.
Creating a custom update is not difficult but it does require that the administrator understand how to patch the software, what criteria to use to determine whether a patch is applicable, and what targeting rules should be used to focus the update. Targeting rules are defined separately from the update creation process. They can be viewed by selecting the Manage Rules option from the Action menu.
Custom update creation is initiated by selecting the Create Update item on the Action menu, which launches a wizard where you’ll supply the details of the custom update. Detailed discussion of creating a custom update is beyond the scope of this article, but it is instructive to select properties on one of the imported custom third-party updates to understand what is required in each field when building your own update. The properties of a configured third-party update are shown in Figure 4.
Figure 4 Properties of a third-party update
Figure 4 Properties of a third-party update
Using the custom updates creation process, you can do more than just updates; you can also configure software to be distributed to client systems. Although this will work, it is important to note that it is not a recommended approach nor is it the intended use of CUPT.

The Inventory Tool for Custom Updates
The ITCU is a new inventory tool that works with custom update catalogs. Like the scan tools before it, ITCU creates custom collections, packages, and advertisements that are used for deploying the scan tools to SMS clients in the enterprise. Just as with previous scan tools, ITCU will retrieve the catalog, in this case the custom updates catalog, from an accessible SMS distribution point, perform the scan based on catalog data, insert the results of that scan into Windows Management Instrumentation (WMI), and report the results via hardware inventory. The main difference in the scan process is the catalog used.
The introduction of SMS 2003 R2 adds a powerful tool to the existing SMS security arsenal. Never before have administrators been able to leverage existing SMS infrastructure for patching third-party and custom applications. SMS R2 is a welcome addition for the patch management administrator.
So now you have two tools at your disposal for handling software updates from sources other than Microsoft. The manageability and convenience that CUPT and ITCU provide will ensure that your custom updates go as smoothly as the Windows updates you’re already using.
Update Management Resource
  • TechNet: Update Management
  • Webcast: IT's Showtime - SMS 2003 R2
  • Ten Principles of Microsoft Patch Management

Steve Rachui is a Manageability Support Escalation Engineer in the Product Support Services group at Microsoft. He has supported SMS since version 1.2. Steve can be reached at steverac@microsoft.com.


 From the Editor: We May Be Wrong...
From The Editor
We May Be Wrong...

ONE OF THE MAJOR DIFFERENCES between print and the Web is that once something's in print, it's there forever. When you put some tidbit of information on the Web and need to update it later, you just go in and change what needs to be changed. No one's the wiser.
Print, of course, is a different animal. Once we send something to press, there's no turning back. More than one hundred thousand copies go out, and whatever we've put on the pages is what will be in your library until the end of time (or until the next moving day). Also, print gives you a natural progression from month to month, and you know that the newest issue will have the most current news and articles.
Now we also put the magazine online in its entirety after it's been published, and that creates a new problem. From the point of view of someone performing an online search, all content that's on our Web site is on at the same time. So how do you know whether you're looking at the most current guidance?
To solve this problem, a few years ago we formulated a corrections policy that uniquely enhances our print product with our ability to reach readers online. On the TechNet Magazine corrections page, you'll see full disclosure of every post-publication change we make to our articles. We mark one of five reasons for updating a piece: technical, editorial, new information, out-of-date, and security.
For instance, the article "Techniques for Simplifying Desktop Image Creation," which we published in May 2006, mentioned a tool called CNIC that wasn't yet available. When CNIC became available, we added an update to the Corrections page and an Editor's Update to the article posted online. Clicking on the Editor's Update link takes you right to the new information.
As you can see, although each print issue of TechNet Magazine is replaced by a new one every month, our corrections policy helps assure that articles stays relevant over time. -JOSHUA TRUPIN

Thank you to the following Microsoft technical experts: Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher, and Alan von Weltin.


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

File and Directory Synchronization
Allway Sync
allwaysync.com

No matter what kind of IT job you have, chances are you spend a lot of time moving files and directories from one place to another—whether from your desktop to a USB key or from server to server over the network. Often, it's important to keep those directories synchronized to ensure you aren't creating unnecessary duplicates and that you're working with the latest version of the files. Sometimes you may need to synchronize files and directories across many machines, as when deploying static XML or HTML files across a set of Web servers. Allway Sync from Usov Lab is a helpful tool for handling these kinds of tasks.
Allway Sync gives you true n-way synchronization, from single direction replication of files and directories to a multidirectory, bidirectional option. Not only does the application let you keep local drives and networked resources in sync, it also supports automatic synchronization to removable devices, such as USB keys and rewriteable optical drives. You can have Allway Sync start automatically when the device is connected to your machine.
Other automatic start-up options for syncing include starting when file changes are detected, when you log in or log out, when Allway Sync is started, and at specified time intervals. You can even tie syncing to a scheduled task via the app's GUI.
Synchronize files and folders with Allway Sync
Synchronize files and folders with Allway Sync
All file modifications and deletions are tracked in the application's local database and Allway Sync provides many options for versioning modified files and deleting conflicted files, including removing items permanently, moving them to the recycle bin, or moving them to a specified folder.
For each job, you can specify multiple inclusion or exclusion filters to get the files you need and ignore the ones you don't. You can customize the actions you'd like Allway Sync to take when it encounters warnings or errors, and configure a different action for each type of warning or error. For example, you can choose to automatically retry a copy in the event of error, and you can configure not only the number of automatic retries but even the time-delay between retries to accommodate any network latency or short-term connectivity issues.
You can configure the verbosity of the application's logging feature to ensure you receive maximum information about your jobs. Application settings can be imported and exported via XML, so it's easy to keep them backed up or to transfer them to another computer. And, a fun facility for the curious, the application also provides a simple usage statistics window (accessible via the Help menu). This handy tool can make syncing your files a snap, and it's quite a bargain to boot.
Price: Free for personal use. $29.99 for commercial use.

Map and Monitor Your Network
LANState Pro
10-strike.com/lanstate

Quick access to the status and availability of your network's resources is vital to a proactive IT operations environment. When a problem arises, you need to know about it before anyone else. The handy LANState Pro network mapper and monitor from 10-Strike Software can help with quick visualization and LAN management capabilities for Windows®-based networks.
When you launch the application to monitor on your network, you can choose the Network Mapping Wizard, which allows you to either scan your Network Neighborhood or an IP address range for applicable hosts. If you prefer, you can add in your hosts manually. Once your network map is created, LANState automatically begins the status checks you configured, such as a TCP port check or ICMP ping check. Responsive hosts are color-coded while unresponsive hosts are grayed out. You can then arrange your map into the logical groupings appropriate to your configuration and change any visual elements as well as add descriptions and the like.
Create logical network groupings with LANState Pro
Create logical network groupings with LANState Pro
The drawing and editing tools are a little rough, but once your map is complete, you can save it to a file and you won't have to recreate it. In addition to TCP port and ICMP ping checks, you can configure LANState Pro to check for the existence of a folder or file, the size of a file, or how much disk space is free on a remote host at a configurable interval and timeout. Right-clicking on a host brings up a context menu that allows you to glean more system information from the remote host, as well as perform a trace route, send a ping, do a default check, or send a network message.
The system information view shows you everything from NIC MAC addresses and bound IP addresses to network shares, services, and local accounts. Most of the OS-level information requires the appropriate permissions and open ports on the remote system, but you can get quite a bit of good data from the RPC calls. And, if you do have those permissions, you can also send remote power up and shutdown signals to the remote hosts.
Price: $249.95 for a single user license.

Command-Line Scripting
Book Review
www.syngress.com

Interactive wizards and configuration GUIs can really simplify complex tasks. But when you're an IT professional, these interfaces can slow you down and they don't always provide enough granularity or control for the task at hand. Fortunately, that level of control is almost always available via the command-line interface (CLI). Getting acquainted with the tools included with Windows and learning how to customize the command prompt to streamline administrative tasks can save time, increase efficiency, and give more precise control. Pawan K. Bhardwaj's How to Cheat at Windows System Administration Using Command Line Scripts (Syngress Publishing, 2006) can help you master the CLI and OS utilities.
This book takes you through customization of the command shell, using batch files for automation and batch processing and CLI administration of scheduled tasks. Once you master those sections, the book introduces the utilities included in the Windows OS that help you manage disks, files, and directories. You'll also get a nice overview of Directory Services commands, such as DSQuery and DSMod, which, in combination with the batch processing skills you picked up in the earlier chapters, can save a lot of time administering larger directory structures.
You also learn about the Windows Networking commands—from Netstat to Pathping—that are at your disposal, and you get an overview of the remote connection tools, such as TFTP, RSH, and RCP. Again, combining these tools with the skills you picked up in the first section of the book on automation and scheduled tasks, you can definitely increase your productivity. All in all, though it is not a comprehensive reference for Windows utilities, Bhardwaj's book is a useful addition to your reference shelf.
Price: $39.95 direct.

Hardware Reliability Testing
BurnInTest
passmark.com/products/bit.htm

Whether you are involved in the production of custom PCs, performing hardware component updates for your client base, or just building a new super-admin desktop rig, it's crucial to ensure that the new components will perform reliably before you deliver them to your users. BurnInTest from PassMark Software does just that, by running a number of different stress tests on components you specify to ensure they won't fail upon delivery.
As with all burn-in software tests, the application tries to "exercise" the hardware, putting strain on select system components in an effort to simulate a long activity cycle in a short amount of time. The idea is to uncover any under-the-surface errors before a system or device is put into service. BurnIn Test lets you test everything from CPUs and graphics card memory to hard drives and CD burners.
The application is very easy to use and configure, allowing you to change the duty cycles and preferences for each component unit test in a particular configuration. Once you've set up your test configuration, you can save your preferences for later use, speeding up the next iteration of testing you might need to do a few months down the line.
Each of the tests has a configurable duty cycle, so you can set a load value from 1 to 100 for each component being tested. For example, you can test CPU math operations at a 75 percent load while simultaneously testing a 90 percent load on system memory. You can also tell BurnInTest to stop after a set number of minutes or operational cycles.
The application lets you test up to 20 hard drives, floppy drives, and/or optical drives simultaneously, so you can batch test the drives before dispersing them out into your client environment. This can be a great time saver when upgrading a system component, since you can test each new component at once without having to test every system individually. I like that the program provides for SMART parameter checking.
The Professional Edition supports a variety of loopback tests for USB 2.0, parallel, and serial ports. (The hardware loopback devices are available for purchase from PassMark.) This version of BurnInTest can be run from CD or USB key drive, which adds to the credibility of the tests being performed by reducing the impact of the application on the system being tested.
Price: $49 Professional Edition; $24 Standard Edition.

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.


 SQL Q&amp;A: Rebuilding Indexes, Disk Queue Length, and More
SQL Q&A
Rebuilding Indexes, Disk Queue Length, and More
Edited by Nancy Michell

Q How are SQL Server indexes rebuilt? I need to know why DBCC DBREINDEX consumes all my disk space and why space is not freed when the command fails. My database size is 90GB and the largest table is 70GB.
When I run DBCC DBREINDEX, leaving 10 percent free space, it consumes all the available disk space and the command fails. While initially the database file is 90GB, when the DBCC command fails, the database file grows to 160GB and that extra 70GB is never freed; I have to manually shrink the database several times to reclaim it.
When the command does work, the size of the database file is also 160GB, but the space is automatically freed a few hours later by autoshrink. Would it be acceptable to do a defrag instead of a DBREINDEX to consume less space? I have no clustered indexes, and I'm using simple recovery mode.
A At the simplest level, indexes are rebuilt by constructing a new copy of the index and then deleting the old one. This means that essentially there are two copies of the index for a short period of time. Constructing the new index could require as much database file space as the original index, and if the rebuild requires a sort operation, then an additional 20 percent of the index size is required for the sort.
So the worst case is that rebuilding an index requires 1.2 times the space of the old index. If the database file does not have enough free space, then the file will have to grow as the operation proceeds. It's possible that if autogrow is not enabled or there is not enough space on the disk volume, then there may not be enough free space available and the rebuild operation will fail.
Whether the operation fails or not, the extra space allocated to the database file is not freed up after the rebuild operation completes. The assumption is that the space will be used for regular database operations.
Running shrink (either manually or automatically) is almost guaranteed to create index fragmentation due to the way the algorithm works. For more details, see SQL Server Storage Engine. Autoshrink can be particularly detrimental to performance if the database needs free space for regular operations because you can get into an autogrow-autoshrink-autogrow-autoshrink cycle that can wreak havoc on fragmentation and performance.
Using DBCC INDEXDEFRAG (or ALTER INDEX ... REORGANIZE in SQL Server™ 2005) has the advantage that it uses almost no additional database file space, but it can take longer and generate a lot more transaction logging than an index rebuild. DBCC INDEXDEFRAG is always fully logged, regardless of the recovery mode in use, whereas in simple recovery mode an index rebuild will be bulk-logged. There are a variety of pros and cons to each method and they are explained more fully in the SQL Server Index Defragmentation Best Practices whitepaper.
Before making the decision on how to fix fragmentation, first decide whether to fix fragmentation at all. Depending on the type of operations the index is used for, fragmentation may have no effect on performance and so fixing it is a waste of resources. The whitepaper has great detail.
Bottom line: make sure you choose the most appropriate method of fragmentation removal for your environment and that removing fragmentation is helping query performance.

Q I have configured database mirroring successfully between two SQL Server 2005 instances. My application is connecting to SQL Server using a SQL Server login and is built using ADO and the SQL native client. My connection string and connection settings specify the correct information, including the appropriate failover partner. I have also created all the same logins on the mirror server as exist on the principal server. Upon testing a database failure, the mirror successfully assumes the principal role and everything looks correct on the SQL Server instance. (I can even connect to the mirror using my Windows® login.) However, the application reconnection fails with the following error:
Cannot open database "<db name>" requested by the login. The login failed.
It appears that the login is not associated with a user in the new principal (originally the mirror) database. I run sp_change_users_login to synchronize the users and logins for the database, and I get a message saying it fixed multiple orphaned users. My application then reconnects successfully to the new principal server. I have tried multiple failovers, and each time I see the same behavior-the association between the login and user gets lost.
Is there a way to configure the mirroring setup so this is not a problem?
A Yes. The problem is due to the fact that the security identifiers (SIDs) for the SQL Server logins on each server do not match, even though the names for the logins are the same. This is not a problem with Windows/domain user/group logins because the SIDs for these logins are created based on the domain SID for the user/group, and hence will be the same for the same given user/group no matter which SQL Server the user/group is added to.
In order to make the sp_change_users_login synchronization step unnecessary, you'll need to create the SQL Server logins on the mirror server not only with the same name, but also with the same SID as on the principal server. You do this by using the SID specification in the CREATE LOGIN statement when creating the logins on the mirror server, as follows:
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
You can retrieve the SID for each login from the principal server by querying the sys.sql_logins catalog view. An example of a query that will generate an actual CREATE LOGIN statement for each SQL Server/Windows login on a given server is shown in Figure 1.
Figure 1 Generate CREATE LOGIN statement (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

Q What should my average disk queue length be? For example, if I have 20 separate physical spindles off of Storage Area Network (SAN) with RAID 01 configuration, how do I calculate average disk queue length? Is it Avg. Disk Queue Length/20 or Avg. Disk Queue Length/2?
A First of all, you should look at the disk latency before wasting any time on average disk queue length in a SAN environment. But it really does depend on what you are trying to figure out. You'll see why in a moment.
The explanation of this counter (from Perfmon) is "Avg. Disk Queue Length is the average number of both read and write requests that were queued for the selected disk during the sample interval." This is either a physical disk or logical disk counter, so the number that you get depends on how the underlying storage is presented to the operating system.
Let's look at your case. You have 20 spindles in a RAID 01 configuration, which means they are striped and mirrored (or mirrored and striped depending on how you read 01 or 10). The key point about your storage array is that there are 10 spindles in the stripe set.
But I'm missing essential information, such as what the stripe size is, how big your writes are, and what kind of I/O you're issuing (read, write, sequential, or random).
Ignoring the missing information for now, if the Avg. Disk Queue Length says 10, then the OS queued 10 I/Os to the disk array. Theoretically, that could be one I/O to each of the 10 mirrored sets in the stripe, or it could have been 10 I/Os all to the one disk. You have no way of knowing which it was.
This is where the missing information comes in. Let's assume your stripe size is 64KB, your write size is 8KB, and you're going to do a whole chunk of sequential writes. This is a typical scenario for SQL Server storage activity. In this case, there is a good chance that eight of the I/Os all went to the first disk, and the next two I/Os went to the next disk. So, if you're trying to work out the disk queue length per disk for this scenario, it is 8 for the first disk, 2 for the second disk, and 0 for the remaining eight disks in the array.
Now let's change the scenario to a theoretical stripe size of 8KB and a write block size of 64KB-and keep the disk queue length at 10. In this case, each 64KB block gets spread over 8 disks, so one I/O is written to 8 disks and the 10 queued I/Os are spread across 80 disk writes over all 10 disks in the array. If you're trying to calculate the disk queue length per disk in the array, it's going to be 8 for each disk in the array.
Let's be realistic and add another level of uncertainty into the picture. In most cases, your SAN storage is going to be connected to the server using one or more HBAs in the server, a number of fibers to connect the HBA to the SAN, a number of ports on the front end of the SAN, and perhaps some kind of fiber switch in the fabric between the server and the SAN. Then we get into the internal architecture of the buses inside the SAN, and how the disks are connected to the ports on the front of the SAN.
Any queuing you are seeing reported in Perfmon can be a symptom of high latency or queuing at any of these points between where the OS measures its disk queue length and the surface of the disks. This is why you should look at the latency and base any decisions on that counter rather than the average disk queue length.

Q I'm using transactional replication, and I know that many rows have been manually changed in a table at the subscriber, so I am getting errors when the publisher is trying to update a row that no longer exists in the subscriber.
I need to know if there is any way through replication to just re-initialize this one table from the publisher instead of reapplying a whole snapshot again. I looked into the tablediff function, which looks like it will do what I want, but I wonder how it interacts with replication.
For example, does tablediff take a snapshot-in-time of the publisher table and compare it with the subscription equivalent? Do I need to stop replication to use the tablediff utility to ensure the consistency of the data? What else do I need to know?
A First of all, tablediff does not take a literal snapshot of either the publishing or subscribing table. Regarding your particular scenario, there are a couple of options you could look at.
The first one would be to temporarily stop replication and run the utility. If you're worried about users attempting to make modifications to the data, you can use the -sourcelocked and -destinationlocked parameters, which will take out an exclusive lock on both tables while the utility is running. If this is unacceptable, another option would be to look at the -rc and -ri parameters while leaving replication running. This will run tablediff once and then run it consecutively on the errors it detects, eliminating errors which could be due to replication propagation delays. Be warned, however, that with this option, depending on your replication delay you may not necessarily catch all of the rows that have changed on the subscriber.

Thanks to the following Microsoft IT pros for their technical expertise: Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe, and Steven Wort.


 Utility Spotlight: Autoruns
Utility Spotlight
Autoruns
Lance Whitney
Download the code for this article: Autoruns (490KB)

The typical PC running Windows® loads an array of items at startup, including files, drivers, tasks, and services. At some point, it’s quite likely you’ll need to view and perhaps disable certain startup items—to troubleshoot a startup conflict, to track down malware in the autostart sequence, to reduce Windows launch time, or to free up memory and system resources.
The System Configuration Utility (msconfig.exe) lets you view and disable a number of startup files and services, but there are many it misses—toolbars, browser helper objects, Windows Explorer shell extensions. Furthermore, msconfig doesn’t share many details about these items. For a better way to view and manage everything that loads at startup, take a look at Autoruns from Sysinternals.
Autoruns, written by Mark Russinovich and Bryce Cogswell, is a free utility that unveils every startup item—also known as an image—on a Windows-based PC. You can view all images stored in the startup folders, the Registry, and other areas where they like to hide (see Figure 1).
Figure 1 Viewing startup items with Autoruns
Figure 1 Viewing startup items with Autoruns
Autoruns shows you the name and location of each image. For files it displays the directory path; for Registry entries you get the exact key. Autoruns also supplies the name of the publisher and a brief description based on the item’s version data. Double-clicking on an entry takes you to its directory or Registry key; right-clicking opens a popup menu with more options, including a Properties command that displays the standard File Properties window with full version information. An option to "Include Empty Locations" shows all of the PC’s startup areas, whether or not they currently have any entries. You can also select other user accounts on the PC to see their startup environments.
You can check on the digital signature of an entry through the Verify command, which queries Web sites with certificate revocation lists (CRLs) to determine if an image is digitally signed and whether the signature is valid. Another option to "Hide Signed Microsoft Entries" excludes entries already signed by Microsoft allowing you to focus on third-party images.
The entire list of startup items can be exported into a text file—handy if you want to disable any items and need a snapshot of your startup environment before you tweak it. You can then compare the exported text file with your revised startup configuration to see your changes.
Here are just a few of the startup categories Autoruns covers:
Logon includes the user and all users’ startup folders and the Run keys that are found in the Registry.
Explorer includes a list of Explorer shell extensions, toolbars, and active setup executions.
Internet Explorer includes Browser Helper Objects and Internet Explorer® toolbars and extensions.
LSA Providers includes Local Security Authority authentication, notification, and security packages.
In Autoruns, you can permanently delete a startup item or just disable it. An Online Search option helps you find which items you can safely disable. This option runs an Internet search for Web pages that describe an item or its category and advises you whether to remove it from startup. When you disable an item, Autoruns moves it to a backup location in the Registry or on the hard drive.
Autoruns works under all versions of Windows including Windows XP 64-bit Edition and Windows Server® 2003 64-bit Edition. Grab a copy from microsoft.com/technet/technetmag/code07.aspx.

Lance Whitney is an IT consultant, trainer, and technical writer. He has spent countless hours tweaking Windows workstations and servers. Originally a journalist, he took a blind leap into the IT world 15 years ago.


 The Cable Guy: Wireless Group Policy Settings for Windows Vista
The Cable Guy
Wireless Group Policy Settings for Windows Vista
Joseph Davies
This column includes prerelease information about Windows Server "Longhorn" that is subject to change.

As an administrator, your job would probably be a bit easier if you could centrally configure and distribute wireless network settings to all the computers in your Active Directory network. Fortunately, Windows supports a special Group Policy extension for Computer Configuration that lets you do just that. It’s
called the Wireless Network (IEEE 802.11) Policies extension, supported by computers running Windows Vista™, Windows® XP, Windows Server® 2003, and the next version of Windows Server, code-named "Longhorn."
Here’s how it works. Either when joining the domain, or when starting up (and on an ongoing basis after that), these operating systems automatically download the wireless settings in this Group Policy extension and apply them. You can configure wireless policies for a domain-based Group Policy object from the following node in the Group Policy Object Editor snap-in: Computer Configuration | Windows Settings | Security Settings | Wireless Network (IEEE 802.11) Policies.
Figure 1 shows the location of the Wireless Network (IEEE 802.11) Policies node for a Windows Server code-named "Longhorn" domain or for a Windows Server 2003 domain that has had its schema extended with the 802.11Schema.ldf and 802.3Schema.ldf schema extension files (described in microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Figure 1 Wireless Network (IEEE 802.11) Policies node
Figure 1 Wireless Network (IEEE 802.11) Policies node
By default, there are no Wireless Network (IEEE 802.11) Policies. To create a new policy, right-click Wireless Network (IEEE 802.11) Policies in the console tree and then click Create A New Windows XP Policy or click Create A New Windows Vista Policy. For each type of policy, you can only create a single policy, but each policy can contain settings for multiple wireless networks.
For the Windows XP policy, the policy settings are very similar to those described in my July 2003 column. However, there are new options for non-broadcast wireless networks, Wi-Fi Protected Access 2 (WPA2) authentication methods, and fast roaming settings for WPA2 authentication. To support these new settings, computers running Windows XP Service Pack 2 (SP2) must install the Wireless Client Update for Windows XP SP2 found at support.microsoft.com/kb/917021.
The Windows Vista wireless policy contains policy settings specific to Windows Vista and Windows Server "Longhorn" wireless clients. If both types of wireless policies are configured, Windows XP wireless clients will only use their own policy settings and the Windows Vista wireless clients will only use their own policy settings. If there are no Windows Vista policy settings, Windows Vista wireless clients will use the Windows XP settings. This article describes the settings that can be configured with the Windows Vista wireless policy.
On the General tab of a Windows Vista wireless network policy, you can configure a name and description for the policy, specify whether the WLAN AutoConfig service is enabled, and configure the list of wireless network profiles and their settings in preferred order (see Figure 2). You can also export a profile as an XML file by selecting the profile and clicking Export. To import an XML file as a wireless profile, click Import and specify the file’s location.
Figure 2 Wireless network policy properties
Figure 2 Wireless network policy properties
Figure 3 shows the Network Permissions tab for a Windows Vista wireless network policy with its default settings. This tab is new for Windows Vista and allows you to specify wireless networks by name and either allow or deny access to them. For example, you can create an Allow list containing wireless network names, also known as Service Set Identifiers (SSID), to which a Windows Vista wireless client is allowed to connect. This is useful for network administrators who want an organization’s laptop computers to connect to a specific set of wireless networks, which might include the organization’s wireless network and Internet service providers.
Figure 3 Network Permissions tab
Figure 3 Network Permissions tab
With a deny list, you can specify by name the set of wireless networks to which the wireless client is not allowed to connect. This is useful to prevent managed laptop computers from connecting to other wireless networks that are within range—for example, when an organization occupies a floor of a building and there are other wireless networks of other organizations on adjoining floors. You can also prevent managed laptop computers from connecting to known unsecured wireless networks using a deny list. To create either list or specify individual wireless networks to grant or deny access, click Add to add a wireless network by name and specify whether it is allowed or denied.
On the Network Permissions tab, there are also settings to prevent connections to either ad hoc or infrastructure-mode wireless networks. You can also allow users to view the wireless networks that have been configured as denied and enable any user to create an all-user profile. An all-user profile can be used to connect to a specific wireless network by any user with an account on the computer. If this setting is disabled, only users in the Network Administrators group or Network Operators group can create all-user wireless profiles on the computer.

Wireless Network Profile Properties
To manage a wireless network profile from the General tab of the Windows Vista wireless policy, either select an existing profile and click Edit or click Add and then specify whether the new wireless profile is for an ad hoc or infrastructure-mode wireless network.
To create a new wireless profile, begin on the Connection tab by naming the profile and creating a list of wireless network names to which it applies (see Figure 4). You can add new names by typing the name in Network Name(s) (SSID) and clicking Add. You can also specify whether the wireless client using this profile will automatically attempt to connect to the wireless networks named in the profile when in range (subject to the preference order of the list of wireless profiles on the General tab for the Windows Vista policy). Additionally, you can indicate whether to automatically disconnect from this wireless network if a more preferred wireless network comes within range, and indicate that the wireless networks in this profile are non-broadcast networks (also known as hidden networks).
Figure 4 Connection tab
Figure 4 Connection tab
From the Security tab, shown in Figure 5, you can configure the authentication and encryption methods for the wireless networks in the profile. The choice of encryption methods depends on your choice of authentication method. The choices for each are listed in Figure 6.
Figure 6 Security methods (Close Figure 6)

Authentication Methods
Open
Shared
Wi-Fi Protected Access (WPA)-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Open with 802.1X
Encryption Methods
Wired Equivalent Privacy (WEP)
Temporal Key Integrity Protocol (TKIP)
Advanced Encryption Standard (AES)
Figure 5 Security tab
Figure 5 Security tab
If you decide to select WPA-Enterprise, WPA2-Enterprise, or Open with 802.1X as the authentication method, you can also configure the network authentication method (the Extensible Authentication Protocol [EAP] type), the authentication mode (user re-authentication, computer authentication, user authentication, or guest authentication), the number of times authentication attempts can fail before authentication is abandoned, and whether to cache user information for subsequent connections. This last setting specifies that when the user logs off, the user credential data is removed from the registry. So, when the next user logs on, he will be prompted for his credentials (such as user name and password).
To configure advanced security settings for the WPA-Enterprise, WPA2-Enterprise, or Open with 802.1X authentication methods, click Advanced. Figure 7 shows the default Advanced security settings dialog box.
Figure 7 Advanced security settings dialog box
Figure 7 Advanced security settings dialog box
In the IEEE 802.1X section, you can specify the number of successive EAP over LAN (EAPOL)-Start messages that are sent out when no response to the initial EAPOL-Start messages is received, and the time interval between the retransmission of EAPOL-Start messages when no response to the previously sent EAPOL-Start message is received. You can also set the period for which the authenticating client will not perform any 802.1X authentication activity after it has received an authentication failure indication from the authenticator, and the interval for which the authenticating client will wait before retransmitting any 802.1X requests after end-to-end 802.1X authentication has been initiated.
Single sign-on (SSO) allows you to configure when 802.1X authentication occurs relative to the user logon and to integrate user logon and 802.1X authentication credentials on the Windows logon server. In the SSO section, there are settings to perform wireless authentication immediately before or after the user logon process and to specify the number of seconds of delay for connectivity before the process begins. You can also indicate whether to prompt the user for additional input fields if the authentication method requires the user to type additional credentials and how long to display those fields, and whether the wireless networks for this profile use a different virtual LAN (VLAN) for computer or user authentication.
In the Fast Roaming section, you can configure Pairwise Master Key (PMK) caching and preauthentication options. The Fast Roaming section only appears when you select WPA2-Enterprise as the authentication method. With PMK caching, wireless clients and wireless access points (APs) cache the results of 802.1X authentications. Therefore, access is much faster when a wireless client roams back to a wireless AP to which the client already authenticated. You can configure a maximum time to keep an entry in the PMK cache and the maximum number of entries. With preauthentication, a wireless client can perform an 802.1X authentication with other wireless APs in its range while it is still connected to its current wireless AP. If the wireless client roams to a wireless AP with which it has preauthenticated, access time is substantially decreased. You can configure the maximum number of times to attempt preauthentication with a wireless AP.
For more information about wireless support in Windows, see microsoft.com/wifi. For more information about Windows Group Policy, see the resources at microsoft.com/gp.

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: Filtering and Formatting Data
Windows PowerShell
Filtering and Formatting Data
Don Jones

There’s no question that Windows PowerShell can, without a lot of work on your part, return a great deal of valuable information. For example, consider the simple Get-WMIObject cmdlet, which can be used to return a list of services on the local computer. The default view, which lists the status, name, and startup mode of
the services running, is essentially a command-line view of the Services console. Windows PowerShell™ just makes it much easier to get to.
But there’s a lot more useful information available for services than just what is shown in the default view. Try running this command:
$s = get-wmiobject win32_service
$s[0] | gm
The first line of the command returns a collection of all services (or, more specifically, all instances of the Win32_Service class from Windows® Management Instrumentation, or WMI), storing them in the $s variable. The second line takes the first service in that collection (ordinal number zero, indicated in square brackets) and pipes it to the Get-Member cmdlet, which I’ve abbreviated using its alias, gm. The resulting output shows all the properties and methods available for that data type. I’ve decided to use the Win32_Service class in WMI, rather than the built-in Get-Service cmdlet in Windows PowerShell, because WMI actually exposes more information than the Microsoft® .NET ServiceController object, including the StartName property. That property tells me the name of the user account that the service is running under. You can check the name of a single instance, such as the first one, as follows:
PS C:\> $s[0].StartName
LocalSystem
However, referring to services by their ordinal number within the collection isn’t very useful since the services aren’t in any particular order. (They are usually listed alphabetically, but not always.) From a management perspective, you’ll probably be most interested in a list of all services and the account each is using to log in with. This would be handy for, say, a compliance audit. So let’s back up a second and look at what WMI is providing by default. I’ll use Get-WMIObject’s shorter alias, gwmi (see Figure 1).
Figure 1 Using gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
This is obviously just a sample, but you can see that the output isn’t really great for a management report. What I want to know is the name of the service and the StartName, which is the account the service is running under. I’d also like the report in a more readable format, rather than this somewhat awkward-looking list. That’s where the formidable formatting and data-filtering cmdlets of Windows PowerShell come into play.

Get the Data You Need
I’m going to start by filtering the data from Get-WMIObject so that the properties I’m interested in are being displayed. The best way to do this is to use the Windows PowerShell Select-Object cmdlet or its simple alias, select. Select is designed to accept a collection of objects—such as the collection returned by Get-WMIObject—and display just the desired properties of those objects. This means I can pipe the output of gwmi to select and specify the two properties I’m interested in. Figure 2 shows the results, which include the Name and StartName properties formatted nicely as a table.
Figure 2 Viewing just the Name and StartName properties in a table
Figure 2 Viewing just the Name and StartName properties in a table
If I were producing this report for a compliance audit, however, it really contains too much information. Some of the services are disabled, so it most likely wouldn’t matter to anyone reading the output what account the disabled services would theoretically use. Thus, I’d like to filter out all services that have a startup type of Disabled—that’s the StartMode property of the Win32_Service class.
Windows PowerShell performs object filtering using the Where-Object cmdlet or its shorter alias, where. The where cmdlet accepts a collection of input objects and runs each through a scriptblock to determine whether each object is going to be present in the cmdlet’s output based on a set of defined criteria. Each object that meets the criteria produces a True comparison and is included in the output; objects that produce a False value are not included.
So, I determined that I only want objects whose StartMode property equals Disabled. In Windows PowerShell terms, that evaluation looks like this:
$object.StartMode –eq “Disabled”
Of course, $object is just an example. I’m not actually writing a script and so I don’t have a variable named $object. Within the scriptblock used by where, however, I do have the use of a special variable named $_, which represents the object currently being evaluated by the cmdlet. So my where scriptblock might look like this:
$_.StartMode –eq “Disabled”
I can test that easily enough:
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
Of course, in this quick test, the output is back to appearing in the default list-style. And, to conserve space, I’ve only included one service here. But you’ll notice that this output is backwards. I’ve included disabled services, as opposed to excluding them. That’s because I’ve got my scriptblock backwards: I need to include all services where the StartMode is not equal to Disabled, as shown by this modification to my example:
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
That’s better! Now that the output contains only the services I’m really interested in, I can once again pipe the output to select and specify just the properties I want:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
This business of piping data from one cmdlet to another and to yet another really illustrates the capabilities of Windows PowerShell. I still haven’t written a script, yet I’ve managed to filter through a large data set to get just the output I’m looking for.

The Right Look
You should keep in mind that the output of select is still a bunch of objects. When I retrieve a nicely formatted table using Windows PowerShell, that’s really the PowerShell.exe rendition of those objects. In other words, Windows PowerShell knows that I, as a mere human, can’t see the objects, so it renders the objects as text. In this case, it rendered the objects as a table, with a column for each property, as illustrated in Figure 2.
This might be sufficient for my auditing purposes. But then again, it might not. Everyone has different needs and Windows PowerShell doesn’t presume to know what your specific needs are. Instead, it gives you the tools to format the output in whatever way works best for you. Four built-in cmdlets—Format-List, Format-Custom, Format-Table, and Format-Wide—are designed to accept a collection of objects (such as the collection returned by select) and format those objects in various ways. Format-Table is basically what Windows PowerShell is already using to format the output of my select cmdlet. For a different look, let’s try Format-List:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
The result looks a bit like this sample:
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
The Format-Wide cmdlet is designed to produce a multi-column list of, by default, the first property from each object. Take this line, for example:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
It produces a list of service names, which isn’t what I want. The output is missing the StartName (see Figure 3), which is an important piece of information I need in my auditing report.
Figure 3 Output displayed using the Format-Wide cmdlet omits key information--the StartName
Figure 3 Output displayed using the Format-Wide cmdlet omits key information--the StartName
Since I’m only dealing with two properties, it’s likely that either Format-Table or Format-List would be acceptable. But it’s unlikely that an auditor would be happy looking at this information on the screen. She would probably prefer a file of some kind.

Exporting Data
So how might an auditor want to view the data? Outputting the list of services and login names to a CSV (comma-separated values) file might be sufficient since the file can then be easily opened in Microsoft Excel®. To create a CSV file, simply pipe your output to the Windows PowerShell Export-CSV cmdlet:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
Of course, in today’s world, CSV seems a bit outdated. Perhaps your auditors would prefer the data to be displayed as a Web page on an intranet server. To do this, start by converting the output to HTML, using the ConvertTo-HTML cmdlet:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
Raw HTML is hard to view, so you’ll need to write the output to a file:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
The result, shown in Figure 4, is a well-formatted HTML page that can be posted on any Web server without further modification.
Figure 4 Output displayed as a well-formatted HTML page
Figure 4 Output displayed as a well-formatted HTML page

Just the (Relevant) Facts
Windows PowerShell provides you with quick access to a broad range of management data. However, that data in its raw state isn’t always useful in a business sense.
By filtering the data (using where), choosing the desired object properties (using select), and applying an appropriate formatting option (such as Format-Table or Format-List), you can quickly turn this management data into useful information with very little effort. And then, by exporting the data to a file format that can be easily shared, you can take this information beyond your own desktop and communicate valuable information to other people in your organization.

Don Jones is the Director of Projects and Services for SAPIEN Technologies, and coauthor of Windows PowerShell: TFM (SAPIEN Press). Contact Don through his Web site at www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Naively Taking on Local Users and Groups
Hey, Scripting Guy!
Naively Taking on Local Users and Groups
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2007_04.exe (151KB)

How can I manage security descriptors on files and folders?

Believe it or not, there was a time—long ago, of course—when the Scripting Guys really weren’t all that smart. We know that’s hard to believe, but—what do you mean it’s not that hard to believe? And what do you mean it couldn’t have been that long ago? Why, we’ll have you know that—oh, OK. Obviously you saw one of the Scripting Guys authors trying to hook up a new TV the other day.
In his defense, though, this particular Scripting Guy would argue that hooking up a new TV isn’t rocket science; actually it’s way more complicated than rocket science. Just hooking up the TV itself involves three video cables and a pair of audio cables; on top of that you then have to throw in a VCR, a DVD player, and an Xbox®, not to mention punching random sets of numbers into the "universal" remote to try and get it to recognize all those devices. Compared to that, placing a satellite in orbit around the planet Mars is a piece of cake.
Remarkably, the Scripting Guy actually managed to get all of those connections exactly right. However, when he turned everything on nothing happened. Dutifully, he double- and triple-checked each connection. He read through all the user manuals, and even checked online to see if there might be some information he was missing. Nothing. He was just about to sacrifice an MP3 player to the electronics god when he noticed that he hadn’t taken the key step of plugging in the cable leading from the cable box to the cable outlet in the wall.
Note: You might be thinking that if it’s this hard to connect all the Scripting Family’s stuff then maybe the Scripting Family has too much stuff. Actually, this Scripting Guy would agree with that. However, any time the family votes on acquiring even more stuff this Scripting Guy is outvoted 2-0. And no, that shouldn’t read 2-1; it’s 2-0. For some reason, the Scripting Dad’s vote never seems to count in family elections, and there’s no paper trail.
In answer to your next question, yes, he has tried. But so far the United Nations has refused to send election monitors to the Scripting House.
Of course, now that we think about it, it wasn’t so much that the Scripting Guys (well, the one with the new TV in particular) were dumb as they were naïve. For example, when they were planning the Microsoft® Windows® 2000 Scripting Guide, they solicited help from a number of...experts...when it came time to hammer out the book’s chapters. One of the chapters that did not make the cut was a chapter on managing local users and groups. "Managing local users and groups?!?" said the experts. "Why is that even being considered? Who cares about managing local users and groups?"
Well, much to our chagrin we have since discovered that everybody (with the possible exception of our in-house "experts") cares about local users and groups. Each week we get tons of e-mail from people asking how to do things like add a user to a local group, delete a user from a local group, or change the local Administrator password on a computer.
Granted, the Script Center Script Repository does have some sample scripts that show you how to perform these tasks, but most of these scripts work on just one computer at a time. That’s not good enough: people want to know how to do this on multiple machines, and all at the same time. Change the local Administrator password on one lousy computer? Get in touch with the real world, Scripting Guys—we want to do that on all our computers, or on all the computers in an OU, or on all our mail servers, or—well, you get the idea.
Considering the fact that the Scripting Guide was published in 2003, that means we’ve spent nearly four years being besieged by these same e-mail messages. "Here’s another reader asking how they can read computer names from an Excel® spreadsheet and then change the local Administrator password on each of those computers," one of the Scripting Guys recently remarked. "What in the world can we do about that?"
Well, it took us four years, but we finally figured it out. Figure 1 shows exactly what we can do about that.
Figure 1 We finally figured it out (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Note: As you can see, it didn’t take us four years to write this script because it was hard; it took us four years to write this script because it takes us that long to do pretty much anything. That’s why you never want to miss the Scripting Guys annual New Year’s Eve parties; after all, you never know when, or if, the next annual event will come along.
What we’ve got here is a script that pulls computer names from a spreadsheet and then changes the local Administrator password on each of those machines. To perform this magic, we start off easy, by assuming that you have a very simple little spreadsheet, one that looks something like Figure 2. (If not, create one right now.)
Figure 2 Obligatory list of computers
Figure 2 Obligatory list of computers
As you can see, there’s nothing special here. In column 1 (column A), we list the names of all the computers that have passwords we need to change. In column 2 (column B), we simply keep track of the date and time that the Administrator password on each computer was last changed. That makes it easy for you to keep tabs on whether your Administrator passwords are all in sync.
As for the script itself, we kick things off with the On Error Resume Next statement. Usually we don’t bother including error handling in our scripts. That isn’t because we’re opposed to error handling; rather, it’s because we try to keep our scripts as short and easy to follow as possible. In this case, however, the On Error Resume Next statement is crucial. After all, our script is going to try to connect to scores of different computers. What happens if one of those computers is turned off? Well, with error handling, nothing will happen. Sure, an error will occur, but the script will be able to shrug it off and continue on. Without error handling you’ll get pretty much the same thing the Scripting Guy got when he turned on the new TV for the first time: nothing.
Next up, we use the following block of code to create an instance of the Excel.Application object, make that instance of Excel visible onscreen, and open the spreadsheet C:\Scripts\Test.xls:
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
And then last, but surely not least, we assign the value 2 to a counter variable named i. We’ll use this variable to keep track of our current row in the spreadsheet.
Note: So then why is i assigned the value 2? That’s easy: if you look closely at the spreadsheet you’ll see that our data actually begins in row 2. Row 1 is just a header row.
See? We might not be that good at connecting YPbPr1 cables, but we do know something about scripting.
Well, sometimes, anyway.
Now we’re ready to get to work. First of all, we set up a Do Until loop that runs until we encounter an empty cell in column 1. And yes, that means that, no matter what else you do, you can’t leave any blank rows in column 1. If your script encounters a blank row, it will assume that it has reached the end of the data so the loop (and the script) will end. And while there are ways to work around that, it’s a lot simpler just to avoid having blank rows anywhere in your spreadsheet.
Inside the loop, we begin by assigning the value found in cell row i, column 1 to a variable named strComputer. (Remember, the first time through the loop i is equal to 2; thus we’ll be working with the value in cell row 2, column 1.) We then use this line of code to create an object reference (objUser) to the local Administrator account on the computer represented by the variable strComputer:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If anything is going to go wrong with this script, it’s going to blow up right here. For example, suppose we’re having network problems, suppose the computer has been turned off, or suppose one of the Scripting Guys has hooked up his DVD player wrong and blacked-out the entire western United States. If any of those things happen, we’re not going to be able to make a connection to the computer. That’s why we immediately check the value of the VBScript Err object:
If Err = 0 Then
If the Err object is equal to 0, that means that we were able to connect to the computer (and to the Administrator account) without any problem. If Err is equal to anything other than 0, that can mean only one thing: our connection attempt failed. In that case, we won’t even bother to try to change the password on that computer; needless to say, if we can’t make the connection, we’re not going to be able to change the password.
Assuming all goes well and that no error occurs, we then execute the following two lines of code:
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
In line 1, we use the SetPassword method to assign a new password (egTY634!alK2) to the local Administrator’s account. (And yes, we know: you’re not supposed to use your child’s name as a password.) In line 2, we then write the current date and time (using the VBScript Now function) to cell row i, column 2. Notice that we update the Password Changed column only if we’re actually able to connect to the remote computer and change the password. If we can’t connect to a computer then its corresponding Password Changed field will never get updated; that’s how we can tell which operations were successful and which ones weren’t.
What does all that mean? That means that, the first time through the loop, our spreadsheet will look something like Figure 3.
Figure 3 List of computers after resetting the first password
Figure 3 List of computers after resetting the first password
So much for computer 1. Now we just need to do a little housekeeping before we move on:
Err.Clear
i = i + 1
Short as they might be, both these lines of code are very important. (As if the Scripting Guys would write any lines of code that weren’t very important!) The first line resets the Err object to 0. If no error occurred, that’s redundant; after all, in that case Err will already be 0. If an error did take place, however, then Err will be equal to a value other than 0. In that case, it’s crucial that we manually reset the Err object. Why? Because this is the Error object: it only keeps track of errors, it doesn’t keep track of successes. For example, let’s assume a problem occurred with computer 1 and we were unable to make a connection. For the sake of argument, let’s say that caused the Error object to be set to 99.
Now, let’s further assume that we loop around and successfully connect to computer 2. What do you think the value of Err will be now? That’s right: like it or not, Err will still be set to 99. That’s because the Err object value gets changed only when an error occurs; if no error occurs, however, then the Err object will maintain its current value indefinitely.
Does that really matter to us? Well, it should. After all, technically we don’t change the password on a computer if we make a successful connection; instead, we change the password only if Err is equal to 0. And—hold on a second while we bring up Calculator—yes, we were right: 99 is not equal to 0 (except, of course, in Scripting Family elections, when 99 Scripting Dad votes do add up to 0). And that matters to us because, even though we made the connection to computer 2, Err is not equal to 0. And because Err is not equal to 0, we don’t even try to change the local Administrator password.
In other words, if the value of Err ever changes, you’ll need to reset that value to 0; otherwise from then on your script will believe that an error has occurred. And how do you reset the Err object back to 0? You got it: just call Err.Clear.
Next we increment the value of i by 1. Why? Well, the first time through the loop the variable i was equal to 2; that’s because we wanted to connect to the computer listed in row 2, column 1. The second time through the loop we want to connect to the computer listed in row 3, column 1. Seeing as how i is the variable that indicates the row we want to work with we thus need to make i equal to 3. And, as everyone knows, 2 + 1 = 3. (Good thing we still had Calculator running, isn’t it?) Only then do we loop around and repeat the process with the next computer in the spreadsheet.
Now, that’s pretty cool, but—seeing as how we’re no longer as naïve as we used to be—we’re well aware that this script, by itself, will barely put a dent in the e-mail we’ll get. "That Excel thing was nice," people will say, "but I still need to change the local Administrator password for all the computers in an OU, or for all the computers listed in a text file. Or maybe I’d like to pop-up a list of computers and be able to select one from a listbox. Or maybe what I’d really like to do is ..."
Relax. Your wish is the Scripting Guys’ command. (Assuming you’re willing to wait four years for that wish to come true, that is.) As it turns out, we have scores of multiple computer templates posted on the Script Center, templates that make it extremely easy to run a script against multiple machines. For example, suppose you do want to change the local Administrator password for all the computers in an OU. Hey, no problem. The template for running a script against all the computers in an OU looks like Figure 4.
Figure 4 Running a script against an OU (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
See the section in the template labeled "Insert your code here"? All you need to do is delete the sample code found in that section and replace it with the code (which you can copy from this column) for changing the local Administrator password. In other words, replace the sample code with the following code:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
This particular example won’t log the results for you, but you can easily add that code in yourself. Replace the sample code, change the connection string LDAP://OU=Finance,dc=fabrikam,dc=com to point to one of your OUs, and you’re in business.
To tell you the truth, we actually posted these templates over a year ago, figuring that they would be one of the most popular items we ever put up in the Script Center. We were wrong about that: they hardly ever get used, even though people write to us pretty much every day asking how to run scripts against multiple machines. We’re assuming that no one knew that these templates existed. But now you know. Or at least you’ll know if we tell you where to find them: microsoft.com/technet/scriptcenter/scripts/templates. Hmmm, maybe that’s why no one ever used these templates...
So now that the Scripting Guys aren’t as naive as they used to be, does that also mean that they aren’t as dumb and as klutzy as they used to be? Let’s put it this way: not too long ago one of the Scripting Guys decided to spend the weekend fixing up a few things around the house. When he came back to work on Monday, he had both a smashed thumb that wouldn’t stop bleeding and a big gash in his leg.
Which, come to think of it, really wasn’t all that bad. At least not for a Scripting Guy.

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: The Security Configuration Wizard
Security Watch
The Security Configuration Wizard
John Morello
This column includes prerelease information about Windows Server "Longhorn" that is subject to change.

Securing servers efficiently and consistently is a challenge for many IT organizations, particularly those with large numbers of machines dispersed over numerous geographic and organizational boundaries. While hardening a single server can be a relatively straightforward task for a skilled administrator, hardening tens, hundreds, or
even thousands of servers is a far different proposition. Over the years, many organizations have come up with their own internal checklists or standards for server security or incorporated such guidance provided by Microsoft, the National Institute of Standards and Technology, or other external parties. Though this documentation can be tremendously valuable, documentation alone isn’t enough to enable organizations to really put these best practices into action on their networks. Thus, many have opted to either stay with default installation settings or to invest significant time and effort to create their own scripts or policies for hardening systems.
With the advent of the Security Configuration Wizard (SCW) in Windows Server® 2003 Service Pack 1 (SP1), Microsoft now provides a straightforward and supported method for hardening servers and reducing their attack surface based on the roles they perform. By combining the benefits of the SCW with the centralized deployment and management capabilities of Group Policy, the SCW can be scaled to the largest IT enterprises. In this month’s column, I’ll provide an overview of how IT organizations can use the SCW and Group Policy to manage their servers in a more secure and consistent manner, while lowering deployment and operational costs.

What is the SCW?
The SCW is an optional component, installed through the Add/Remove Windows® Components control panel, available on all members of the Windows Server 2003 SP1 family, including Windows Server 2003 R2. An administrator would start by running the SCW against a target server to identify the roles that server fulfills. The SCW then assists the administrator in creating a security policy that hardens the machine using a least-privilege scheme. In other words, the SCW helps to ensure that only those services, application capabilities, and ports required for the roles to function are available; anything not specifically needed by the roles the server holds will be disabled. This approach helps to reduce the attack surface of the target server. If you run services that are not required for the role the server performs, you increase the net risk to the server without any gain in capability or functionality. Disabling these services lowers the risk and may also improve server performance.
While Microsoft made many security advances with Windows Server 2003, greatly reducing its overall attack surface compared to previous versions of Windows Server, it is not built on the same highly componentized core that Windows Vista™ and the forthcoming version of Windows Server code-named "Longhorn" are. Thus, on a default installation of Windows Server 2003, there can be services enabled and running that are not needed for all server role configurations. For example, the Print Spooler service is enabled by default but is not required for a machine that’s only acting as a database server.

Making Role-Based Security a Reality
Over the past several years, Microsoft has released a wealth of security-focused documentation that helps administrators understand what services are required in different server roles and provides pre-built templates for well known roles like Web servers. However, guidelines like those in the Windows Server 2003 Security Guide can be challenging to implement in large environments, particularly when the applications used in those environments are often more complex than basic IIS or SQL Server installations. Further complicating the matter are myriad third-party applications that enterprises employ, many of which have dependencies on multiple server roles and whose application and service requirements are not always well defined.
SCW addresses these issues by encapsulating all the dependency knowledge and best practices contained in the guides into an administrator- driven wizard. For example, if an administrator is deploying a new line-of-business (LOB) application that requires both SQL Server™ and IIS, he no longer needs to invest significant time combing through the security guide and developing his own list of custom dependencies. Instead, he can install the application on the server and launch the SCW. The SCW will detect what services are currently running, and present the administrator with a list of roles to choose for the server. Depending on his selection, SCW will generate a policy that will disable all services not required by the dependency matrix for the roles. SCW will also provide options for hardening the registry, blocking unneeded network communications, and applying an effective audit policy. After running SCW, the administrator can save the SCW policy as an XML file and apply it to any other servers running the same LOB application.
Running SCW thus provides three powerful advantages over traditional, more manual approaches to securing Windows Server. First, it greatly reduces (if not eliminates) the need for an administrator to constantly consult product documentation to determine the services and settings required for a given workload. This knowledge is built into SCW, and the question-driven interface makes it easy for the administrator to supply needed details. Next, the SCW consolidates guidance for a number of areas, including service hardening, reducing network attack surface, hardening of LDAP and SMB services, and locking down IIS. Previously, performing these configuration tasks required separate utilities, each with its own interface and approach. Finally, because the SCW outputs its settings into an XML policy file, it can be used in "create once, apply many" scenarios. Whether you’re deploying 1 or 100 servers to support a particular LOB application, the same SCW policy can easily be applied to all of them. This makes security settings more consistent and lowers operational costs. It also makes rolling back SCW policies simple.

SCW Components
For all its capabilities and benefits, the SCW is actually a fairly simple tool that consists of three primary parts: the wizard interface, the command-line interface, and the Security Configuration Database (SCD). Administrators in small or medium enterprises may only need to interact with the wizard interface. In larger or more complex environments, administrators can use the command-line interface to assist in automating SCW tasks such as transforming an SCW policy into a Group Policy Object (GPO). Typically, only advanced administrators who wish to create their own custom SCW roles will modify the SCD.
The wizard interface, shown in Figure 1, allows administrators to create, edit, apply, and roll back security settings to a target server. It presents choices to administrators in a consistent work flow that first examines services and settings, then network connectivity, then security audit policies, and finally IIS settings.
Figure 1 SCW interface
Figure 1 SCW interface
The SCW command-line interface provides three basic functions. It allows administrators to analyze and configure multiple servers (either local or remote), and to roll back policies. It can be used to automatically convert an XML-based SCW policy into a GPO that can be natively used in standard GPO management tools like the Group Policy Management Console. Finally, the SCW command-line tool shown in Figure 2 is used to register any new Security Configuration Database extensions.
Figure 2 SCW command-line tool
Figure 2 SCW command-line tool
The SCD is simply a collection of XML files that detail the particular services and settings required for each SCW role. These files are located in %windir%\security\msscw\kbs. By default, the SCW ships with a number of core Windows Server roles, as well as 12 predefined application roles including: BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server, and Systems Management Server. Each role has its own XML file (see Figure 3). Any time a new role definition is created, its corresponding XML file will be placed into this directory. The files are standard XML and can be read in any text viewer or other application that supports XML (see Figure 4).
Figure 3 Predefined roles
Figure 3 Predefined roles
Figure 4 Role configuration file
Figure 4 Role configuration file

Combining the SCW and Group Policy
By itself, the SCW is a great tool, but its true power isn’t fully revealed until it’s combined with Group Policy. Since the release of Windows® 2000, Microsoft recommendations for securing Windows servers have been focused on using Group Policy to provide consistent, persistent, centrally managed policy application. By grouping servers into Organizational Units (OUs) based on their roles, administrators are able to deploy standard security configurations throughout the enterprise rather than at the individual machine level. By building upon the standard Group Policy accumulation and application logic, organizations can design a tiered server role hierarchy where a handful of master policies can secure hundreds or thousands of individual servers. When unique server roles demand variation from the master policies, smaller role-focused delta policies can be created more "closely" in the OU hierarchy to the servers themselves. This allows small changes to be made to enable role-specific functionality without having to duplicate the master policy in its entirety, an approach that gives large enterprises the benefits of a centrally managed policy along with the flexibility to adapt to specific applications when required.
The real challenge to this approach is in making it a reality. For large organizations with many different applications and server roles, creating the right set of policies is difficult and time consuming—or it was before the SCW. By using the SCW to generate policies and then attaching those policies to the right OU, you can greatly decrease the time it takes to deploy directory-hosted, role-based security, both for existing workloads and any you may adopt later on. To better illustrate how an organization might make this work, let’s walk through a large enterprise implementation of SCW and role-based GPOs.

SCW in the Enterprise
For this example, I’ll use the fictional Contoso network. Contoso has a large, complex, and geographically dispersed IT enterprise. Hoping to reduce its operational costs and increase the security of its servers, Contoso follows Microsoft guidance for creating a role-based OU hierarchy that separates and organizes servers based on workload. To create the policies to attach to these OUs, Contoso uses the SCW.
Because the SCW is not installed by default, Contoso needs to specifically enable the SCW component in its unattended installation image. To do so, it adds a new line, SCW=On, to the [Components] section of Unattend.txt. Thereafter, all new systems built with this image will have the SCW component installed during setup. Note that simply configuring SCW to be installed does not apply any policies to machines as they’re being built.
To apply a default policy during the setup process, Contoso edits the [Commands] section of the cmdlines.txt file in the image to call scwcmd with the following options:
scwcmd configure /p:ContosoBaselinePolicy.xml
Both the text file and the XML file must be in the $OEM$ directory of the image. Why would Contoso apply a baseline policy at build time rather than simply relying on the one attached to the top-level OU in the directory? By applying a policy at build time, Contoso is able to ensure a consistent baseline regardless of whether a machine is joined to Active Directory®. For example, if a server is built for testing purposes, applying the baseline policy during the build process ensures that it at least follows the organization’s standard security policy, even if it’s never joined to the production Active Directory. If the server is later joined to Active Directory, the Group Policy application and precedence algorithm will override the local settings with those from the Domain or OU level (remember that the order of precedence for policy application is Local, Site, Domain, OU).
Once the SCW has been installed, Contoso can begin creating its baseline policy. The baseline policy should be the one deployed at the top level of the role-based security OU hierarchy and will typically be the most restrictive policy in the hierarchy. The idea is to have as secure a default as possible, then to open up only those services and ports for individual workloads as required by those server roles. To that end, the baseline policy should be created by taking a plain, newly built server and adding the standard Contoso stack of management tools and utilities, then running SCW against it. For example, after the basic Windows installation is complete, Contoso installs (either manually or through the cmdlines.txt file) its standard antivirus, backup, management, and monitoring tools on the server. Because each of these tools likely creates its own Windows services, having them on the server prior to creating the baseline policy allows SCW to be aware of them during the service-lockdown phase.
Once the server is built, Contoso runs the SCW against it. The SCW can be run either locally or remotely, and whoever is running it must be a member of the local administrators group on the machine. If SCW is being run remotely, it provides an option to specify the user account to run under on the remote host; if it’s being run locally, you can use runas.exe to accomplish the same thing. The first task SCW undertakes is to evaluate those services running on the local machine and to display which roles are currently installed (see Figure 5).
Figure 5 Select and view server roles
Figure 5 Select and view server roles
No roles should be selected on Contoso’s baseline server since the machine is designed to be in a highly restricted state. After the roles the server performs are selected, the next step is to identify the required client features in order to enable functionality such as Automatic updates, Active Directory, or the FTP client. For most organizations, accepting the SCW default (as illustrated in Figure 6) provides important functionality (such as the ability to join a domain), while prohibiting less critical features (like the FTP client).
Figure 6 Installed features
Figure 6 Installed features
The SCW then continues, letting you choose which specific administrative tools and non-default services to allow. Those non-default services options are why you should run the SCW after installing the standard Contoso server management stack. When the antivirus, backup, and related applications are installed, SCW will then be able to have knowledge of these services and therefore include them in its resulting policy settings.
The last question in the service hardening section asks how to handle unspecified services. These are services that may be encountered on other computers on which the SCW policy is applied, even though they’re not running on the machine on which the policy was originally created. For example, if the baseline policy is applied to a new server with some new third-party application, any services installed by that application are handled according to the choice the administrator makes here. SCW allows the administrator to either not change the startup mode of the service or to disable it. Disabled is the more secure option, but it should be used with care since any services that are not explicitly allowed to run will be prevented from running. For this reason, this option is most suitable for high-security, well-managed environments. For other parts of an organization, choosing not to change the startup mode is recommended. Thus, in the Contoso example, that’s the option chosen. Before completing the service hardening portion of its tasks, SCW presents the administrator with a report on which services will be altered.
After completing service hardening, the SCW provides options for limiting inbound network access. As with the list of services required for a given role, the list of ports required for a given workload is included in the SCW’s XML database.
Administrators can configure additional ports as needed and also make per-service port rules, as shown in Figure 7. For the Contoso baseline server, only the most basic services, such as Remote Desktop, should be allowed. All other exceptions will be configured in the role-based policies lower in the OU hierarchy.
Figure 7 View and allow ports
Figure 7 View and allow ports
The SCW then allows the administrator to select registry options such as signing file and print traffic. Again, in the baseline configuration, choosing the most secure defaults is recommended as a best practice.
The next set of choices involves the system audit policy. On most systems, selecting the Audit successful activities option is best; auditing all activities is more processor-intensive and generates a significant amount of data in the audit log. When an attack is suspected or more detailed analysis needed, failure auditing can be enabled on the specific machine.
Finally, SCW will present the administrator with options for hardening IIS. These options are similar to those available in the IIS Lockdown tool and are now integrated directly into the SCW policy.
After all the steps are completed, SCW prompts the administrator to save the XML file. The saved file must then be converted into a format that is understood natively by Group Policy. Scwcmd.exe is used to transform the saved XML file into a GPO. Here’s the command to enter:
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
This policy is automatically created in Active Directory and can be attached to the top of the Contoso role-based hardening OU hierarchy.
Once this policy is applied to the top level of the hierarchy, any machines added to the OU hierarchy will inherit its settings. When a machine is added that requires modifications to this policy (such as an IIS server that requires the W3SVC service to be running), Contoso administrators will rerun the SCW for that new server role, transform this new policy into a GPO, and attach that GPO to a new sub-OU containing the server(s). Because the GPO closest to the server will take precedence, the end result will be that all of the baseline settings will be in place, except those that require modification to enable the desired role functionality for that OU (see Figure 8).
Figure 8 Policy application at Contoso
Figure 8 Policy application at Contoso
The real power of this approach becomes clear in larger organizations or when many servers are being deployed. Once the initial SCW policy is created and attached to an OU, subsequent servers simply need to be added to that OU and they automatically inherit the proper security policy. Thus, once the initial set of policies is created and added to Active Directory, deploying new servers or replacing existing ones becomes a simple and fast process.

Looking Ahead
In the next release of Windows Server "Longhorn," Microsoft has greatly componentized the operating system, resulting in a streamlined and limited attack surface out of the box. Rather than focusing on locking down the minimal default installation, administrators will instead use the Server Manager tool to add those roles and workloads required on each server. Server Manager works much like the SCW in that it has an internal database of dependencies that allows the installer to add only those pieces of functionality required to provide the desired role service. Moreover, centrally managed role-based security using Group Policy as discussed in this article is further enhanced by the greatly expanded set of GPO-controlled features. In short, Windows Server "Longhorn" takes the SCW concept to the next level with increased flexibility and an even stronger security posture right out of the box.
SCW Resources
The following Web pages will help you get started using SCW:
  • Security Configuration Wizard Documentation
  • Security Configuration Wizard for Windows Server 2003
  • Windows Server "Longhorn"

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


 The Desktop Files: When I’m x64
The Desktop Files
When I’m x64
Wes Miller

Windows XP has been available natively for 64-bit architectures for over five years. But unless you were one of the early adopters of the Intel Itanium processor (Windows XP for the Itanium shipped the same day as Windows XP), you’ve probably been hearing about it more recently with the availability of Windows XP and Windows
Server 2003 versions for x64 systems. x64—also referred to in the industry as x86-64—is the generic name for AMD’s AMD64 architecture and Intel’s EM64T. And if you’ve bought a new PC within the last year or so, there’s a good chance it’s 64-bit capable, even if it’s currently living a 32-bit life (as most likely are).
Today I work for a small startup in Austin, Texas. Because of the architecture of one of our products, we are interested in taking advantage of some very specific benefits in the x64 architecture—much like the Microsoft® Exchange 2007 team, which put a stake in the ground and has begun shipping solely for the x64 architecture. Similarly, the development and test team that I manage is solely deployed on x64 versions of Windows® XP and Windows Server® 2003 for development workstations, laptops, servers, and production servers. Furthermore, I run Windows XP Professional x64 Edition on my personal laptop in order to test and debug our product.
Interestingly, the first response I get from most people when I mention running 64-bit Windows—especially on a mobile system—is a rather confused look. And if they’re familiar with 64-bit computing, it’s something like disbelief meets nausea meets amazement—due to the commonly held assumption that it’s difficult to round up device drivers for 64-bit systems. In this month’s column, I’ll explain how and why I use Windows XP and Windows Server 2003 on x64 systems in 64-bit mode, and I describe some of the deployment benefits (and hurdles) you can expect to run into. I also go into aspects of Windows Vista™ x64 support, migration, and deployment.

A Bit of History
As I noted earlier, the origin of 64-bit support in Windows really begins with support for the Intel Itanium processor. (Though Windows was available for the 64-bit Alpha processor, Windows was never actually 64-bit when running on the Alpha.) There is no support for Itanium in Windows XP and Windows Vista, so the x64 architecture currently carries the torch for 64-bit Windows client computing. A larger selection of Windows Server 2003 editions are currently available for x64 than Itanium (which has essentially been relegated to ultrahigh-end datacenter workloads)—a trend I expect to continue with the next version of Windows Server, code-named "Longhorn," when it ships.
Support for Windows on the x64 platform became available when Windows Server 2003 Service Pack 1 (SP1) shipped. Though it’s somewhat confusing, this is also when the x64 version of Windows XP became available—meaning that Windows XP 32-bit products and 64-bit products derived from different code trees within Windows. While 32-bit products currently have a second service pack available for them, the 64-bit version of Windows XP technically has no service pack level at all (or you could think of it as having SP1 for Windows Server 2003 slipstream integrated into it already).
In order to run 64-bit Windows—Windows XP, Windows Server 2003, Windows Vista, or Windows Server "Longhorn"—the requirements are effectively the same. Obviously, first you need to have a 64-bit-capable processor. In the case of AMD, this means looking for a single, dual, or quad-core system that touts AMD64 compatibility (see amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). For Intel, this means looking for a single, dual, or quad-core system that touts either EM64T support or the Intel 64 Architecture (see intel.com/technology/intel64). Note that the devil is in the details here. An Intel Core Duo system, for example, is not 64-bit capable. An Intel Core 2 Duo system is 64-bit capable—even though it may be referred to as simply a Centrino Duo (as in the case of my laptop).

Living with x64
Once you’ve determined whether your system will natively support a 64-bit version of Windows, you need to deal with device support. Regrettably, as much as Microsoft has encouraged vendors and OEMs (through at least two years of WinHEC sessions) to create and certify 64-bit drivers for their devices and systems, the largest challenge you run into when using Windows x64 is finding drivers for hardware devices or software. In my experience, you will be most successful running x64 on a server where necessary device support is limited and the benefit of x64 is the most logical.
It’s hardest to find drivers for desktop and mobile systems. Generally, you’ll have better luck with a major OEM provider or a system built from enterprise-class components (where the likelihood of business use leads the vendor or OEM to create and sign x64-capable drivers).
For Windows Vista, this situation happily gets much better. Instead of a world where x86 is the preferred architecture and x64 is the ignored architecture with limited drivers available for the majority of hardware, the opposite is true. For Windows Vista, a device vendor must submit x64 drivers for compatibility testing. In fact, x86 drivers do not need to be included as well, but certainly can be. Conceptually, this means that some hardware—especially devices that take advantage of new Windows Vista capabilities—may actually only have x64 Windows support and not have x86 support.
The reality is that drivers are only one problem you will run into when attempting to run 64-bit Windows natively. The larger problem is getting there (or migrating) to begin with, but I’ll discuss that later.

Why 64-Bit?
AMD, Intel, and Microsoft didn’t move to a 64-bit architecture just for kicks, of course. The move to 64-bit provides several key benefits. As you can see in Figure 1, the most important enhancement provided by the x64 architecture is the ability to address significantly more memory—up to 16 terabytes (TB) versus the 4GB that 32-bit Windows can address. Note that while 64-bit pointers can address up to that 16TB limit, applications only have access up to about 8TB.
Figure 1 Memory address space limits (Close Figure 1)

Address Space | 64-bit Windows | 32-bit Windows
Virtual memory | 16TB | 4GB
Paging file | 512TB | 16TB
Paged pool | 128GB | 470MB
Non-paged pool | 128GB | 256MB
System cache | 1TB | 1GB
In addition, x64 versions of Windows provide for hardware-based Data Execution Prevention (DEP) —also available on x86 systems with NX (No Execute) support. This allows for a hardware-driven solution that Windows utilizes to prevent buffer overflows. It prevents code execution from data pages in memory—see support.microsoft.com/kb/875352 for more information on this topic.
x64 versions of Windows allow for native support of multiprocessor or multicore CPUs, just as x86 versions of Windows do. But one of the largest complexities of imaging a Windows XP system is eliminated by the use of a single hardware abstraction layer (HAL) across all Windows x64 installations—no more struggling to identify the HAL in use on non-ACPI or single-CPU systems.
Basically, Windows x64 as an architecture allows you to use your existing management infrastructure and existing 32-bit software (through emulation) plus 64-bit software with the ability to access such significantly enhanced memory. In fact, the only unpleasant side effects to moving to Windows x64 are: the complete lack of support for 16-bit applications (including gotchas like 32-bit applications with 16-bit installers); problems with applications that do not run reliably when hardware DEP is enabled (though DEP can be disabled on a process-by-process basis, and the Windows Application Compatibility team shims some applications which do not run correctly with DEP enabled); and finally, the fact that in 64-bit Windows Vista, all drivers must be digitally signed.
This last item was added to help prevent tampering with the Windows kernel in memory, a technique often used by rootkits. The expectation is that since x64 is the architecture that Microsoft is encouraging vendors to develop drivers for first (in order to get drivers through Windows hardware quality testing), this isn’t as scary of a requirement as it might have been historically.
There are a couple of other points to note when considering Windows for x64 systems. There are no versions of Windows XP for x64 systems that contain the functionality included in Windows Media® Center Edition or Windows Tablet PC Edition. However, this changes in Windows Vista, where the x64 versions of Windows have the same functionality as x86 versions.

Virtualization
One thing I haven’t mentioned is virtualization. I’m not talking about Microsoft Virtual PC or the VMWare PC virtualization products; I’m talking about operating system virtualization for 32-bit executables. In 32-bit versions of Windows, 16-bit applications all run within the context of the NTVDM—a Virtual MS-DOS® Machine. As I mentioned earlier, there is no support for 16-bit applications in the 64-bit versions of Windows. Instead, while most integrated components of Windows run natively as 64-bit binaries, some components and many third-party programs run as 32-bit applications.
Windows gives you an entirely new emulation layer called Windows On Windows (WOW) to allow for these 32-bit applications to see a different view of the operating system—effectively running on a 32-bit version of Windows. Under WOW, x86 applications see Program Files (X86) as simply Program Files. Likewise, %WINDIR%\SysWOW64 appears to x86 applications as %WINDIR%\System32. x86 applications view the registry key HKLM\SOFTWARE\Wow6432Node as they would view the HKLM\SOFTWARE node itself.
By using the Process Explorer tool, you can peer into another perspective of virtualization. Because many 32-bit applications expect to interact with integrated 32-bit Windows binaries, many of those binaries are provided in both 64- and 32-bit versions. By adding an additional column to Process Explorer, you can easily see this. In Figure 2, you’ll notice two instances of cmd.exe—one 32-bit version and one 64-bit version. Notice in the highlighted 32-bit instance, you’ll see several wow64* DLLs loaded in the 32-bit process. These show the virtualization taking place, which allows 32-bit applications to function under 64-bit Windows. Also note the working directory (Path) being used by the 64- and 32-bit versions of cmd.exe.
Figure 2 Process Explorer reveals 32-bit and 64-bit versions of cmd.exe
Figure 2 Process Explorer reveals 32-bit and 64-bit versions of cmd.exe
One final note of consideration on the topic of virtualization—while Windows runs explorer.exe as a native 64-bit application, this has some pros and cons. The largest con is that any Explorer shell extension must be recompiled for x64 in order to work (the majority have not).
The opposite is true of Internet Explorer®—it runs natively with the 32-bit version as the default. This is done primarily so that the abundance of ActiveX® controls on the Internet already in use today will successfully work as-is. Without it, because 64-bit applications cannot load 32-bit DLLs or drivers in-process, there is effectively no way to load 32-bit ActiveX controls which comprise almost all currently available ActiveX controls, on a 64-bit browser—meaning quite a bit of Internet content becomes inaccessible. To see this in practice, try loading C:\Program Files\Internet Explorer\iexplore.exe on a 64-bit Windows system and visiting any site that loads ActiveX control content (even Windows Update)—the result will be varying degrees of failure. Windows Update (see Figure 3) has now updated the experience to open a 32-bit instance of Internet Explorer in this situation. In the future, surely there will be some ActiveX control content updated to take advantage of 64-bit Internet Explorer. But with the majority of Windows systems today running purely 32-bit Windows, the necessity for ActiveX control content to be updated is not critical. I don’t expect this to change for quite some time.
Figure 3 32-bit ActiveX controls fail in 64-bit Internet Explorer
Figure 3 32-bit ActiveX controls fail in 64-bit Internet Explorer

x64 Windows at Pluck
I noted at the beginning of this article that we have begun the transition to x64 Windows at Pluck. We’ve done this with three different versions of Windows: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64, and Windows Vista x64.
Our organization is small enough that as we began developing our most recent product, we could begin migrating to Windows for x64 to take advantage of its benefits. Doing so meant ensuring all new hardware we ordered was x64-capable. In fact, it is the expanded memory capabilities of x64 in concert with virtualization that allow us to run our product the way we do. All of our physical servers run as 64-bit virtual servers on a 64-bit host server. Each host server has 16GB of RAM divided among the virtual servers hosted on it (generally 2GB for each staging virtual machine or VM and 3GB for each production VM).
By using tier 1 systems and virtualized hardware as well, we are able to achieve near 100 percent device support. My laptop, for example, has three devices that do not have x64 drivers available. These all appear to be backplane type devices that are not critical, and the system performs fine without their presence. Interestingly, an installation of Windows Vista RC1 x64 resulted in exactly the same device support—though with my system bearing the Windows Vista Capable logo, surely even these missing drivers will arrive from the vendor in short order.
Since our use of the systems is primarily constrained to Microsoft Office, Visual Studio®, and several additional tools utilized in our development and build process, we do not have many legacy applications to cause compatibility issues in our migration. While quite a bit of our organization does use 32-bit versions of Windows, we’ve begun the migration to 64-bit with new hardware and it has been relatively painless.

x64 Deployment and Migration
There are a few considerations that need to be taken into account regarding deployment. Microsoft provides a version of the Windows Pre-installation Environment (Windows PE) specifically for the x64 architecture. However, since there is x86 parity on x64 systems, you may well want to use x86 Windows PE to deploy—especially if you are using an imaging solution. If you are deploying Windows XP using unattended installation, Windows PE will have to be architecture-specific—as winnt32.exe must run under the same architecture it is deploying. Since Windows PE does not have a 32-bit compatibility layer, and winnt32.exe under x64 is a 64-bit application, 32-bit Windows requires 32-bit Windows PE. The same applies for 64-bit versions of Windows, which require 64-bit Windows PE.
Remote Installation Services (RIS) is different in this respect, and we use RIS at Pluck for this reason. RIS, beginning with Windows Server 2003 SP1, can deploy x64 as well as x86 or Itanium architectures of Windows. When an x64 system connects to a RIS server, the server (in default configuration) will offer up x86 and x64 RISetup or RIPrep images. RIS can be configured also offer x64 clients exclusively x86 images or exclusively x64 images. The choice was offered as the default to provide the best experience with x64 hardware.
Notice that I didn’t mention upgrading yet. That’s for good reason. Unfortunately, the act of upgrading an entire OS from x86 to x64 is a massive undertaking. For this reason—and given the limited deployment of Windows XP Pro x64 Edition—you cannot upgrade to Windows XP x64 from any x86 version, nor can you upgrade from any version of Windows XP (x86 or x64) to Windows Vista x64. Windows Vista on x64 systems is, as Windows XP Pro x64 Edition before it, a clean-installation-only product. For this reason, many organizations consider migration to x64 only when a hardware refresh rolls around—a similar strategy that many organizations are expected to take with Windows Vista itself (making the dual jump at the same time potentially a logical one).
But that doesn’t mean that people or organizations moving from x86 Windows to x64 Windows don’t have any tools readily available—they definitely do. Versions of the User State Migration Tool (USMT) for Windows XP and for Windows Vista have both been extended to support migration (versus an in-band upgrade of the OS) from one installation of Windows to another. This is the predominant method most organizations use to deploy Windows today regardless—wipe and reload, even on the same PC—so utilizing the same mechanism to move to Windows on an entirely new architecture should not present a much larger hurdle than before.

Conclusion
Though our small organization’s gradual migration to x64 may be considerably easier than the extensive migration process facing larger organizations, every IT professional must begin to consider the eventual move to x64 architecture. The reality is that although the x86 architecture and x86 native versions of Windows will still be around well into the next decade, the x64 architecture is certainly the future of enterprise computing. With Microsoft moving fully into x64 capabilities with Exchange Server and other products, you should begin understanding where x64 systems will fit in your architecture first, and where they may make sense in your Windows Vista migration plan as well, whether or not you are utilizing Windows XP or Windows Server 2003 natively on your x64 systems today.

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


 Inside Microsoft.com: Using Active Directory Federation Services
Inside Microsoft.com
Using Active Directory Federation Services
Jim Guthrie

Here at Microsoft we provide an extranet to give our business partners access to important internal resources. The architecture of the extranet requires that each participant outside the organization have a unique domain account for this space. This account is created and managed by Microsoft employees rather than the
partners, for obvious reasons. However, while functional, the experience for the user may be less than satisfying and the burden on Microsoft to manage all those partner users is somewhat resource-intensive.
Here’s how the extranet works now. When a customer or partner signs into an application, he is required to enter his credentials. During the same session, if that user decides to access a different resource he will again be prompted for his credentials. This continues as long as he bounces from one resource to the next. If the user were to sign into a single application that uses multiple resources, such as a financial database, he would have to authenticate to each resource independently. This can be a cumbersome and annoying experience for users.
Fortunately, by using Active Directory® Federation Services (ADFS), we can solve the multiple-authentication problem quite easily, and so can you. ADFS is a Windows Server® 2003 R2 component that facilitates a trust between two or more organizations to allow the sharing of multiple resources while maintaining each organization’s ability to manage its own set of users. In this column, I illustrate how Microsoft plans to use ADFS to solve this multiple-resource extranet problem, which will provide you with the information you need to implement a similar solution. Before I get into the details, however, take a look at Figure 1 to familiarize yourself with some of the basic ADFS terminology.
Figure 1 ADFS terminology (Close Figure 1)

Term | Definition
Federation | A pair of realms or domains that have established an Active Directory federation trust.
Federation Service Resource (FS-R) | Routes incoming authentications request to the FS-A and desired resources.
Federation Service Accounts (FS-A) | Provides an account token to be authenticated on the FS-R.
Federation Service Proxy (FS-P) | Provides a layer of separation for the FS servers from inbound Internet traffic.
Claim | A statement that a server makes (for example, name, identity, key, group, privilege, or capability) about a client.
Realm discovery | Each FS-A has a domain, or realm, in which logon credentials are stored. Realm discovery determines which FS-A is used for the ADFS session.

An ADFS Solution
When a user attempts to access an ADFS-aware application, the browser is sent to the Federation Service Resource (FS-R) for realm discovery. Here the user will select which set of credentials she will use for the duration of the session. Based on the realm the client has chosen, she will next be redirected to the Federation Service Accounts (FS-A) server. It is at this server that she will receive a valid account token (in a cookie) that is based on the credentials she input in the form of a Windows Live™ ID (formerly a Passport account), Windows Integrated Authentication, or SSL authentication (see Figure 2). In this model, it is up to the individual organizations to maintain their own account federation server. In the case of the Microsoft partner servers, this removes the burden on Microsoft.com to manage every account in the environment. Of course, if you implement that level of responsibility you must carefully select the organizations with which you will federate, and ensure that they are actively managing their account information.
Figure 2 ADFS flow
Figure 2 ADFS flow
The next stop on the route is back to the FS-R server to exchange the account token for a resource token. In our configuration, this token contains a complete list of the permissions the user has been granted through a claims-mapping process that is performed on the FS-R. Once the token has been received, that user gets the single sign-on (SSO) capability on ADFS-aware applications for as long as the session is open, or up to 24 hours by default (this window is configurable). The upshot is that you have enabled SSO to these ADFS-aware applications, resulting in a more secure and efficient customer experience. For a complete walkthrough of the ADFS authentication process, see Matt Steele’s article from the July 2006 issue of TechNet Magazine entitled "Simplify Single Sign-on with ADFS".
To maintain the security of Microsoft corporate resources, we have isolated the internet-facing side of the extranet from the corporate side, meaning that each server is potentially dual-homed. We allow a one-way trust from corporate internal users and utilize the servers to provide the needed protection. We also have a separate domain for the extranet space where we provide external users with access to the needed resources.
Two main areas of concern during implementation were load balancing and the ADFS policy file changes. Load balancing was a challenge at both a global and local level. Initially in production we will use global load balancing from our Content Delivery Network (CDN) partners Akamai or Savvis for the front-end Web server clusters in two regions. This will ensure availability of the system to end users even in the unlikely event a pair of regional servers go offline. This is accomplished with failover automation based on server health-checking services provided by the CDNs. Additionally, we have the ability to easily add more clusters in the future. As a cost savings, our preproduction deployments have elected not to use the CDN service.
At the regional level we have paired up the servers for local failover through network load balancing (NLB) clustering. We are not using any special load-balancing features, so this could have just as easily been accomplished with hardware; however, again we are using NLB for the cost savings. This configuration will provide the stability to ensure greater than 99.9 percent uptime in all supported environments.
Another challenge we faced was ensuring that the ADFS policy file, the backbone of ADFS, was correctly distributed throughout our environment and that changes to it are replicated as well. To achieve this, we leverage another built-in feature of Windows Server 2003 R2—Distributed File System-Replication (DFS-R), a new state-based multi-master replication engine. On each of the back-end servers we have enabled a DFS-R group membership with a 24-hour, full-mesh replication. Now, no matter where the change to the policy file happens, it will be distributed to all servers. As long as we control who can change the file, we have a stable, highly available service.
We have tried to ensure that all changes be made through the ADFS snap-in. However, in practice we found we must occasionally update this file manually. When updating manually it’s important to remember that ADFS tracks the version of this file. Therefore you must increment the file so your changes will be reflected in the environment:
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
You also have to remember that, like all XML, the policy XML file is case sensitive. Throughout the policy XML file there are many references to the applications or other ADFS servers and in all cases they must be copied verbatim from server to server. Please note the following common examples where the first, RevocationCheckFlags, was manually entered and the second is a trusted application URL modified from the UI:
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
For an additional level of security we use another component of ADFS, the Federation Service Proxy (FS-P), which ensures that the FS-Rs remain a layer removed from direct access from incoming Internet requests. A unique way we have implemented proxies at Microsoft.com is through the use of a single set of proxies to host several ADFS environments in our preproduction area. Interestingly, during the initial ramp-up on the technology we discovered that we needed to make a simple registry key modification in order for this to happen. The key is located at HKLM\Software\Microsoft\WebSSO. Simply changing the value of the initial directory in this key will allow you to use the proxy for several environments. The default was:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
To switch environments, the key would change like so:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
Creating a batch file can simplify the management of this process. Unfortunately the current version of the MMC snap-in for ADFS doesn’t support switching environments as there is a one-to-one relationship between the proxy and the resource or account server. This is the only way to maximize the utilization of the proxy servers. The end result is that this is a tremendous cost savings as it limits the number of physical servers required no matter how many different environments you choose to host.
From an architectural standpoint we are running our preproduction environment with virtual machines—another cost-saving measure. This eliminates the need to purchase and house six additional servers. To date, we have had no performance problems. However, to meet the significantly increased demand in the production environment we have elected to use higher-performing physical machines.

Not Just for Active Directory
Not only is Microsoft.com using Active Directory accounts for authentication, but we have also successfully integrated with Windows Live ID accounts. We’ve found that by using Windows Live ID (WLID) 4.5, we can use an individual’s Windows Live ID account to delegate access to Microsoft resources using a custom claims transform. This is a huge win for achieving the SSO authentication as we no longer require a specific domain account.

Remaining Challenges
The biggest challenge we are facing right now is the management of ADFS for sharing token-signing certificates. We are using standard certificates that remain valid typically for one year before requiring renewal. At renewal time each of the appropriate servers will need to be updated accordingly, which will have significant impact on the FS-Rs. While marginally manageable with 15 or 20 federations, the scale we would like to think about is at least in the hundreds if not thousands. This would require full-time staffing for the management of SSL certificates for a single environment. We have several teams looking at the best methods to automate this solution but have not settled on a course of action.
Another remaining challenge is that not all applications are ADFS-aware out of the box. There will be some programming required for the sites to take advantage of the ADFS opportunity. We are working closely with the Microsoft® Office SharePoint® Services team to ensure that the next generation of SharePoint will support our implementation needs for ADFS.

Conclusion
There are a number of factors to consider in making the decision to move to an ADFS model. One is the number of resources customers will access. The process of setting up a federated trust between organizations can be a trivial task, but it takes time and effort to write, review, and execute acceptable access policies. So if you have just one resource your customers will access, you will have to decide if it’s worth the effort. However, as the number of resources grows, the benefits increase.
If you’re looking for more information, see the ADFS Overview and Active Directory Federation Services: A Path to Federated Identity and Access Management.

Jim Guthrie works for Microsoft on the Microsoft.com Operations team where, in addition to working with ADFS, he is a Systems Engineer with the Enterprise Portal Platform Support team.


 Field Notes: The Joy (and Pain) of Learning
Field Notes
The Joy (and Pain) of Learning
Mark D. Scott

I remember how it used to be when something new came out—the thrill of getting my hands on the latest technology before most people did, turning the product inside out, learning how it worked, making it work. I thrived on being an early adopter, the one in the know, the wizard to whom others came to get that secret knowledge.
But, somewhere along the line, the joy dimmed. I am not certain what happened. Maybe I lost it in the frustrations of trying to make mission-critical applications work at 3:00 in the morning. Maybe I left it on the floor with the product documentation I misread as the enterprise mail server went south (back in the days when one server was enough). Maybe I’m just getting old and cynical. No matter. It’s just not as exciting to burn the midnight oil as it was a decade or so ago. But that doesn’t mean it’s OK to stop learning. I had that point reinforced not long ago.
I recently upgraded to Microsoft® Outlook® 2007 and I really like it. But I am also an MSN® Premium subscriber; my ISP provides my subscription as part of its service. Under the previous version of Outlook, I needed a special piece of software called a connector to access my MSN e-mail address. This software connector did not work with Outlook 2007, so I contacted MSN. MSN told me to speak to my ISP, who told me—eventually—that it did not support the MSN Outlook connector on Outlook 2007. Back and forth, e-mail, chat, and voice—it took just short of forever to get this information.
Then it hit me—maybe I didn’t need a connector anymore. I started Outlook 2007 and configured a new connection to MSN without using the connector software. Outlook went out on the Internet, found the server, and configured the account without a hitch. It did that for several other of my POP3 accounts as well. So I got access to my e-mail and I learned about a great new feature of the product.
Now, there’s a moral to all of this. If someone in the support ranks had bothered to play with the new product, most likely he could have told me I didn’t need the connector and it would have saved us both a lot of time.
Perhaps more to the point, if I had played with the product in the first place, I would probably have found the solution myself. But instead I wanted someone to just tell me the answer. And because no one had taken the time to explore something that was, after all, important to our everyday lives, we both lost more time than if each of us had just dug in and solved the problem on our own—which is exactly what I ended up doing anyway.
Technology changes defeat our presumptions. To serve as IT professionals, we need to keep ourselves free of preconceptions. The knowledge we work the hardest to gain is the knowledge that new technology will inevitably supplant—because replacing that knowledge is what makes the technology easier to use. We can’t leverage that arcane knowledge as our competitive edge forever. The real edge lies not in the accumulation of aging facts about how technology used to work, but rather in the ability to master new concepts and techniques. By continually learning, making learning part of our routine, we hone those skills. With the vast array of new products endlessly coming down the pike, learning must remain our way of life.
So if you need to reach me, feel free to e-mail me at either my Microsoft account or my MSN account—I can get mail from both in Outlook 2007.

Mark D. Scott is a Senior Consultant with Microsoft Consulting Services. He works closely with clients to help design and build large-scale, data-centric applications. You can reach Mark at granddaddy2002@msn.com or mascott@microsoft.com.


 Windows Confidential: The Power of Bugs
Windows Confidential
The Power of Bugs
Raymond Chen

In Windows 95, you could go to the Troubleshooting page and select Disable Synchronous Buffer Commits. But do you know what this checkbox did? Or why?
The normal behavior of the MS-DOS® Commit function was to flush all unwritten data for a particular file to disk, and wait until the data had been confirmed as written before returning. With the Disable Synchronous Buffer Commits option checked, the call would return immediately, rather than waiting for the data to be written. This, of course, was a violation of the functional specification, which requires that the call not return until the data has been written. This increased the risk of what Knowledge Base article 139669 euphemistically calls "file integrity problems" since it caused the program that issued the flush request to think that the data was safely on disk when it really wasn’t.
A database program may use the Commit function to establish points at which the state of the file on disk is in agreement with what the program expects to be on the disk. If the computer loses power during an update, the database program can use the information recorded at the last commit point to re-establish the integrity of the database. If Commit returned immediately before the commit was complete, then this integrity checkpoint would be lost. The result was that your database became corrupted.
Why was this option available if the consequences were so awful? The reason: a bug in Windows® 3.11.
Figure 1 Enabling buggy behavior in Windows Server 2003
Figure 1 Enabling buggy behavior in Windows Server 2003
Windows 3.11 introduced "32-bit file access," which was a 32-bit implementation of the low-level file I/O interface. But the implementation of the Commit function contained a bug that effectively ignored requests to flush file buffers. If you took a program that flushed its file buffers and ran it on Windows 3.11, the flush call had no effect. As a result, if you lost power at just the wrong time, you ended up with a corrupted database.
The folks working on the Windows 95 file system fixed this bug, but new bug reports started to trickle in. Somebody’s accounts payable program started running really slowly. Then somebody else’s database program did the same. What was going on?
It turned out that these programs constantly issued flush calls. The programmers noticed that flush calls were really fast on Windows 3.11, so they sprinkled them liberally throughout their program. Write a byte, flush. Write a string, flush. Since the flushes were so fast, the app could commit the data to disk after every operation with no noticeable performance degradation. But once Windows 95 fixed the bug, these programs started to run very slowly since the Commit calls were suddenly doing actual work.
Of course, if the file system team had done nothing, these programs would have continued to run slowly and users would have jumped to the conclusion that Windows 95 was the problem. "Windows 95 runs like a dog," they would tell others. On the other hand, if the file system returned to the old Windows 3.11 behavior, they would have been reintroducing a bug that could lead to those pesky "file integrity problems."
So they concluded that the solution was to leave the bug fixed but add a check-box—albeit buried in the Troubleshooting page—to return to the Windows 3.11 behavior for those people who were running programs that encountered problems due to the bug being fixed.
It turned out that history repeated itself. In Windows Server® 2003, the I/O folks found a bug where requests tagged as Forced Unit Access (FUA) would lose the FUA tag and be performed as normal I/O. It was the modern-day version of ignoring flush requests! They fixed the bug but left an option to return to the old buggy behavior. The Windows Server 2003 version of this checkbox is called "Enable Advanced Performance," but now you know it really just means "Restore old buggy behavior."

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. He does not clip the tags off his pillows.