 TechNet Magazine January 2008

TechNet Magazine January 2008

System Center: Real Control with Virtual Machine Manager 2007

Virtualization allows organizations to consolidate resources and save money. But as you begin to implement increasing numbers of virtual machines, you'll want a convenient way to manage them. Here's a guide to setting up Virtual Machine Manager and using it to perform administrative tasks from a centralized interface.

Edwin Yuen System Center: Better Backups with Data Protection Manager 2007

The latest version of Data Protection Manager offers many new features, delivering a powerful and flexible solution for managing your backups. Here's an overview of how DPM can protect everything from Exchange and SQL Server to branch offices and SharePoint sites.

Calvin Keaton System Center: Online Services Help Simplify Software Inventory

Software asset management is an essential task for every business—large or small. But with the amount of software businesses now purchase and deploy, getting a handle on those assets can feel next to impossible. Find out how the new Asset Inventory Service from Microsoft can help.

Paul Bourgeau Group Policy: Inside ADM and ADMX Templates for Group Policy

ADM files are both necessary and often confusing. Don't let this slow your Group Policy efforts. This guided tour will help you better understand what's inside ADM files and the new ADMX format, which tools you can use to handle them, and how you can make the best use of these files.

Jeremy Moskowitz Group Policy: Optimizing Group Policy Performance

All Group Policy is not the same, and knowing the differences between types can help you fine-tune performance on your systems. Explore monolithic and functional GPs, learn how to process Group Policy, and find out what happens when Group Policy changes occur.

Darren Mar-Elia Group Policy: Dive into Advanced Group Policy Management

AGPM, or Advanced Group Policy Management, is a handy tool that lets you work with Group Policy Objects in ways that other tools don't. And it's now available to members of the Microsoft Software Assurance program. Check out how you can use AGPM to edit GPOs offline, delegate administration, track changes, and more.

Derek Melber From the Editor: Winning Over a Cynic

Joshua Hoffman Letters: Readers Speak Out

Toolbox: New Products for IT Pros

Greg Steen Exchange Queue & A: Adding Voice Prompts, Choosing a PBX , and More

Have questions about Exchange Unified Messaging? We've got answers. In this installment of Exchange Queue & A, we focus on Unified Messaging, discussing how you can implement phone and fax features, offer high availability, set up voice prompts, and more.

Seema Rahman Utility Spotlight: Windows Easy Transfer Companion

This free tool can simplify the migration of key applications from Windows XP to Windows Vista.

Lance Whitney The Cable Guy: DNS Enhancements in Windows Server 2008

Windows Server 2008 includes many DNS server enhancements. Take a close look at how these updates make name resolution faster, improve support for IPv6, and add greater flexibility to DNS administration.

Joseph Davies Windows PowerShell: Heading Off Malicious Code

When designing Windows PowerShell, a lot of thought was put into security. But, as with any software, Windows PowerShell can still be exposed to malicious code. Here are some recommendations for choosing an Execution Policy that will keep your systems more secure.

Don Jones Hey, Scripting Guy!: There's No Mistaking Regular Expressions

Looking for a way to avoid making mistakes? Validation is a good start. Learn how to perform character pattern matching in a script using regular expressions.

The Microsoft Scripting Guys Security Watch: Island Hopping: The Infectious Allure of Vendor Swag

Security threats don't just come from e-mail and malicious Web sites. See how a USB thumb drive and some simple social engineering can be used to gain access to your entire network. And find out what you can do to keep your network more secure against this threat.

Jesper M. Johansson The Desktop Files: Shared Computing with Windows SteadyState

The new Windows SteadyState toolkit can help you improve security and simplify management of Windows XP systems in a shared-use environment? Take a guided tour to find out how.

Wes Miller Field Notes: Your Most Important Task of the Day

When you're working on a project, don't underestimate the importance of setting aside time to think, plan, and prioritize.

Eric N. Bush Windows Confidential: Remind Me Never to Do That Again

Hardware detection in the days before proper Plug and Play devices was a very scary undertaking. Find out why.

Raymond Chen


 System Center: Real Control with Virtual Machine Manager 2007
System Center Edwin Yuen

Real Control with Virtual Machine Manager 2007
At a Glance:
  • Major features of System Center Virtual Machine Manager 2007
  • How to install VMM
  • Converting physical or virtual machines to VMs

System Center Virtual Machine Manager 2007 is a new solution that provides a consolidated interface for managing your entire virtual infrastructure. Virtual Machine Manager (VMM)
can manage existing Microsoft® Virtual Server 2005 installations, and it can also install Virtual Server 2005 R2 SP1 on new virtual machine (VM) hosts. With VMM, the traditional Virtual Server 2005 administrative tasks can now be performed far more efficiently through a centralized interface, with management access across multiple Virtual Server installations.
In addition, VMM brings new capabilities to Virtual Server, including Physical-to-Virtual (P2V) conversions, Virtual-to-Virtual (V2V) conversion of VMware Virtual Machine Disk Format (VMDK) disks to Virtual Server Virtual Hard Disks (VHDs), and rapid VM deployments from templates and pre-configured VHDs via a centralized library of virtual infrastructure objects.
In the following pages, I'll explore VMM and the powerful set of features it provides to IT administrators. I will then look at the requirements and steps for creating a VMM installation. Finally, I'll take a deeper dive into a handful of the more exciting features of VMM and leave you with some helpful tips on getting started.

Introducing Virtual Machine Manager 2007
System Center Virtual Machine Manager 2007 is a standalone application that provides centralized, enterprise-class management of virtual machines running under Microsoft Virtual Server 2005. As part of the System Center family, Virtual Machine Manager integrates with the other System Center products to provide end-to-end physical and virtual infrastructure management. Figure 1 shows the various components of Virtual Machine Manager and how VMM relates to a Virtual Server host.
The left-side box represents the VMM server and the right side represents a virtual machine host. The VMM components can also be installed on separate servers, if you prefer, to improve performance and scalability. For this article, we will use the model in Figure 1, where the core VMM components are all installed on one computer. At the heart of the VMM product is the Virtual Machine Manager service, in the center on the left. Above it are the three different interfaces into the service: the Windows PowerShellTM interface, the Administrator Console, and the Self-Service Portal with Delegated Provision management. Supporting VMM is a Microsoft SQL Server® 2005 database (you can use either a full installation of SQL Server or SQL Server 2005 Express Edition), and the centralized library, which is a file share for virtual infrastructure components.
Figure 1 System Center Virtual Machine Manager 2007 architecture
Figure 1 System Center Virtual Machine Manager 2007 architecture
The right side of Figure 1 represents a Virtual Server 2005 R2 virtual machine host that VMM is managing. At the bottom is the host operating system—in this case, Windows Server® 2003 R2. VMM will install an agent on the virtual machine host that facilitates the communication between VMM and Virtual Server 2005 R2. This is a single installation on the physical host, with no installation in the VMs or guest OS. If Virtual Server is not installed on the host machine, VMM can automatically perform the installation when the host is added to the list of managed servers.
As part of the System Center family of products, Virtual Machine Manager uses the new System Center (or Outlook®-style) interface for Administrator Console (as opposed to the traditional MMC snap-in). The VMM Administrator Console (see Figure 2) is built using the Microsoft .NET Framework 2.0 and is built on top of Windows PowerShell 1.0. In fact, any action performed in the Administrator Console actually calls the associated Windows PowerShell command. As a result, any command or function called in the Administrator Console can also be invoked directly through the command line in Windows PowerShell.
Figure 2 VMM Admin UI showing managed Virtual Machines
Figure 2 VMM Admin UI showing managed Virtual Machines
Each wizard in the Administrator Console also has a View Script button that will show the associated Windows PowerShell script for the command about to be run, which provides a great starting point for learning Windows PowerShell as it relates to VMM. Once you get used to using Windows PowerShell with VMM, you will be able to script bulk actions through VMM.
Virtual Machine Manager is designed to provide three key benefits for IT administrators: it allows you to maximize resources, achieve better agility, and leverage existing skills. VMM supplies these benefits through several features and functions. First, VMM helps maximize your resources by providing a method to convert your physical servers to virtual machines, a process known as P2V conversion that lets you consolidate your existing physical machines into virtual machines without having to reinstall those machines. This is especially significant when converting machines that have low utilization for their hardware because you can place several such machines together on a single piece of physical hardware. This can be particularly useful for, say, machines with legacy software that's rarely used but needs to be maintained because it runs once a year (regulatory accounting software, for example). When used in conjunction with System Center Operations Manager 2007, VMM can help produce a Server Consolidation Candidates report to review which machines in the physical infrastructure are likely candidates for P2V.
If you already have virtual machines in VMware's VMDK format, VMM provides the capability to perform a V2V conversion to translate your existing VMDKs into the VHD format. This quickly gets your Virtual Server 2005 environment up and running.
As part of any deployment, whether new or started through conversion, VMM uses a process called Intelligent Placement to deploy the VMs to the virtual machine hosts. Using Intelligent Placement, VMM queries all the virtual machine hosts that it manages, retrieves several parameters about the resource availability of these hosts, and then returns a weighted list of recommended hosts to deploy the VM to. As you can see in Figure 3, the administrator can then choose to accept the recommendation, adjust the algorithm to fit particular needs, or simply deploy the VM to the server of his choice. With its consolidated view of the virtual infrastructure and its host recommendations, Intelligent Placement greatly reduces the burdens related to VM deployment.
Figure 3 Intelligent Placement provides recommendations for the best Virtual Server host
Figure 3 Intelligent Placement provides recommendations for the best Virtual Server host
Other features of VMM that yield great benefits include a centralized library and a self-service portal for delegated provisioning. The library, shown in Figure 4, provides a central store for all components needed to build a virtual infrastructure, including pre-created and deployment-ready VHDs, templates with OS and hardware configurations, ISO files, scripts, and profiles. New VMs can be created and deployed from these components, and the use of templates and profiles can standardize both hardware and software configurations across the VMs. VMM also supports distributed libraries, allowing the components to be stored in remote locations and keeping large file transfers within the remote location while continuing to manage the components centrally.
Figure 4 VMM's library contains all the building blocks for a virtual infrastructure
Figure 4 VMM's library contains all the building blocks for a virtual infrastructure
The self-service portal is a Web site that integrates with the VMM service and an IIS installation. The portal grants access for Active Directory® authorized users and groups to VMs, with the available functions depending on the policy created for that user or group. These functions range from the ability to view and access the VMs, to running and shutting down the VMs, to creating new VMs based on specific delegated resources.
The administrator creates a self-service policy that grants particular functions to Active Directory users and groups, to specific virtual machine hosts or host groups, and to specific VMs and templates. The self-service portal gives the administrator the ability to safely delegate functions to end users. Without this function, the administrator would either need to grant end users access to the Administrator Console to manage their VMs or have the end users put requests in for each function, resulting in burdensome e-mails and phones calls just to perform actions such as VM starts and resets.

Virtual Machine Manager Installation
VMM currently manages Virtual Server 2005 (and later) installations on Window Server 2003 SP1 (and above) within an Active Directory domain (or trusted domain), as well as non-domain hosts using VMM's perimeter network support. Virtual Server installations on desktop operating systems like Windows® XP are not supported. P2V operations are only available for physical machines located in the same domain (or trusted domain) as the VMM server.
While I'd recommend that each VMM component be installed on separate servers in a production environment, the instructions here will cover a single-server installation. The recommended hardware for a VMM server installation is an x86-or x64-based server running at 2.8GHz or above with at least 2GB of RAM. Since this is a single server installation with a local SQL Server database, 7GB of hard disk space is required. If a remote database is used instead, only 1GB is required for the VMM installation. An additional 80GB of disk space is recommended for the local library installation.
Additionally, VMM requires that WinRM 1.1 be installed on the VMM server, all virtual machine hosts, and any library servers that will be managed by VMM. WinRM is the Microsoft implementation of the Web services for Management (WS-Management) protocol. WinRM is a SOAP-based, firewall-friendly protocol that lets hardware and software from different vendors interoperate and manage one another. VMM uses WinRM to perform actions between the VMM server, the virtual machine hosts, and the library servers. You can download WinRM 1.1 from go.microsoft.com/fwlink/?LinkId=103610.
Other prerequisites for the installation include the .NET Framework 2.0 and 3.0, Windows PowerShell 1.0, and IIS for the self-service portal. All of the additional software requirements are checked for during the VMM software installation and links to the proper installers are provided. If any of these requirements are not met, the installation will not proceed.
When you start the VMM installation, you are offered three choices in the main menu: the Virtual Machine Manager Server, the Administrator Console, and the Self-Service Portal. We will install all three on the single machine, starting with the Server. Once the setup process starts, the first screens will check for the system prerequisites; you must ensure they are all met in order to allow the installation to proceed.
After the prerequisites are cleared, you should review the installation options, especially those related to the SQL Server database. With VMM, you can either choose a SQL Server 2005 Express Edition install or use an existing SQL Server 2005 database. For this example, we'll use SQL Server 2005 Express Edition.
In the next step of the VMM installation wizard, you identify the location for the centralized library. This location can either be a local directory on the VMM server (and a share will be created for that directory), or an existing file share can be used. The default location is C:\Documents and Settings\All Users\Shared Documents\Virtual Machine Manager Library Files.
Port assignments are the next step. Here you configure the ports used for the Administrator Console's connection to the core VMM server service (port 8100), the port used by WinRM to perform the management functions (port 80, the standard HTTP port), and the port used by the Background Intelligent Transfer Service (BITS) to move the files to the virtual machine hosts (port 443, the standard HTTPS port). Once all this information is gathered, a summary screen is presented and the server installation can finish.
Now let's install the Administrator Console. The system prerequisites are similar to the VMM server, requiring .NET Framework 2.0 and 3.0, as well as Windows PowerShell 1.0. The only configuration option is to confirm the communications port used to connect to the core VMM server service. This port should be 8100, as configured in the VMM server installation. At the end of the installation, you are given the option to create a desktop shortcut for the Administrator Console and to open the console when you close the setup. I suggest selecting both. The first time you open the Administrator Console, you will be prompted for the server connection information. With a single server installation, you connect to localhost on port 8100 and hit Enter to start the console.
Finally, let's install the self-service portal on this server. The prerequisites for this are IIS, the .NET Framework 2.0 and 3.0, and Windows PowerShell 1.0. During the installation, the only configuration options are those that deal with the ports used by the self-service portal. The first is the port to connect to the core VMM service, port 8100, which is the same as the Administrator Console. The second is the port to run the portal on. The default is port 80, but, in many configurations, that port may already be in use. If necessary, change the port to another open one such as 81.
The installer will create a Web site called Microsoft System Center Virtual Machine Manager 2007 Self-Service Portal, and the configuration can be changed in IIS Manager. Here's a tip to ease installation: go into IIS Manager and select the Microsoft System Center Virtual Machine Manager 2007 Self-Service Portal properties. Review the ASP.NET configuration for the Web site and confirm that the ASP.NET version is set to 2.0. The self-service portal will not work with ASP.NET set to version 1.1, and depending on the installation order of IIS and the .NET Framework versions, these settings can vary.
Once the IIS installation is complete, you can open the Web site by browsing to http://localhost:81 in Internet Explorer®. If you get prompted for authentication when opening the Web site, this is due to Internet Explorer security settings. The self-service portal should run in the intranet context in Internet Explorer; you may need to add the VMM server to the list of intranet sites in your local configuration. Once those changes are complete, you will be ready to create and use self-service policies in VMM.

Virtual Machine Manager Features
While there are many exciting features in VMM, the two that have arguably generated the most interest are the Physical-to-Virtual and Virtual-to-Virtual capabilities. Both functions are supported from within the Administrator Console. Since the VMM Administrator Console is built on top of Windows PowerShell, all the commands can also be run through Windows PowerShell itself. For our purposes, we'll explore the P2V process using the Administrator Console and the V2V process through Windows PowerShell.

Physical-to-Virtual Conversion
To perform the P2V conversion, we use the VMM Administrator Console. There are several requirements for the physical machine that will be converted. First, this machine must be a member of the current domain or a trusted domain. VMM will connect to that machine to install a P2V agent and transfer the necessary information. Second, the source machine must be running a supported operating system. The supported operating systems for P2V are Windows Server 2003, Windows 2000 Server, and Windows XP Professional. If that source machine is running Windows Server 2003 or Windows XP, VMM will use the Volume Shadow Copy Service (VSS) to consolidate the hard drives and stream the data into virtual hard disks. This allows the machine to be converted without any downtime, so you don't have to schedule downtime for the server just to create the P2V image. For Windows 2000, a Windows PE boot disk is created to facilitate the P2V image creation. For this example, I'll use a Windows Server 2003 target.
The P2V process is started by choosing the "Convert physical server" option under Actions in the upper-right portion of the Administrator Console. This brings up the P2V Wizard, shown in Figure 5. The first page is the Select Source step, where the machine to be converted is identified. Enter the DNS name of that machine and the appropriate domain credentials to connect to and manage it. The next step allows you to give a name to the resulting VM.
Figure 5 VMM's P2V function is wizard-based and is built into the Admin UI
Figure 5 VMM's P2V function is wizard-based and is built into the Admin UI
The wizard then starts the process of gathering information from the source machine. When you click Gather System Information, VMM installs a P2V agent that will retrieve the necessary information about the source machine's operating system, hard drive, and network adapters. Clicking Next takes you to a validation screen to verify that there are no known issues to prevent conversion. If there are, possible resolutions will be presented.
Once the configuration information has been retrieved, you can select the hard disk partitions to convert. By default, the boot partition is selected and any other partitions that are present are made available. You can choose which partitions will be kept as part of the conversion. The P2V is a smart-copy process; what this means is it pulls over only the data on the specified partitions, as opposed to a fixed transfer of an entire hard drive image and size.
Finally, the wizard progresses to the standard VMM deployment steps, including the Virtual Server start-up configurations and the Intelligent Placement process described earlier. When the wizard is done, the Jobs window will pop-up, showing you the entire process and progress of the P2V.
By default, newly converted VMs will not start automatically (they are converted into a Stopped state), nor does the P2V process shut down or change the running status of the source machine. This is a non-destructive P2V process. Because the new VM will have the same computer name, IP address, and even MAC address of the original server, that machine must be shut down before the VM can be started. If you want the source machine shut down or the newly converted VM to start automatically, this can be done from the Windows PowerShell command line. As part of the process, it's a good idea to perform the P2V and then run the resulting VM in a test environment, making sure that everything converted successfully.

Virtual-to-Virtual Conversion
To perform the V2V, you need both a VMWare virtual machine (in the form of a VMDK file) and a valid VMM installation with a designated destination virtual machine host. The VMM V2V Windows PowerShell cmdlet new-v2v supports the following four VMDK file formats: monolithicSparse, monolithicFlat, twoGbMaxExtentSparse, and twoGbMaxExtentFlat. Most existing VMDK files will fall into one of these categories.
The V2V process only works on offline VMDK files. However, the P2V process may be used to convert VMware virtual machines that are currently running. VMware virtual machines consist of two main components—the VMDK files that are the virtual hard disks where the data is stored, and a VMX file that contains the virtual machine configuration information. The VMDK files and associated VMX can be placed in a library location that gives you a way to access and convert the VMware virtual machine without the necessity of having to grant access to the file from the origin server.
During the V2V process, the VMDK file will be converted to a VHD file, the guest operating system will be cleaned up to work with Virtual Server and a new virtual machine will be created to match the original configuration as closely as possible, making the changes necessary for the virtual hardware supported by Virtual Server. Note that each part of the conversion process can be managed separately through Windows PowerShell, which allows bulk format conversions prior to allocating hosts for the new virtual machines. In this example, though, we want to convert and deploy the VHD.
While V2V can be done through both the Administrator Console and via Windows PowerShell, we will use Windows PowerShell for this example. To start the V2V process, let's start a Windows PowerShell window with the VMM cmdlets loaded. This can be done by clicking on Start | All Programs | Microsoft System Center | Virtual Machine Manager 2007 | Windows PowerShell—Virtual Machine Manager.
The resulting window should have the title Windows PowerShell—Virtual Machine Manager. If it does not, the VMM cmdlets may not be loaded. Once Windows PowerShell is open, you can review the new-v2v command by running the following:
get-help new-v2v –full | more
This will provide you with the syntax and examples on how to perform a V2V. In the example that is given for this article, our VMM server will be called vmmserver.contoso.com, the destination virtual machine host will be called vshost1.contoso.com, and the VMDK is available from the library server vmmserver.contoso.com.
You start by identifying the context for the VMM server that will be used to perform the V2V, using the get-vmmserver command. As with all Windows PowerShell commands, get-vmmserver follows the verb-noun format and uses dashes for the parameters. The following line shows is the command we will use to identify the VMM server:
get-vmmserver –computername "vmmserver.contoso.com"
This sets vmmserver.contoso.com as the VMM server context for the commands to follow. The result of the above command is a detailed list of information about vmmserver.contoso.com. If the command was incorrect or the syntax was wrong, a red error message will describe the problem.
The next step is to identify the destination virtual machine host, the Virtual Server host that the converted VMDK/VHD will be assigned to. Let's go ahead and assign the virtual machine host value to the variable $vmhost, using the following command in Windows PowerShell:
$vmhost = get-vmhost –computername
"vshost1.contoso.com"
This command doesn't produce any feedback in the command window but you can easily verify that the variable is correctly set by simply typing $vmhost at the Windows PowerShell prompt and then pressing Enter. This should display the information stored in $vmhost (detailed information about vshost1.contoso.com, similar to the information we had above for the VMM server).
In addition to the virtual machine host, you need to identify the library server where the VMDK file is located. The command is similar to the virtual machine host command that I used previously:
$library = get-libraryserver –computername
"vmmserver.contoso.com"
As with $vmhost, entering $library on the command line will display the library server information.
Finally, you actually type the command to perform the V2V conversion. In order to accomplish this, you use the new-v2v command with the get-help function. In this command, you go ahead and identify the library server for the VMX/VMDK, the destination host, the name of the resulting VM, and the path for the converted VHD file.
For the command line, most of the references are done from the perspective of the destination host, in our case, vshost1.contoso.com, with the install path is given as a local reference for VSHOST1. The VMX path is from the perspective of the library server. The resulting command line in Windows PowerShell is as follows:
new-v2v –LibraryServer $library –vmxpath
"\\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx"
–vmhost $vmhost -name "DemoV2V"
–path "C:\VHDs"
As you can see, here we're converting the VMX/VMDK for \\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx on the library server $library (VMMSERVER), deploying it to the host in the variable $vmhost (VSHOST1), with the name DemoV2V, to the path C:\VHDs on VSHOST1.
Once the command has been run, it's always a good idea to go back to the Jobs window in the VMM Administrator Console in order to view the progress. The VMX/VMDK will be converted and then copied to VSHOST1, where the resulting VHD will be added to the list of VMs as DemoV2V. When the process is completely finished, you will then be able to use VMM to start the new virtual machine and review the results.

Wrap-Up
As you see, System Center Virtual Machine Manager 2007 brings some great new features and capabilities to your virtual infrastructure. By reviewing the P2V and V2V processes, I hope I've shown how easy these are using Virtual Machine Manager.
VMM is designed to simplify an IT administrator's job when it comes to creating, deploying, and maintaining VMs. With the release of System Center Virtual Machine Manager 2007, I strongly recommend that Virtual Server 2005 administrators look into using Virtual Machine Manager to maintain their virtual machine hosts. For users of the new Windows Server virtualization in Windows Server 2008, Microsoft will provide support for Windows Server virtualization in the next version of System Center Virtual Machine Manager, which will be available after the final release of Windows Server 2008 virtualization.
For additional information on VMM, and to download a demo, please visit microsoft.com/SCVMM. For more information on all Microsoft virtualization products, visit microsoft.com/virtualization.

Edwin Yuen is the Technical Product Manager in the Windows Enterprise Management division for System Center Virtual Machine Manager. Edwin came to Microsoft with the July 2006 acquisition of Softricity. Edwin also has 13 years of technical consulting experience in both the commercial and federal space. He has a BS in electrical engineering from Johns Hopkins University.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 System Center: Better Backups with Data Protection Manager 2007
System Center Calvin Keaton

Better Backups with Data Protection Manager 2007
At a Glance:
  • Moving away from tape backups
  • Continuous Data Protection
  • Disk-based backups
  • More granular control with DPM

The data protection market has recently experienced a renaissance of sorts. After years of tape-based backup solutions and one-size-fits-all approaches to nightly backup, a number of new
technologies and methods have been introduced in a relatively short period of time. These new technologies have included disk-based backup, Continuous Data Protection (CDP), and even something as seemingly simple as data encryption. Some of these new approaches have been made possible or even necessary by recent decreases in the price of disk storage, by improvements in network and processor performance, and by new regulatory requirements.
Microsoft has a long history of providing platform- and application-based solutions in this area, such as NTBackup, Exchange Server, and SQL ServerTM backup tools, to name just a few examples.
System Center Data Protection Manager (DPM) 2006 was the first Microsoft standalone software entry in the data protection market; it was one of the first products to offer disk-based data protection, and it remains one of the only such offerings to have been built from the ground up with disk-based backup in mind. Most other offerings were and continue to be tape-based approaches that have been retrofitted for disk.
DPM is a part of the System Center family of products. System Center products are designed to work together in making the day-to-day management of your complex IT infrastructure both easier and more cost effective. System Center solutions are based on automation and best practices derived from the Microsoft® Operations Framework (MOF) and Information Technology Infrastructure Library (ITIL) and can be used at all levels of an organization.
DPM is just one part of the System Center family. System Center Configuration Manager provides configuration management and software delivery. System Center Operations Manager gives you proactive system monitoring and automation. System Center Capacity Planner can be used for capacity planning and what-if analysis of infrastructure deployments. (See microsoft.com/systemcenter for more information.)
System Center Data Protection Manager 2006 provided disk-based backup of File and Print servers as well as WAN-based disk backup of branch offices. It was designed to protect file servers in the datacenter and to get local tape backup hardware out of the branch. But it lacked native support for Microsoft applications and relied on third-party products for long-term archive to tape.
The new version of DPM, System Center Data Protection Manager 2007, builds on this foundation and continues to provide robust disk-based protection of File and Print servers as well as branch offices, but it also adds support for business-critical Microsoft applications such as Exchange, SQL Server, and SharePoint® as well as native support for tape backups. While it's not unusual to see a significant amount of change in a new version, this is especially true in the case of DPM. The second version has added a large number of new features as well as significant enhancements to existing features. In this article, I'll walk you through several of these new and enhanced features and give you a broad look at what you can expect from this exciting new release.

Application and Platform Support
Many backup software vendors take a "peanut butter" approach to application support. They spread their engineering investment across a large number of applications in an attempt to support as many data sources as possible. The result is very basic support for a large number of applications. Rather than attempting to provide limited support for a broad range of applications or platforms, Microsoft has chosen to focus on protecting a few very specific applications on the Windows® platform. This has allowed us to focus our engineering investment on these applications to build an integrated backup and restore experience, which includes features not commonly found in other backup products.
Microsoft Exchange support was the number-one feature request of users of DPM 2006. With this in mind, DPM 2007 introduces support for both Exchange Server 2003 and Exchange Server 2007. Protection occurs at the storage group level with individual storage groups appearing as objects in the DPM UI, which can then be added to protection groups as necessary to enable scheduled, policy-driven backups to occur. Clustered Storage Groups appear as a single object, removing the need to track individual members of a cluster and manually sync up their protection. Restores can occur at the Storage Group, Database, or Mailbox level. Granular recovery is achieved via automation, which uses standard Exchange tools to restore the data to a recovery storage group and then extract more granular objects like mailboxes once again via standard Exchange tools (see Figure 1).
Figure 1 Exchange support in DPM
Figure 1 Exchange support in DPM
Unlike some other Exchange backup solutions, DPM does not rely on non-Exchange tools or reverse engineering the Exchange database when it extracts objects that are then restored. So DPM-based mailbox restores are fully supported by Exchange.
DPM 2007 is the first product to fully support Exchange 2007 Cluster Continuous Replication (CCR) and Local Continuous Replication (LCR) clusters. Exchange 2003 clusters are supported as well.
SQL Server 2000 and SQL Server 2005 are supported by DPM 2007, with both backup and restore occurring at the database level. Support for redirected and renamed restores, as well as full support for clustered, mirrored, or log-shipping databases, is also included.
As with Exchange, clustered databases appear as a single object in the UI, removing the need to configure protection on multiple clustered servers separately (see Figure 2). SQL Server support in DPM can be used to protect a number of third-party applications that rely on back-end SQL Server databases, with support for the application occurring via file protection and the SQL Server database being protected natively via DPM support for SQL Server. The flexible scheduling engine in DPM allows both the file backup and the SQL Server backup to be added to the same protection group so that they occur simultaneously and share a common management and scheduling interface.
Figure 2 Clustering backups
Figure 2 Clustering backups
Collaboration workloads are protected with SharePoint 2007, with Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 both being supported. Support occurs at the farm level, even if that farm spans more than one server. So, for example, a farm consisting of three Web front-end servers, two site collection servers, and a single database server for a total of six servers would appear as a single object in the DPM UI, would be backed up as a single object, and could be restored as a single object by DPM as well.
While full farm restores are supported, DPM also includes support for site, site collection, and individual document, list, or item restores. Older versions of SharePoint can, of course, be protected as SQL Server databases via DPM SQL Server protection features.
File and Print Workloads continue to be supported in DPM 2007, with Open File support available at no additional charge. Support for file and folder exclusions has been added, as well as System State backup support. It's important to note that File support has been further expanded to include Windows Vista® and Windows XP. But support for these client operating systems is relatively limited, as support is mainly aimed at systems that are used as file servers. DPM users are permitted to protect a small number of clients as needed, but this support will not easily scale to larger numbers of desktops.
Native support for Exchange Servers, SQL Server, SharePoint servers and file servers allows DPM to support a vast majority of the workloads found in Windows environments. But for less-common workloads, DPM 2007 also includes support for pre- and post-scripts, which can be run automatically when a backup occurs. This functionality allows DPM to support a wide range of other applications or workloads. Such support is not as integrated as that offered for Exchange, SQL Server, and SharePoint, but it does offer significant flexibility in data source support. White papers detailing how to support some key non-Microsoft products such as Oracle will be available on the DPM TechCenter at technet.microsoft.com/dpm.
One of the more interesting innovations in DPM 2007 is host-based virtual server support. While most backup products are able to support virtual server guests as individual servers, few, if any, are able to provide such protection at the host level via a single license and agent install. DPM leverages recursive volume shadow copy service (VSS) writers to protect all the guests that are hosted on a given virtual server host via a single agent deployed on the host. These recursive VSS writers are able to call VSS writers that live on guests or even in applications that run on guests regardless of what application or operating system is installed on the guest. This allows DPM to protect any platform or application that runs as a guest, regardless of the vendor. Such host-based virtual server backups are application-consistent and result in a single Virtual Hard Disk (VHD) image that can be restored on an existing or new host as necessary.
These host-based backup images don't offer the same granularity of restore as do backups made via a DPM agent installed on the guest or a standalone server, but they do offer other efficiencies including easy system recovery to virtualized environments.

Speed, Reliability, and Efficiency
In addition to improvements in both depth and breadth of application support as compared to the previous version, DPM 2007 allows increased granularity of full and incremental backups. While DPM 2006 allowed you to synchronize up to every hour, the new version of DPM allows you to take an incremental backup every 15 minutes and a full backup every hour. For customers with less aggressive service level agreements (SLAs), full backups may be required only once per week. Thus those customers can reduce the frequency of backups on less critical servers while still allowing for aggressive protection schedules for critical servers. Even though synchronization with the DPM server occurs up to every 15 minutes, the DPM agent is still actively tracking changes on the protected server during the interval between synchronizations.
This new DPM agent continuously tracks block-level changes as they occur on a protected server. This is made possible by an entirely new volume filter developed for DPM 2007 that consists of a bitmap that lives in paged pool memory and includes one bit for every block on the protected volume.
Each time a block is written to in the volume, a bit is flipped in the bitmap. The processor and memory impact associated with this process is lower than with a typical antivirus filter and there is no disk space requirement that scales with the change rate. In fact, the load associated with this filter doesn't scale at all with the change rate. This is very important, as most block-level change tracking schemes generally result in high processor and memory overhead as well as a disk footprint that scales with the change rate. So higher change rates tend to have greater impact, and in some cases very high change rates can result in the system running out of disk space. With DPM 2007, the impact of the volume filter on processer, memory, and disk is the same regardless of the change rate. Whether it's one percent or 1,000 percent, the change rate simply does not impact the low overhead associated with the filter.
Tracking changed data is only one part of the story, however. DPM 2007 also leverages the VSS service on the protected server to create application-consistent backup images that can be recovered reliably. VSS was developed by Microsoft to provide the backup infrastructure for Windows XP and Windows Server® 2003, and to serve as a mechanism for creating consistent point-in-time copies of data (shadow copies). VSS can produce consistent shadow copies by coordinating reads and writes with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware. As a result, VSS is arguably the most consistent and reliable mechanism for producing application consistent backups on the market today. Several features in Windows Server 2003 use VSS, including Shadow Copies for Shared Folders.
Most products that use VSS for application backups create a VSS replica and leave it in place on the protected server to track changes and get an application-consistent image for backup. Unfortunately, keeping the replica in place on the protected server at all times has some significant performance implications, as a copy on write occurs to keep the VSS replica up-to-date each time the application writes to disk. This can create as much as 25 percent processor overhead and has a significant impact on write times.
Since DPM tracks changes via its volume filter, it does not need to keep a VSS replica in place 100 percent of the time. Instead, DPM creates a VSS replica when full backup occurs, then overlays the volume filter bitmap to identify only changed data in the replica. This changed data is moved over to the DPM server, which is used to create a recovery point. The VSS replica on the protected server is then deleted and the volume filter is reset. Block-level change tracking then continues with little overhead and no need for a VSS replica or its associated resource use.
This solution guarantees that recovery points will result in a restorable application image, and it reduces the amount of data moved between the protected server and the DPM server.
With DPM 2007, a full backup does not move a full copy of the data from the protected server to the DPM server. Instead, it moves only the changed data. So a daily full backup on a 100GB Exchange Storage Group with a 10 percent change rate per day would be only 10GB.
This reduction in the size of full backups translates into very efficient storage on the DPM server when a snapshot is created to capture a recovery point. Each snapshot consists of the changed data that made up the last full backup, and it occurs automatically when a full backup is performed. When dealing with applications, these snapshots also include any intervening incremental backups that have occurred.
Incremental backups are essentially log backups in DPM, so every time you take a full backup of an application, the changed data is moved over to the DPM server and is bundled with any intervening log backups to create a single snapshot that contains multiple recovery points. In the case of the 100GB Exchange Storage Group with a 10 percent daily change rate described earlier, if we assume a daily full backup and 15-minute increments, a snapshot would include 10GB of changed data and approximately 5-10GB of application logs. But it's important to realize this 15 to 20GB snapshot would contain up to 97 recovery points!
Full backups must occur at least once per week, and the total number of snapshots is limited to 512 for application servers and 64 for file servers. So, performing weekly full backups and incremental backups every 15 minutes would result in 673 recovery points per snapshot and more than 340,000 recovery points if all 512 snapshots were used. While it's unlikely anyone would ever have a need for so many recovery points on disk, it does demonstrate the flexibility and scalability of DPM with regard to job scheduling and point-in-time recovery.
Including log backups with full backups allows DPM to efficiently store a very large number of recovery points in a very small amount of disk space. But there is some overhead associated with this process, and the process is not technically compression or even single instance storage (SIS), though there are some data de-duplication components to the process, namely the block-level change tracking. Whatever the label happens to be, DPM does a very good job of using a small amount of storage for each recovery point created. More importantly, because DPM does not use traditional compression, single instance storage, or de-duplication to perform this task, there is room for additional efficiencies if a compression, SIS, or de-duplication storage platform is used to provide storage to the DPM server.

Zero Data Loss Recovery and CDP
Perhaps one of the most exciting changes in DPM 2007 is its ability to perform lossless recoveries of Microsoft applications. This is made possible by the block-level change tracking and VSS architecture as well as deep integration with existing application logs on the protected server.
Generally speaking, there are two approaches to data protection and recovery in the market today:
Replication-Based Solutions This is what most customers traditionally think of as Continuous Data Protection (CDP). Replication-based data protection involves moving changes on the protected server over to the backup server as they occur. This is a disk-based solution that purports to allow recovery to any point in time with zero data loss.
While this is a compelling claim, there are a few very real disadvantages associated with this approach. First and foremost, a replication solution has no concept of application state, nor does it have any awareness of the moving parts in an application. So it doesn't flush buffers or account for data that may be in memory or in transit when the backup is occurring. This means that replication-based recovery points are often not application-consistent. You can perform a recovery, but the application doesn't actually come back in a usable state. This issue is so prevalent that some replication-based CDP vendors have notes in their documentation telling you to try another recovery point for an application if the current one doesn't work.
In addition to these application-consistency issues, replication-based CDP solutions are generally quite expensive, have significant network and processor overhead, and require fairly large amounts of storage, which may well be located on proprietary hardware. Replication-based data protection solutions are also not particularly well- suited to archiving or off-site tape backups, both of which are a requirement for many customers.
Snapshot-Based Solutions This is a traditional tape backup approach to data protection in which point-in-time snapshots are created on external media that can then be used for point-in-time recoveries. The recovery point objective (RPO) is determined by the frequency of the snapshots, so a daily backup results in 24 hours of data loss. The advantage of snapshots is that they are cheap, easy to manage, have a more limited impact on the network, and are well-suited to disk or tape archiving. They also tend to result in application-consistent images because you have time to prepare the application prior to the snapshot being taken, so you have less risk that any moving parts of the application will be missed when the backup occurs.
One recent trend in snapshotting is near-CDP solutions. These are snapshot solutions in which the frequency of snapshots is increased so that the RPO becomes very low. Some products now measure their RPO in minutes and take such frequent snapshots that they have dropped the near-CDP moniker entirely and now call themselves CDP products. They still lose some minutes worth of data in the case of a restore, however.
DPM 2006 was firmly in the near-CDP snapshotting camp, but DPM 2007 is unique in its approach to CDP. The new version of DPM takes snapshots up to every 15 minutes using VSS and its block-level change tracking technology to only move the changed data from the VSS snapshot on the protected server. Thus, individual point-in-time snapshots are very small, as they only consist of block-level changes. This is essentially a very advanced snapshotting approach. The new innovation in DPM is deep application integration for Exchange, SQL, and SharePoint. It's so deep that DPM is aware of the app logs and is able to roll forward those logs in the case of a recovery. As long as your app logs are available (they should be if you follow best practices and have them on a separate drive), DPM will be able to roll them forward from the last point-in-time snapshot for a lossless recovery (see Figure 3).
Figure 3 Recovery options in the Data Protection Manager Administrator Console
Figure 3 Recovery options in the Data Protection Manager Administrator Console
In many ways, this hybrid approach to CDP is the best of both worlds. It offers the application consistency and long-term archive support of a snapshotting solution with the zero data loss features of a replication product, while avoiding many of the disadvantages of either solution.

Support for Disk and Tape Backups
No discussion of the new features of DPM 2007 would be complete without mentioning the addition of tape support to the product. DPM 2006 only supported Disk-to-Disk (D2D) backups, with data being moved from disk on the protected server to disk on the DPM server. DPM 2007 includes support for both disk and tape media. Therefore, data can be moved from disk on the protected server to disk attached to the DPM server (D2D), to tape attached to the DPM server (D2T), or protected data can be staged to disk on the DPM server before being moved to tape for long-term retention (D2D2T).
DPM 2007 supports a wide variety of tape libraries and autoloaders, as well as a wide variety of different tape media types.
Tape support in DPM includes many advanced features, such as software-based tape media encryption at no additional cost, as well as basic encryption key management and tape retention and location tracking.

Wrap-Up
I've detailed several of the new features and enhancements found in System Center Data Protection Manger 2007. These features are designed to deliver consistent, reliable, and easily managed data protection for Microsoft platforms and applications, setting a new standard in Windows application and platform data protection.
In addition to the features outlined in this article, there are many more enhancements in the product such as Windows-integrated End User Recovery, flexible bandwidth throttling, and an advanced command-line interface. I encourage you to download the Beta 2 version of Data Protection Manager 2007 to see these and other features at work. For more information and an overview of all the products in the System Center family, please visit microsoft.com/systemcenter. From there you can navigate to any solution in the system center family, including Data Protection Manager.

Calvin Keaton is currently the product planner for DPM. Formerly he managed the Microsoft IT Data Protection service. Calvin had six years of industry experience in datacenter operations and hardware prior to coming to Microsoft, including managing Data Center Site Operations teams for Compaq and, later, HP Services.


 System Center: Online Services Help Simplify Software Inventory
System Center Paul Bourgeau

Online Services Help Simplify Software Inventory
At a Glance:
  • Online services basics
  • Setting up the inventory agent
  • Getting inventory reports

Your CFO just e-mailed, asking you for a "small favor": he needs a complete inventory of all the computers in your organization, where they are located, and what software is installed on each
machine. By the end of the week. He needs this because (pick one or more):
  • It's time to plan the budget for the upcoming year, and he wants to know how much to allocate for software licensing.
  • He's received a notice of a software audit and now has to demonstrate that your organization has enough licenses of a certain product to be compliant.
  • He's been asked by your CEO to reduce IT operations spending, and he's thinking that application standardization is one way to accomplish this.
So what do you do?
IT asset management has evolved over the past decade, and now organizations have shifted focus to the effective management of their software assets. This is primarily because software now represents a significantly larger financial investment than it once did, but there are also growing legal, security, and policy issues that need attention. The possibility of being found to be in a non-compliance situation and facing large true-up fees or fines has further stressed the need for accurate software asset management.
Larger organizations typically have resources and tools in place to manage software. These tools are often large-scale, multipurpose solutions that not only track hardware and software inventory but also manage software delivery to the desktop and monitor performance, along with other operational functions. Where does that leave organizations where such solutions are not viable or where resources and expertise to implement and manage such complex solutions are not available?
Meeting the needs of business both large and small is one of the driving influences behind the concept of software as a service (SaaS). The Microsoft "Software plus Services" strategy encompasses efforts to develop service-based solutions to assist customers in managing software assets effectively. One of the first of these services, Microsoft® Asset Inventory Service, is being released to Software Assurance customers as part of the Desktop Optimization Pack for Software Assurance later this year.
Asset Inventory Service (AIS), shown in Figure 1, provides an easy-to-deploy, easy-to-use hosted service for gathering information about the software installed on computers throughout your organization. You can access this information through browser-based reports, and there are plans for a future version of the service to also analyze the deployment of Microsoft volume license agreements.
Figure 1 Microsoft Asset Inventory Service
Figure 1 Microsoft Asset Inventory Service

The Nature of Online Services
Why adopt an online solution? There are several compelling reasons including immediacy of availability of updates and new versions, ease of adoption, and reduced deployment and management costs.
Online services are dynamic: like a Web page, the content and functionality can be constantly updated by the service provider to enhance the user experience and provide current responses to changes in the technological landscape. This provides an unprecedented level of agility and allows software vendors to deliver up-to-the-minute features, solutions, and knowledge that enable administrators to be more proactive in managing their desktops.
Online services have the benefit of being ubiquitous. In today's IT environments, you find a mix of situations, ranging from fully networked PCs connecting to network resources directly, to remote users and branch offices accessing resources over the Internet from widespread locations. Throw in mobile users who rarely even connect to your network except over Web-based mail programs, and it becomes very difficult to achieve a complete inventory of your IT assets. This has historically been a major challenge for inventory tools, particularly on-premise solutions that won't provide support for remote/non-networked scenarios.
However, most if not all of your PCs have Internet connectivity, so you can use an online service to manage them without implementing special measures to ensure connectivity to in-house client-server solutions. Access to the service to perform the management functions is equally accessible via a secure Internet connection, so you can manage any PC on your managed account from anywhere the Internet is accessible.
Deployment is easy, and you need only create your account with the online system to get started. There are no servers to stand up in your environment and no new network infrastructure and new software platforms to invest in. This all means less administration and financial investment. Ongoing support is also easier, since the organization does not have to worry about maintaining an upgrade path because the service will more often than not include newer versions as part of the service agreement.

Using the Service
Fostering an Online Community
Asset Inventory Service and the System Center Online service are furthering the development of a strong community of users who could influence the evolution of online services. The software catalog is an excellent example of something that a user community could provide input on (in true wiki fashion), and the users of the service could provide suggestions, corrections, and guidance.
In the future, the catalog itself may also be a valuable source of information to end users when they are researching potential software purchases. Aggregate anonymous statistics can be collected from the entire service to determine adoption rates for software and hardware products, and will provide useful data to end users involved in these activities.
The community will also be the voice that guides the overall direction of the service by contributing feedback on what areas should be prioritized to meet specific business needs.

To deliver online desktop management services, Microsoft System Center Online is building out a platform that will not only support Asset Inventory Service in the short term but also future services. The service has been designed with security, scalability, and reliability in mind. AIS is a completely hosted solution, with all servers located at Microsoft datacenters. To deploy the solution, customers must install a small piece of software on each client PC they wish to include in their managed inventory.
Asset Inventory Service is managed by the same people who manage Microsoft.com. It is a multi-tenant Web application that uses Web services to ensure privacy and security of data on a per-customer basis, and uses a combination of client and Web applications to store customer data. Agents running on the customer site upload software inventory to a Microsoft IIS Web service. Mutually authenticated SSL protects the customer data, communication between the client and the service, and the AIS Web site, and the site uses SQL Server™ for storage.
Using Windows Live™ ID accounts for authentication, customers log in to the service to manage their accounts and view reports. The customer Web site also uses SSL to protect the customer data and SQL Server Reporting Services generate reports. The SQL Server databases are mirrored and the Web sites are load balanced for high availability. In addition, the inventory data is partitioned into scale units for high scalability.
You subscribe to Asset Inventory Service by purchasing Microsoft Desktop Optimization Pack licenses on your Microsoft Volume License agreement. You can then activate the Asset Inventory Service subscription from Microsoft Volume Licensing services site at licensing.microsoft.com. To successfully authenticate and log in to the AIS service, you must have a valid Windows Live ID.
During activation, the agreement administrator designates an Asset Inventory Service subscription administrator by specifying her Windows Live ID. The subscription administrator logs in to AIS with her Windows Live ID and finishes the activation process for AIS. She can then subsequently add other users to the service by specifying their Windows Live IDs.

Inventory Agent
The client installed on each PC is a small, easy-to-deploy agent that is packaged as a Windows® Installer (MSI). You can download the agent installer and manage client deployment from the online service. (Figure 2 shows the management and support interface.) The agent operates in a manner similar to the Windows Update agent in that it communicates with the System Center Online servers on a regular basis. This is to update its inventory profile based on a predefined frequency and to self-update if there is a newer version of the agent available.
Figure 2 Account management and client deployment
Figure 2 Account management and client deployment
Inventory is scheduled to run automatically, and no user intervention is required. There is also an option to start a manual inventory if necessary. The first time an agent contacts the service, it uses public key infrastructure (PKI) certificate credentials to present the customer identity to the service and to generate a unique identity for the computer on which the agent is running. The agent itself, which only runs on a scheduled basis, is designed to be unobtrusive for the user, so it takes minimal resources and runs in the background. Uploaded data files are small so as not to cause network traffic spikes.
The inventory process itself is light and efficient. The agent scans registry entries, the MSI database, and other sources to obtain installation information, unlike traditional management systems that intrude on users' productivity by scanning and resolving all executables present on a machine. This process returns software inventory data using friendly names with metadata that assists in the identification and classification of items so they can be used in a broad set of software asset management activities.

Reporting Services
Once inventory data is uploaded, it is put through an identification and cataloguing process that prepares it for display in reports. Inventory data is matched against a central software catalog, where it is categorized. This is one of the most important capabilities of the service: every customer's software inventory data contributes unique signatures to a central software catalog. A team of researchers at Microsoft reviews the non-private, unclassified software signatures and, using a structured taxonomy of software families and categories, classifies the applications they represent according to what the applications are and what they do. These categories aid in providing a higher level of intelligence to reporting by allowing users to quickly focus in on specific types of software they are interested in—for example, maybe you only want to see antivirus applications.
Software signatures also serve to consolidate the data being displayed in reports. For example, a publisher name may have a number of variations—one application may report the publisher name as Contoso Software, while another may report Contoso, which would display them as different in a report. By consolidating publisher and application names, the ability to accurately report by these criteria and present data in a meaningful way is enhanced.
Once the user has arrived at the desired dataset by applying filters and groupings, report contents can be exported in a variety of formats supported through the use of SQL Server Reporting Services, including CSV files, Microsoft Word documents, Microsoft Excel® spreadsheets, and PDF files (see Figure 3). This allows you to perform additional external analysis and manipulation, or can serve as an input to other enterprise management systems.
Figure 3 Reporting inventory results
Figure 3 Reporting inventory results
An upcoming feature in the service will enhance the way Microsoft licenses are handled, making the process much easier for users. Users will be able to upload their volume license agreement pairs, which will then be used to retrieve their license position information from the Microsoft Customer License Position Repository. This license entitlement data will then populate a statement that summarizes all licensable Microsoft software that was found to be installed and the corresponding license quantities.
Using the Product Identifier that is also collected during inventory, the installed software can be further broken out by channel: Volume License, Retail, and OEM. This feature is planned for release in the next version of Asset Inventory Service.

Going Forward
Asset Inventory Service is the initial offering from System Center Online, but by no means will it be the last. As mentioned earlier, System Center Online has the long-term objective of providing total desktop management services, to be completely available as an online service.
Some of the potential offerings under consideration include IT asset management for hardware and software inventory and tracking, software update and distribution providing functionality similar to Windows Software Update Services from the Internet, and online/on-premise hybrid services. A number of other desktop management services are also being investigated to see if they would work in this type of scenario.
To learn more about Microsoft Asset Inventory Service, take a look at microsoft.com/windows/products/windowsvista/enterprise/ais.mspx.

Paul Bourgeau a Program Manager in the System Center Online team, joined Microsoft with the acquisition of Assetmetrix.


 Group Policy: Inside ADM and ADMX Templates for Group Policy
Group Policy Jeremy Moskowitz

Inside ADM and ADMX Templates for Group Policy
At a Glance:
  • Types of group policy templates
  • Proper and improper Policies keys
  • Viewing ADM templates
  • Converting ADM to ADMX

ADM files. You either love 'em or you hate 'em. Or maybe both. That's because they're both necessary and confusing. And now there are ADMX files, a new format that can seemingly only add to the confusion. Well, it's time for me to shed some light on this cloudy subject.

Why Do We Need ADM Files?
Group Policy covers a wide range of areas. If you dive down into the Group Policy Object Editor (GPOE), you'll discover lots of different "stuff" you can do with Group Policy. For instance, you'll find Software Restriction Policy, Group Policy Software Installation, Folder Redirection, and, yes, the one we utilize most: Administrative Templates. The Administrative Templates node appears on both the User and Computer sides. As you'd expect, users can only embrace User-side policy settings and computers can only embrace Computer-side policy settings.
But where do all these magical settings within Administrative Templates come from? When new applications are "born," there are some settings you can potentially manipulate. That's where ADM files come into play. They describe the areas of the application that are ready to accept settings defined by an administrator. ADM files are limited right away, unfortunately, because they can only address Registry settings within an application. But an application might save its settings in other areas such as .ini files, .js files, .xml files, and databases.

In-the-Box ADM Files
So how do all those in-the-box policy settings for Computer Configuration | Administrative Templates and User Configuration | Administrative Templates get there in the first place? If you right-click the words "Administrative Templates" in the GPOE and select "Add/Remove Templates" on either the User or Computer side, you'll see the default templates that make up the standard configuration in Figure 1.
Figure 1 Default Administrative Templates
Figure 1 Default Administrative Templates
The breakdown of these files is:
  • Conf.adm—NetMeeting® settings.
  • Inetres.adm—Internet Explorer® settings, including connections, toolbars, and toolbar settings. These settings are equivalent to the options that are available when you click on the Internet Options menu inside Internet Explorer.
  • System.adm—Operating system changes and settings. Most of the Computer and User Administrative Template settings are in this ADM template.
  • Wmplayer.adm—Windows Media® Player 9 settings.
  • Wuau.adm—Controls your clients' access to Windows® Update and/or Windows Server® Update Services servers.

Adding a New ADM Template File
Overcoming Limitations with Microsoft and Third-Party Tools
ADM and ADMX files are extremely useful. Use them to pack some knowledge into your definition file and control your target application. But ADM and ADMX files have limitations. Specifically, the files cannot perform the following:
  • They cannot reach into Registry hives other than HKEY_LOCAL_MACHINE and HKEY_Current_User. If you have business that you must attend to in other Registry hives, you cannot address it with ADM or ADMX files.
  • They cannot perform additions to REG_Binary values.
  • They cannot be specifically set to "run only once."
  • They cannot be specifically set to "always reapply" during a Group Policy refresh.
  • ADM and ADMX files writing to Improper keys tattoo the Registry. So, even if the user falls out of scope of management (SOM), or the GPO is deleted, the value persists.
To overcome these limitations, Microsoft and some third parties have solutions to assist you. Microsoft recently acquired DesktopStandard and has just released a rebranded version of the DesktopStandard Registry Extension. With this tool, you can dictate which specific Registry values you want to manage on the target machine using a wizard interface within the GPOE.
The DesktopStandard PolicyMaker technologies (including the Registry Extension tool) are now called Group Policy Preferences and are included with Windows Server 2008. Group Policy Preferences enables the administrator to configure applications or Windows components not ordinarily configurable via Group Policy, as well as apply to certain users or computers based on a very rich set of targeting rules. Group Policy Preferences are fully integrated with the Group Policy Management Console and Advanced Group Policy Management in Windows Server 2008.
You can read more about Group Policy Preferences in Derek Melber's article, "Dive into Advanced Group Policy Management," in this issue of TechNet Magazine.

This is an easy one. First, get the ADM template you want to use. You could use one that you've downloaded from GPanswers.com (we have about a dozen interesting ones), or maybe you want to utilize the ADM files for Office 2003 or Office 2007 located on the Microsoft Web site.
Just right-click the words "Administrative Templates" and then click "Add," as shown in Figure 1, to add in the template. By default, Windows looks for templates in the \Windows\inf directory, but there's no reason you can't store them wherever you'd like. Here's something you may not be aware of: once the ADM template is added from the original storage point, that ADM template also gets added to the contents of the Group Policy Object (GPO) itself.
For instance, for this article I went to GPanswers.com and downloaded nopassport.adm. I originally housed this template file in my c:\temp directory. This ADM template allows us to squelch the "Do you want to add your passport?" message that happens the first time a user logs into a machine running Windows XP.
I also downloaded the Office 2003 ADM templates and stored them in c:\temp. But they won't stay in that directory. In Figure 2, you can see that I've added nopassport.adm and Word11.adm. You can see these have been added to the list of default templates in the "Add/Remove Templates" window.
Figure 2 Additional ADM files in the GPO
Figure 2 Additional ADM files in the GPO
Now, if you look inside the file-based portion of the GPO itself (specifically, in the \\domaincontroller\SYSVOL\domainname\Policies\GUID\ADM directory), you can see that the nopassport.adm and Word11.adm files are now part of the GPO, as shown in Figure 2.
Why are these templates added to the GPO? Because if you then try to edit this GPO on another management station, you'll be able to see the settings contained within the ADM files.

Why Can't I See What I Just Loaded?
Sometimes you can see your ADM file additions and sometimes you can't. And this is causing a lot of confusion for a lot of administrators. Indeed, this is a very common question on GPanswers.com, so let's clear it up right now.
You should at least be able to see the results of adding the two templates (see Figure 3). Two new nodes will appear: Computer Configuration | Nuisances (because of nopassport.adm) and User Configuration | Microsoft Office Word 2003 (because of Word11.adm). If you dive down into the Microsoft® Word 2003 settings, you'll see quite a huge array of configurables, as indicated in Figure 3.
Figure 3 Configurable group policy settings
Figure 3 Configurable group policy settings
But why can't you see the settings in the new Nuisances node? To understand that, you first need to understand the idea of "proper" versus "improper" Policies keys that an ADM template might affect.

Proper vs. Improper Policies Keys
Microsoft documentation states that four Registry areas are considered to be the approved places to create policies out of Registry hacks:
  • HKLM\Software\Policies (computer settings, the preferred location)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (computer settings, an alternative location)
  • HKCU\Software\Policies (user settings, the preferred location)
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (user settings, an alternative location)
The settings that are contained within the Word 2003 ADM file write to these proper locations, but the nopassport.adm file doesn't—nopassport.adm writes to HKLM\Software\Microsoft\MessengerService\PassportBalloon.
The GPOE puts up a little safety gate before it allows you to see these settings because the settings that don't write to these four proper Policies keys will tattoo the Registry. So, even if you whack the GPO, there's no way the setting will revert back. For example, let's say you added the nopassport.adm file and chose to squelch the "Do you want to add a passport?" pop-up balloon for every machine in your domain. Then, later, the boss said he really enjoyed getting that pop-up balloon. In that case, you've got a long road ahead of you because all computers now will embrace the setting—basically forever—until you expressly put that setting back. And, yes, it's possible to create a new, custom ADM just for this purpose, but, again, it could be a long road.
In contrast, regular policy settings have a default value. And if you whack the GPO, those settings will revert back to the default. For instance, if you choose to prohibit access to the Control Panel using the built-in ADM templates, then later change your mind, all you need to do is whack the GPO and access to the Control Panel comes back. This is true for just about every setting that ships with the default ADMs (there are some oddball exceptions).
Again, with the custom passport squelch ADM, the site where the policy setting is placed doesn't enable the Group Policy engine to revert it upon deletion. So Microsoft protects you by (initially) not showing these tattooing policy settings at all so you don't shoot yourself in the foot!

Seeing ADM Templates
So, seeing the ADM templates isn't all that hard. The editor, by default, doesn't show you the settings, but it's easy to fix that. Click on "Administrative Templates" (on either the User or Computer area), then select View | Filtering. Finally, uncheck (yes, uncheck) "Only show policy settings that can be fully managed" (which can be seen in Figure 4). When you do this, you'll see the policy setting "Passport Solicitation" show up under the Setting column, also seen in Figure 4.
Figure 4 GPO filtering
Figure 4 GPO filtering

Windows XP vs. Windows Vista in the Editor
Did you notice a subtle difference in the policy setting that just popped up? Look at the icons of the policy settings that ship with the ADM files out of the box in Figure 5. Now, look at the icon for a policy setting from an ADM template where the settings don't write to the proper Policies Registry keys, as shown in Figure 6.
Figure 5 ADM files with icons
Figure 5 ADM files with icons
Figure 6 Icons for improper key usage
Figure 6 Icons for improper key usage
This blue versus red icon differential helps you know which settings will tattoo and which won't. But again, it's all based upon where the setting actually performs its duty.
In Windows Vista®, by the way, the situation changes a bit when you use ADM files in your Windows Vista management station. ADM files show up in their own node called the "Classic Administrative Templates (ADM)" node, as seen in Figure 7. What were red-dot settings now show up as scroll icons with a down arrow (but while editing the setting itself, it has a little "No Enter" sign).
Figure 7 Classic Administrative Templates node
Figure 7 Classic Administrative Templates node
The settings that were blue-dot (those that write to the proper Policies keys) show up as little scroll icons, as seen in Figure 8.
Figure 8 Scroll icons showing proper keys
Figure 8 Scroll icons showing proper keys

What's All the Hubbub about ADMX?
Windows Vista and Windows Server 2003 each ship with a new, built-in Group Policy Management Console (GPMC). And with that new GPMC comes a new ability to shake off the use of old ADM files to make room for newer ADMX files if you want to do that. Why would we want to shake off the ADM format?
Recall that the ADM file itself is placed up inside the Group Policy Template (GPT) part of the GPO (the part that lives in SYSVOL). When that happens, you burn about 4MB on every domain controller (DC) every time you create a GPO. Also recall that the ADM file itself is placed in the GPT of the GPO because it's necessary when you want to re-edit the GPO on another management station. Without that ADM file, you can't edit any custom settings contained within the GPO.
So, the ADMX format helps us break away from these issues. You no longer need to store anything inside the GPO directly, so you don't get what's known as "SYSVOL bloat"—that is, a fat SYSVOL that must store GPOs full of ADM files and has the burden of replicating them to every DC. To work around this, the new ADMX standard can take advantage of what's known as the "Central Store." The job of the Central Store is to have one location where you can place the new ADMX files so they don't need to get copied into each and every GPO. So, goodbye SYSVOL bloat. The other big deal about the Central Store is that if an ADMX file has an updated definition, then all Windows Vista management stations will immediately use that updated ADMX file.
If you want to learn about the format of ADMX files, specifically the creation and use of the Central Store in detail, I've got two resources for you. Darren Mar-Elia wrote an informative article on ADMX file format internals and a brief explanation of the Central Store in the February 2007 issue of Technet Magazine (technetmagazine.com/issues/2007/02/Templates). I also have an entire downloadable chapter from my latest book, Group Policy: Management, Troubleshooting, and Security, available in the "Book Resources" section of GPanswers.com.
As I explained, ADM templates are still supported when you use a Windows Vista management station, but ADM files are not supported within the Central Store. This can be a little confusing, so let's take a walk through an example.
Let's assume I just created a GPO from a Windows Vista management station and then tweaked some of the in-the-box settings (like Prohibiting Access to the Control Panel). Now, let's also assume I wanted to add a custom ADM template. After doing so, let's peek into the GPO's GPT and see what has happened to get some clarity.
To add the ADM template, you can repeat some steps I performed earlier. Just open up the GPOE, right-click "Administrative Templates," which is contained within both the Users or Computers node, and select "Add/Remove Template." You can see the added template in Figure 9.
Figure 9 Viewing the added template
Figure 9 Viewing the added template
In order to actually see the settings contained within this ADM template, you're going to need to do what we did earlier in Figure 4. That is, click on View | Filtering. Finally, uncheck "Only show policy settings that can be fully managed." Then, close the GPOE and return to the GPMC. Figure 10 shows the Details tab of the GPO I just created from my Windows Vista management station. (Note the catchy name of the GPO.) By looking in the Details tab, I can determine the GUID for the GPO, which will make it easier when I go sleuthing around in SYSVOL to find that particular GPO.
Figure 10 Default Administrative Templates
Figure 10 Default Administrative Templates
Once I track down the GPT of the GPO (by using the GPO's GUID), I can crack open that GPO's ADM directory and see that there's exactly one ADM template here—the one that I manually imported, shown in Figure 11. This is because Windows Vista machines don't rely on ADMs anymore. Since they don't natively use them, they don't natively push anything up into the GPO itself. However, if you manually import an ADM (as we just did), it will continue to honor the ADM in the same fashion that previous versions of Windows did.
Figure 11 Manually imported ADM file
Figure 11 Manually imported ADM file
This is in contrast with, say, the GPO in Figure 12, which was created on a machine running Windows XP or Windows Server 2003. When GPOs are created using pre-Windows Vista management stations, the original ADM files are pushed up into the GPO, as I previously described. This GPO was created on a Windows XP management station. You can tell because it's jam-packed with ADM files that Windows Vista doesn't need or use.
Figure 12 GPO created on Windows XP
Figure 12 GPO created on Windows XP

Converting ADM to ADMX Using the ADMX Migrator Tool
So Windows XP uses ADM files and Windows Vista uses ADMX files, although Windows Vista will continue to support ADM files if that's what we have available. However, we cannot stick an ADM file into the Central Store and expect our Windows Vista management stations to be able to make use of the file.
In order to utilize the settings contained within the ADM in the Central Store, you would need to convert the ADM file to ADMX, or re-create the ADM files as ADMX files by hand. Luckily, there's a single download that performs both of these functions. The ADMX Migrator tool (which is really composed of both an ADM-to-ADMX converter tool and an ADMX creation tool) can be downloaded at go.microsoft.com/fwlink/?LinkId=103774.
You can install the ADMX Migrator Tool MSI file on Windows Server 2003, Windows XP, or Windows Vista. Once installed, the applications can be found in the C:\Program Files\FullArmor\ADMX Migrator directory. The command-line application I'll be running is called faAdmxConv.exe. But since the directory isn't in the path, you would need to be in that directory in order to run the application. Therefore, when I'm using the tool, I opt to add this directory to my Windows path. The article at www.computerhope.com/issues/ch000549.htm explains how to set the path in Windows.
I usually create a temp directory such as C:\ADMtemp and copy my source ADM files into it. There are a lot of possible parameters for faAdmxConv.exe, but the simplest way to convert an ADM file is to specify the name of the ADM file and the output directory. If you've already gone ahead and put the source ADM file in ADMtemp and added faAdmxConv.exe to the path, you can just run "faAdmxConv nopassport.adm ." (with the dot at the end to signify the current directory as output). If you don't specify the dot (for this directory) or another explicit path, the output goes to the temp directory within your account's profile. In Figure 13, you can see three commands:
Figure 13 ADMX Migrator tool
Figure 13 ADMX Migrator tool
  • A "dir" command to see the ADM file
  • The "faAdmxConv" command with the name of the ADM and the . (dot) to represent the current directory
  • A "dir" to see the outputted files: nopassport.admx and nopassport.adml
Before you go plunking the resulting files directly into your Central Store, you might want to test this on a machine that is running offline. After you take the machine offline, copy the ADMX file to the C:\Windows\PolicyDefinitions directory and the ADML file to the language-specific directory. In the U.S., that directory is C:\Windows\PolicyDefinitions\en-us. An example of the copy procedure can be seen in Figure 14.
Figure 14 Copying ADMX files to the Central Store
Figure 14 Copying ADMX files to the Central Store
The ADM-to-ADMX converter tool was recently updated to version 1.2. This corrects a number of conversion bugs and adds useful warning messages during conversion time. If you've tried the ADM-to-ADMX converter tool in the past, but gave up due to error messages you couldn't correct for, I would encourage you to try it again with the 1.2 version now available for download.
Finally, the converted ADM file is now really two files: an ADMX (language-neutral) file and an ADML (language-specific) file. At this point, you can put the resulting files inside the Central Store or test them on a local machine. However, once again, in order to actually see the policy settings contained within this ADMX template, you're still going to need to do what we did back in Figure 4. That is, you'll still need to click on View | Filtering, then uncheck "Only show policy settings that can be fully managed." That's because the settings contained within this ADMX file do not write to one of the proper Policies keys I discussed previously.

Cleaning Up Shop
The ideal state is clearly to use only ADMX files and to utilize the Central Store. But in order to do that you need to convert all of your current ADM files to ADMX, convert all management stations to Windows Vista (or Windows Server 2008), and make a commitment to stop editing GPOs on pre-Windows Vista machines.
If you've completed these three steps, you have more or less banished ADM files from your world. At this point, the ADM files within your GPOs are just taking up space within your DC's SYSVOL. Once you're achieved ADMX nirvana, you could, if you wanted, simply delete the ADMs contained within the GPO's GPT within SYSVOL. That's right: like your body's appendix, they're vestigial. They did serve a purpose at one point, but no more. You can either do this manually or with a script. But before you do this, note that it would be a serious mistake if these steps haven't been completed. So be sure to do this only if you're sure you can leave ADM files behind.
For additional information on ADM, ADMX, and ADML files, see the Managing Group Policy ADMX Files Step-by-Step Guide at go.microsoft.com/fwlink/?LinkId=105019 and the ADMX Technology Review at go.microsoft.com/fwlink/?LinkId=105032. Also, be sure to sign up for the GPanswers.com newsletter, at GPanswers.com/newsletter, and intermediary notices via blog at GPanswers.com/blog.

Jeremy Moskowitz MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. He also runs a series of Group Policy-intensive training courses. Jeremy's latest book is Group Policy: Management, Troubleshooting, and Security (Sybex, 2007). Contact Jeremy at www.GPanswers.com.


 Group Policy: Optimizing Group Policy Performance
Group Policy Darren Mar-Elia

Optimizing Group Policy Performance
At a Glance:
  • Monolithic vs. functional GPOs
  • How to process group policy entries
  • What happens when GP changes occur

I am frequently asked the question, "From a performance perspective, is it better to have fewer, bigger GPOs or a lot of smaller ones?" That question and others related to Group Policy design and performance are the focus of this article. And, as with most sweeping questions,
I can tell you the answer in advance: "It depends." While this may seem evasive, my goal is to illuminate the mechanisms that underlie Group Policy processing so you can make informed decisions about your Group Policy design, regardless of whether you are just starting out or looking to optimize an environment with hundreds of existing GPOs.

Monolithic vs. Functional GPOs
Let's start by describing the different ways you can implement your GPOs. The terms "monolithic" and "functional" refer to how you design them. Monolithic GPOs contain settings from many different areas. For example, a monolithic GPO might contain settings from Administrative Templates, Internet Explorer Maintenance, and Software Installation policies—all within a single GPO. By contrast, functional GPOs typically do one thing. For example, a functional GPO may do only Software Installation or enforce Security settings. I've even seen functional GPOs that contain only one policy setting! But that is probably the extreme. Figure 1 shows some of the advantages and disadvantages of each approach.
Figure 1 Comparing monolithic and functional GPOs (Close Figure 1)

Issue | Monolithic GPOs | Functional GPOs
Delegation/Isolation | Difficult, since each GPO can contain settings from multiple areas, and you can only delegate at the GPO level, not the settings level. | Easy, since each GPO contains a single policy area, you can delegate, for example, the software installation GPO to the deployment administrator, the security GPO to the security officer, and so on.
Manageability & Complexity | Potentially simpler and easier to manage, because each GPO contains all settings in a single place. | Potentially more difficult because more GPOs mean more places to look to track down problems and more complexity determining the resultant set of policy for a given user or computer.
Performance | Potentially slower because, for a given client-side extension, if one GPO changes, all extensions would need to run against all GPOs in scope. | Depends upon how many GPOs are in use, and how often they change. Performance could be better in dynamic environments compared to monolithic GPOs.
As you can see, there is no cut-and-dried answer to which approach—monolithic or functional—is best in all cases. In your environment, you will likely need both. For example, you might find the functional approach preferable when you are creating security policy for your entire domain. Having a single GPO that contains only security settings makes it easy to delegate control of that GPO to your security administrators where no one else can touch it. By the same token, if you delegate GP administration to OU administrators, then establishing one monolithic GPO for each OU gives those administrators a single place where they can go to manage all of their policy settings. That can reduce complexity for them and allow you to moderate the number of GPOs created for a given OU's users and computers.
How do these high-level design decisions affect the performance of Group Policy processing, and how can you make smart decisions about GP design that minimize performance impacts? The first step in maximizing the performance of your Group Policy infrastructure is understanding how Group Policy processing works under the covers.

Understanding Group Policy Processing
Group Policy processing is a complex set of interactions involving many pieces of your Windows® and Active Directory® infrastructure. At a high level, there are two parts to Group Policy processing. The first is called Core, or Group Policy Infrastructure processing. In this phase, a Windows Group Policy client queries its closest domain controller to determine what the link speed to the DC is, where it lives in the Active Directory hierarchy (that is, which site, domain, and OU the client is a member of), and which GPOs apply to the computer or currently logged-on user. (It's important to note that in this context a client could be a server or workstation participating in an Active Directory domain.) Once the list of GPOs has been created, the next phase kicks in—Client-Side Extension (CSE) processing. During the CSE phase, each registered CSE processes the list of GPOs that have implemented settings in its area. For example, the Registry or Administrative Template CSE runs first in all cases and processes all GPOs that apply to the given computer or user and that have implemented registry policy within them.
The list that follows details the steps the Group Policy processing cycle goes through, including network interactions between the client and domain controller. It's important to remember that Group Policy applies to both computers and users. Therefore, each time policy processes—for example during a background refresh of Group Policy—the cycle I enumerate below will be repeated for both the computer and the currently logged on user account on a given system, since each can have a different set of policies applying to them. When this happens, Windows actually performs the processing cycle simultaneously for both computer and user, with each cycle running on a different thread within the Group Policy engine process. (The Winlogon process for Windows 2000, Windows XP, and Windows Server® 2003, and the Group Policy Client service in Windows Vista® and Windows Server 2008.)
Processing a GP is a six-step procedure:
  1. The client performs Internet Control Message Protocol (ICMP) slow-link detection to a domain controller in its site to determine link speed. In Windows Vista, the use of ICMP for slow-link detection is replaced by the Network Location Awareness (NLA) service.
  2. The client reads CSE status information from its local registry to determine which GPOs were processed last.
  3. The client uses LDAP to search the gpLink attribute in Active Directory on each container object within its location in the Active Directory hierarchy—first at the OU level (including all nested OUs), then at the domain, and finally at the Active Directory site level. From the results of this search, it builds a list of GPOs that must be evaluated for processing.
  4. Each GPO is then searched in Active Directory to determine whether the client (user or computer) has the necessary permissions to process it. Its version number, the path to the Group Policy Template (GPT) portion of the GPO in SYSVOL, and what CSEs are implemented in that GPO are also evaluated.
  5. The client then uses the Server Message Block (SMB) protocol to read the contents of the GPT and get the GPO's version number from the gpt.ini file. The version numbers in the Group Policy Container (GPC) and GPT are one factor that is used to determine whether a GPO has changed since the last processing cycle.
  6. Each CSE runs in the order that is registered under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions, and processes the GPOs that implement that CSE if the GPO has changed since last processing cycle (as determined during core processing). Each CSE also logs Resultant Set of User Policy (RSOP) data to Windows Management Instrumentation (WMI) during each refresh, if available.
Let's dissect this process and look at how performance can be impacted. The first thing to realize is that there is a difference between foreground and background processing. Foreground processing occurs for computers during a system restart and for users during a user logon. Background refreshes occur on workstations and member servers by default every 90 minutes plus up to 30 minutes in a randomized value. Background refreshes occur on domain controllers every 5 minutes by default. In Windows Vista, you can also have NLA-based refreshes, which are essentially background refresh events that are triggered by a previous failure of Group Policy processing due to the lack of access to a domain controller (as when the client was offline when a background interval occurred). Why are these distinctions important? Primarily because certain CSEs (for instance, the Software Installation and Folder Redirection CSEs) will not run during a background refresh. Likewise, logon/logoff or startup/shutdown scripts do not run during a background refresh.
Similarly, in Step 1 of this process, I mentioned the slow-link detection process. In pre-Windows Vista systems, this process relies on clients using ICMP to ping the domain controller to determine its availability and link speed. If the calculated link speed falls below a certain threshold value (the default is 500Kb/s) the link is considered to be slow and, again, certain CSEs, such as Software Installation, Folder Redirection, and Internet Explorer Maintenance, will not run. All of these conditions can have an impact on performance as well as on the expected delivery of policy.
Probably the aspect of the policy processing cycle with the greatest impact on performance is the logic that determines whether GPOs applying to a computer or user have changed. The Group Policy engine has a built-in optimization that says that if nothing has changed for a computer or user since the last time GP was processed, then no processing occurs. This can obviously have a tremendous impact on the time it takes your clients to process policy, especially if your GP environment is fairly static. Let's look in more detail at what constitutes a change.

When Group Policy Change Occurs
So, what constitutes a change in terms of Group Policy processing? There are a number of factors but the most obvious is that if you make a change to a GPO, clients processing that GPO will detect the change and reprocess that GPO. How does a client know that a GPO has changed? It relies on version numbers on the GPO and within the client to figure it out.
A GPO is composed of two pieces—the GPC stored in Active Directory under the CN=Policies, CN=System container within each domain, and the GPT stored in SYSVOL under the "Policies" folder. Each piece of the GPO contains a version number. For the GPC, this version number is stored in the versionNumber attribute on the GPC object. For the GPT, it's stored within the gpt.ini file at the root of a given GPT. The client also keeps a record of the version numbers of the GPOs it has processed (both per-computer and per-user) within its registry. This version information is held under HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History for the computer and HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User> for the user on each client.
When Group Policy processing occurs, one of the parts is to examine the version numbers of all GPOs that the computer or user are subject to and compare them to any processed during the last cycle, as found in the registry. If any of the version numbers of the current GPOs are different (note that they only have to be different—they could be bigger or smaller!), those GPOs will be processed during the current processing cycle. If not, they are not processed unless one of the other change conditions are met. Those other change conditions are as follows:
  • A change in the list of GPOs that apply to a user or computer (a GPO has been added or removed)
  • A change in the security group membership of a user or computer
  • A change in a WMI filter linked to a GPO (a WMI filter has been added or removed)
If any of these change conditions are met, the client will reprocess policy during that cycle. But there are subtleties in this process that you need to be aware of, since they can have a significant impact on performance. For a given CSE, if 1 GPO out of 10 changes, then all GPOs must be processed for that CSE. Remember that processing happens on a per-CSE basis. However, CSEs must process policy in the order of precedence that controls processing (local GPOs first, then site-linked GPOs, then domain-linked GPOs, then OU-linked GPOs). Given this requirement, let's say a user has 10 GPOs that apply, each linked at different levels of the Active Directory hierarchy. And let's say that each of those 10 GPOs implement some Administrative Template policy settings. Now, an administrator comes along and changes a GPO linked to the domain—adding a new Administrative Template policy setting. Then the computer or user goes to process policy and notices that the version number of that changed GPO is greater than the last time it was processed, so the GPO needs to be processed again. But in order to maintain the order of precedence of GP processing, it must process all of the Administrative Template settings that apply to all of the GPOs. So a simple change to one GPO can have a potentially significant performance impact for that client.

Comparing Performance of Monolithic and Functional GPOs
Now that we've looked at the processing cycle and at how changes to your Group Policy environment impacts processing, let's loop back to our discussion of monolithic versus functional GPOs and how each approach impacts performance.
Monolithic GPOs can have a hidden performance penalty due to the way Group Policy versioning works. The reasons for this are not altogether obvious, but they have to do with the fact that there is no concept of per-CSE versioning within Group Policy processing. Let's say a user has three GPOs that apply to him. Each GPO is monolithic in that it implements several policy areas. For example, let's assume that each GPO implements Administrative Template policy, Software Installation policy and Folder Redirection policy. Now let's say that an administrator makes a change to Administrative Template policy in one of these GPOs. Its version number is advanced by that change. Then the user comes along and processes Group Policy. The Administrative Template CSE starts up and sees that one of the GPOs has changed, so it processes those three GPOs again.
When the Software Installation and Folder Redirection CSEs run, they also look at the GPO version numbers and notice the new version number on one of the GPOs. But because that version number doesn't tell them about what policy area was changed in that GPO, they go ahead and process all three GPOs again, just in case. The result is that, in a monolithic GPO implementation, making changes to one area of policy can cause processing activity in another area.
True, in the case of software installation or folder redirection policy, those CSEs may not actually perform any work because, for example, if an application has already been installed it's not going to be installed again. But the point is that this behavior can happen with any CSE and should be taken into account when you are designing monolithic GPOs. If you have a policy area that changes frequently, you might consider keeping GPOs that implement that policy area separate from other policy areas.
From a functional GPO perspective, the performance considerations are more obvious. If you have more GPOs per user or computer (because the functional approach typically involves more GPOs for a given set of policy settings), it means that the Group Policy engine has to spend more time enumerating those GPOs during the core phase of Group Policy processing. However, as we'll see in the next section, this may not necessarily impact performance in a significant way.

Measuring Group Policy Performance
Ultimately, in order to make good decisions about the performance of your Group Policy infrastructure, you need to be able to measure how Group Policy is performing in your real-life environment. Modeling or predicting Group Policy performance is nearly impossible, given the large number of factors that can impact a given processing cycle. For that reason, empirical measurement is your best bet for discovering if GP processing performance is a problem. What constitutes bad performance? Well, bad performance is any situation where Group Policy processing impacts your users' experience on their systems. This may be different for every organization, but the key is knowing you have a problem.
So how do you measure the duration of a given Group Policy processing cycle? Well, again, the answer is not simple. If you are running Windows Vista or Windows Server 2008, you can take advantage of the new Event Viewer Operational Logs. The Group Policy operational log within the Event Viewer, found under Applications and Services Logs\Microsoft\Windows\Group Policy\Operational, provides excellent instrumentation of each step of the Group Policy processing cycle, including time spent during each phase of processing (see Figure 2).
Figure 2 Group Policy Operational Log Event showing policy processing time
Figure 2 Group Policy Operational Log Event showing policy processing time
However, if you are not working in a Windows Vista or Windows Server 2008 environment, the mechanisms for measuring policy processing times are less direct. In that case, your choices are to enable verbose userenv logging (see the Microsoft support article at support.microsoft.com/kb/221833) and view the timestamps within that file for a given processing cycle, or to use the values held in the registry on the client that indicate start and stop times for policy processing. These values are stored in the following for the computer
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}
and here for the user:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}
The values are stored in FILETIME format and must be converted to a normal date and time. You can also use the free GPTime.exe utility I wrote (available at gpoguy.com/tools.htm#GP_Time_Utility) to get the same information.
If you don't have a Windows Vista or Windows Server 2008 environment, but do have access to a userenv log, you can still get valuable information about how much time has been spent in each policy processing cycle. For example, Figure 3 displays a snippet of the userenv log showing part of the core phase of Group Policy processing.
Figure 3 A portion of the userenv log
Figure 3 A portion of the userenv log
Note that each line of the log file includes a timestamp. The core part of the Group Policy processing cycle begins when you see an event that says something like "ProcessGPOs: Starting user Group Policy (Background) processing ..." The CSE part of the processing cycle begins when you see the line "ProcessGPOs: Processing extension Registry." You can use this log and the timestamps within it to determine how long each part of a policy cycle takes.

General Observations on Performance
When you spend enough time looking at userenv log files, you begin to see patterns emerge, and though you can't predict how long policy processing will take, you can start to make some general observations about where time is spent in a given processing cycle. For example, during a policy processing event, when policy changes are being processed and CSEs have work to do because of a change, the time spent in the core part of GP processing is typically much smaller compared to the CSE part.
This is true for most policy areas because most CSEs need to perform tasks that run longer than the core portion of their processing, whose most expensive operations are querying Active Directory and SYSVOL. For example, there's no comparison between time spent in core processing versus the Software Installation CSE running a Microsoft® Office install. However, for a normal background refresh of policy where nothing has changed since the last cycle, the core part of the processing cycle takes roughly the same time as the CSE portion. The exception to this is registry policy processing—which is actually fairly fast unless you have tens or hundreds of registry policy settings in place for a given user or computer.
In addition, disabling the computer or user side of a GPO because it is unused has little effect on policy processing performance. If a policy side is unused, the only overhead will be in querying Active Directory to determine that, and the same query must be performed to view the disable option as the one that occurs to determine whether any CSEs have been implemented for that side of the GPO. The effect of disabling a side is negligible.

Design Recomendations for Optimal GP Performance
Now that we've looked at many aspects of Group Policy processing performance, there are some design recommendations that can directly impact performance. These are summarized in four key points.
  1. If you are making frequent changes to your GPOs, keep in mind the effect mentioned earlier, where a change to one CSE can impact the processing of all CSEs. To that end, if you plan to make frequent changes to, for example, registry policy, it makes more sense to put your registry policy into functional GPOs (GPOs that only do registry policy) as that will isolate other CSEs from processing when changes occur.
  2. When thinking about how many GPOs are too many, keep in mind that policy processing only occurs during changes, and "expensive" CSEs like Software Installation, Folder Redirection, or handling a large number of registry policies or setting permissions on large file or registry trees take up the most time. The time spent querying Active Directory for the list of GPOs during core processing is often the smallest part of the processing cycle. So, 30 GPOs that apply to a given user but do minimal registry policy changes and don't change frequently could take less time to process than 5 GPOs that are running expensive CSEs on a regular basis because those GPOs are changing frequently.
  3. Avoid behaviors that force obvious slowdowns in policy processing performance. For example, you can set policy to force CSEs to process even if a GPO has not changed (under Computer Configuration\Administrative Templates\System\Group Policy). However, if you do this, expect policy processing to take longer during each cycle.
  4. Keep in mind the trade-offs of disabling Fast Logon Optimization in Windows XP and Windows Vista (this is done by enabling the policy at Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and user logon). When this policy is enabled, foreground processing switches from asynchronous to synchronous. This means that computer and user policy must run to completion before the user gets control of the computer and desktop. However, it can also be beneficial because it gets around the problem of requiring two or more restarts or logons for Software Installation and Folder Redirection policy to take effect.

Wrap-Up
While Group Policy processing performance is not an exact science, there is some insight you can bring to your design process that can mitigate performance issues.
Understanding how the processing cycle works and where time is spent can go a long way toward tracking down performance issues. Use the Windows Vista or Windows Server 2008 Operational logs (or userenv logs in earlier versions of Windows) to get instrumented information about the processing cycle. Keep in mind the vagaries of CSE processing and what constitutes a change in policy from a CSE perspective. And remember that, in dynamic environments with lots of changes, functional GPOs may make more sense than monolithic ones. But the bottom line is that Group Policy is a technology designed to help you better manage your Windows environment. It's very important that your business needs drive your Group Policy design rather than the other way around. Keeping in mind some of the performance behaviors discussed here can help you accomplish that goal.

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


 Group Policy: Dive into Advanced Group Policy Management
Group Policy Derek Melber

Dive into Advanced Group Policy Management
At a Glance:
  • AGPM installation and architecture
  • Offline editing of GPOs
  • Change management with AGPM
  • Disaster recovery

Microsoft very recently acquired DesktopStandard, a company that created a product that enables full management of Group Policy Objects. In my opinion, every enterprise that uses Active Directory should be running this tool—Advanced Group Policy Management (AGPM).
AGPM provides for offline editing of Group Policy Objects (GPOs), change management, workflow of updating policies, delegation, and much, much more. In this article, I'll delve into the inner workings of the tool, giving you an in-depth view of this amazing, exceedingly useful product.
Let me first give a little background. AGPM was initially known as GPOVault. After acquiring DesktopStandard, Microsoft renamed it AGPM and added it to the Microsoft® Desktop Optimization Pack (MDOP). You can currently only get MDOP if your Windows Vista® desktop licenses are covered by Microsoft Software Assurance.
Based on my experience with the tools included, I think the MDOP is by far one of the most impressive offerings from Microsoft in recent memory. MDOP comes with five different tools, each of which is impressive individually, and together they create a most remarkable and valuable toolset. For more information about MDOP, please refer to the MDOP Web site: windowsvista.com/optimizeddesktop.

AGPM Installation and Architecture
AGPM installation has been designed to be very slim and easy—it consists of a server component and a client (administrative) component. The server component should be installed on a member server in the domain; it does not alter Active Directory®, the schema, or any other directory service. AGPM can be installed on a domain controller if the situation requires it.
The server installation will install a service that requires a domain-based service account from which AGPM accesses the live production Group Policy Objects on the behalf of the user. The installation also requires that there be an AGPM Admin, which will control all of the settings within AGPM, such as delegation and initial GPO management.
The client must be installed on a computer running Windows Vista where normal administrative functions already occur, most likely on the desktop of the administrators of the network and Active Directory. The client now needs to point the AGPM settings to the AGPM server and the connection to the archive is made. The AGPM client uses the Group Policy Management Console (GPMC) interface and shows up as the Change Control node, as shown in Figure 1.
Figure 1 AGPM is fully integrated into the GPMC for ease of use
Figure 1 AGPM is fully integrated into the GPMC for ease of use
The files that the AGPM client will access are stored in a basic file format on the AGPM server. This is the simplest method for storing these files and makes for easy backup of the entire AGPM archive. Most AGPM functions use the built-in GPMC APIs, which again makes for seamless integration and use of the product. AGPM does not use a database; it stores the GPOs in a single folder and a manifest controls the correlation of all GPOs to the parent GPO within the archive. This ensures that all GPOs have a unique GUID, but when placed into production, the correct GUID is associated with the GPO at deployment.

AGPM Offline Editing
The most basic feature of AGPM is the ability to take the editing of GPOs offline, away from the production environment. It is a well-known issue that editing the GPOs using the default GPMC can result in errant settings being immediately pushed into the production environment, potentially causing disastrous results.
The APGM handles editing of GPOs offline by "controlling" the GPOs. A controlled GPO, as shown in Figure 2, is one that can be edited offline without causing any intrusion on the production environment.
Figure 2 Controlled GPOs are stored in the AGPM archive and can be edited offline
Figure 2 Controlled GPOs are stored in the AGPM archive and can be edited offline
Controlling a GPO is very simple. The uncontrolled GPOs, as shown in Figure 3, list all GPOs that are not yet associated with the AGPM archive. Right-clicking any one of these GPOs provides a menu, which includes Control. Selecting the Control menu option will copy the GPO from the production location (the system volume, or SYSVOL, share on the domain controller) and place it in the AGPM archive. Multiple GPOs can be controlled; just hold down the Shift or Control key when selecting the GPOs to obtain the correct list of GPOs that you want to control, and then right-click to access the Control menu option. You still edit controlled GPOs using the Group Policy Object Editor (GPOE). This is just another way that AGPM has been fully integrated into the GPMC.
Figure 3 Uncontrolled GPOs are placed in the archive by selecting the Control menu option
Figure 3 Uncontrolled GPOs are placed in the archive by selecting the Control menu option

AGPM Delegation of Administration
Let's look at how AGPM handles delegation by first examining how you can delegate GPO administration using the GPMC. Within the GPMC, you have five different delegation tasks you can grant to a user: Create GPO, Link GPO, Edit GPO, Manage GPO, and Read GPO.
All of these delegations are completed within the GPMC interface. They are all controlled by the users and groups that are listed on the Delegation tabs associated with the different nodes within the GPMC. The delegations we are concerned about are those that allow the creation of new GPOs, as well as the editing and management of existing GPOs.
The creation of GPOs within the GPMC is handled by the Delegation tab associated with the Group Policy Objects node, as shown in Figure 4. Once you have AGPM installed, you will be able to remove all users and groups from the list of those who have access to create GPOs. (There's no need to remove system, computers, or computer groups from the Delegation tab to create GPOs.) The creation of GPOs will now be handled by the service account controlling the AGPM service. This account will be granted the delegation to create GPOs on behalf of all users and groups that are granted Create GPOs and Deploy delegations from within AGPM.
Figure 4 Creation of GPOs is controlled by the list of accounts on the Delegation tab on the Group Policy Objects node in the GPMC
Figure 4 Creation of GPOs is controlled by the list of accounts on the Delegation tab on the Group Policy Objects node in the GPMC
This new ability to create GPOs allows for separation of duties and protects the production network. Ideally, GPOs are created, configured, and verified before they're deployed from the AGPM environment to production. There should rarely be any errant configurations pushed out like there are today without AGPM.
For the delegation related to editing or management of GPOs, the story is similar. Within the GPMC, these delegations are configured on the Delegation tab associated with each GPO, as shown in Figure 5.
Figure 5 Editing and managing GPOs is associated with each GPO individually
Figure 5 Editing and managing GPOs is associated with each GPO individually
Once AGPM is installed, these delegations need to be removed from each GPO listed under the Group Policy Objects node. This will restrict all administrators from editing GPOs from outside of the AGPM. In essence, this channels all administration of GPOs to the AGPM, where tasks like offline editing, change management, and disaster recovery are possible.
The removal of users and groups from editing GPOs outside of the AGPM is a manual process. The installation and configuration of AGPM does not remove any user or group from editing GPOs in the production environment. Since the service account controlling the AGPM service will be performing the actions on behalf of the users modifying production GPOs from AGPM, there does not need to be any user or user group listed on the Delegation tab for each GPO. (Computer and computer groups should not be removed from these delegation tabs.)
After all delegations for editing a GPO within the GPMC are removed, all admins will be denied the ability to edit a GPO from the GPMC, as shown in Figure 6.
Figure 6 Admins can't edit GPOs from the GPMC once they are denied delegation for this action
Figure 6 Admins can't edit GPOs from the GPMC once they are denied delegation for this action
To finalize the configuration, all admins who need to edit GPOs must be added to the appropriate Access Control Lists (ACLs) within AGPM. If an admin needs to be able to edit all GPOs that are in the archive, his user account should be added to a group that has been granted editing capabilities at the domain level within AGPM, as shown in Figure 7. If an administrator should be limited to editing a few GPOs within the AGPM archive, this configuration should occur at each GPO (see Figure 8).
Figure 7 Domain Delegation tab allows for configuration of editing all GPOs in the archive
Figure 7 Domain Delegation tab allows for configuration of editing all GPOs in the archive
Figure 8 Editing of individual GPOs needs to be configured on the ACL of that GPO
Figure 8 Editing of individual GPOs needs to be configured on the ACL of that GPO

AGPM GPO Change Management
One of the incredible benefits of AGPM is the ability to track all changes that are made to GPOs within the archive. As this is an automated process, it doesn't need to be set up, configured, or managed. The tracking of all changes occurs in the background when GPOs are managed through the AGPM Client interface.
This is a significant enhancement to the way the default GPMC handles GPO management. Within the default GPMC, there are no automated, or even built-in, capabilities for tracking changes to GPOs. This has been a major complaint of most Group Policy administrators over the years and the problem is now eliminated.
The AGPM change management feature tracks all essential modifications that could occur to a GPO. Along with the changes that are made to the GPO, the change management system will also help in an auditing or overall admin tracking situation. The change management system will monitor, track, and document the following specifics per GPO edit and change: date and time the GPO was modified, user who made the change, original GPO settings, and modifications to the GPO settings.
Since the tracking of all changes is seamless, it is important to know what actions trigger the automated tracking. Within the AGPM Client interface, you can right-click on a GPO under the Controlled tab, then select the Check-out menu option, as shown in Figure 9.
Figure 9 Checking out a GPO will trigger the automated process to track changes
Figure 9 Checking out a GPO will trigger the automated process to track changes
This procedure must be followed to edit the GPO, which I'll discuss in the next section. Even if a GPO is checked out and immediately checked back in without any changes, there will be an archive made of that action. Since GPOs are so integral to the enterprise, the tool tracks even the possibility of a change occurring.
The Check-out procedure is forced within AGPM because there must be a mechanism that tracks GPO changes to the specific admin who made the change. Two admins cannot check out the same GPO at the same time. If an admin checks out the GPO and then fails to check it back in, there is a built-in mechanism that allows the AGPM admin to check it back in.

AGPM GPO Editing
As long as the AGPM client is installed, you can access the AGPM archive. Once delegation for editing or Full Control is granted within the AGPM tool, you will be able to edit stored GPOs. After a GPO is checked out, it can be edited by right-clicking on the GPO and selecting the Edit menu option. (Note: if you can only edit some of the GPOs within the AGPM archive, you may have only been granted delegated capabilities over some of the GPOs, not for all GPOs within the archive.)
With the acquisition of DesktopStandard, Microsoft also acquired PolicyMaker, now renamed Group Policy Preferences. This set of Group Policy features is included in the GPMC that will ship with Windows Server® 2008. Group Policy Preferences enables the administrator to configure applications or Windows components not ordinarily configurable via Group Policy, as well apply it to certain users or computers based on a very rich set of targeting rules. Group Policy Preferences is fully integrated with GPMC and AGPM in Windows Server 2008.

AGPM GPO Deployment
AGPM was designed with efficiency and workflow in mind. As GPO management is now more stable and controlled using AGPM, it makes sense to have admins who have the ability only to edit a GPO, but not deploy it to production. Within AGPM, this is controlled very smoothly with the interface, dialog boxes, and work mechanisms. For instance, if an admin with edit-only rights attempts to deploy a GPO, the system will block it. The admin will then be shown a dialog box for communication with an administrator who does have the deploy delegated permission. This workflow feature will both send an e-mail to the To: and CC: recipients and place the GPO in a unique state. That unique state can be found under the Pending tab in the AGPM interface. Here the GPO is flagged as "Pending Deploy," which gives the administrators a quick view into the status of each and every GPO that has had actions performed on it.
To deploy a GPO that is pending, an AGPM admin who has the deploy delegation can simply right-click on the GPO and select the Approve menu option. If the GPO needs to be deployed and is listed in the Controlled, rather than Pending, tab, the same admin needs only to right-click on the GPO and select Deploy. Since this delegated permission is granted already, the GPO will immediately be deployed to production.

AGPM GPO Settings Report and Comparisons
The GPMC interface has a powerful Settings dialog, accessed through a tab of the same name. This Settings dialog provides a thorough view of all settings that are configured in the GPO, helping you make sense of which of the almost 3000 group policy settings have been configured.
Since AGPM provides an archive of the modified GPOs, the Settings tab in the GPMC will not give you the ability to see the settings configured in edited GPOs. Instead, the AGPM interface provides an alternate solution to this feature, as well as much more.
To see the settings in any GPO, it is beneficial to first view the historical list of all changes. To get this view, double-click on any GPO within the Controlled tab in AGPM. From this interface, you can right-click on any GPO version and select the Settings Report. This will create a report of all settings that are configured in that version of the GPO. The report is a friendly HTML file, though it can also be created in an XML format.
Although this is useful, handier still is the ability to compare two versions of the same GPO. With this feature, you can see what has changed from one version to the other, or compare two completely different versions of the same GPO. (This is also very useful when you have a GPO that's pending deployment, since it lets you see the differences between the pending GPO and the production GPO.) To see this report, you highlight two different GPOs in the history view, then right-click on one of them.
The color coding in the difference report is extremely useful, especially when you want to verify what has changed in a pending GPO before you deploy it. Settings highlighted in red were deleted from the production GPO and are no longer available in the pending GPO. Blue settings were changed, and green settings are new changes that exist in the pending GPO, but not the production GPO.
This feature of AGPM can save many hours of laborious manual comparisons of GPO settings. It is also a perfect way to document the GPOs over time—every version can be reported and printed.

AGPM GPO Disaster Recovery
A single change to a GPO can create havoc for one or more computers on your network. With the default GPMC, this type of errant configuration can be corrected—if the proper manual measures were taken to make backups of the GPO both before and after the changes were made to the production GPO. If no backups were made, then recovering from this disaster is not as simple as one might think.
AGPM handles this easily. Since there are complete backups of all GPOs throughout the GPO history, you can easily open up the history of the GPO and select which GPO version you want to redeploy.
With AGPM, your management of Group Policy becomes quite seamless. For years, administrators have wanted the ability to control and manage GPOs offline. AGPM provides this feature with grace and elegance. AGPM also provides a very robust change management solution, which not only tracks the key areas of a changed GPO, but also provides for easy GPO comparisons and disaster recovery. The delegation model that is built into AGPM allows you to channel all administrators into the AGPM for all edits to GPOs, which provides automated backups of GPO changes and removes any production GPO mishaps. This service has so many features that it's impossible to discuss them all here, but the AGMP manual provides a great deal of information about templates, node link recovery, SMTP configuration, and much more.

Derek Melber is an independent consultant, trainer, and author. Derek educates and evangelizes Microsoft technology, focusing on Active Directory, Group Policy, security, and desktop management. Derek regularly contributes to online and print publications, and has written more than 10 technology books, including The Microsoft Windows Group Policy Guide (Microsoft Press, 2005). You can reach Derek at derekm@braincore.net.


 From the Editor: Winning Over a Cynic
From the Editor
Winning Over a Cynic
Joshua Hoffman

I'm a cynic. Yes, it's true. I know we New Yorkers are generally known for our trusting and humble naivete, but every once in a while, a jaded soul slips through the Lincoln Tunnel and spoils it all. Being a cynic, I have a tendency to question things. It can be hard to win me over.
My colleagues in Redmond may not like hearing this, but I was somewhat cynical when Microsoft introduced the System Center brand a few years back. Don't get me wrong—I'm an SMS guy through and through. As a desktop deployment and management specialist in a former life, Systems Management Server (after v2.0 anyway) was a critical tool in my arsenal. But as the System Center brand evolved, and the product line grew, my natural tendency to question reared its head.
Was this really necessary? Would it benefit the customer in the end? Would diversifying the product line have a negative impact on the flagship management products we've all come to know and love?
I have to admit, though, despite my initial foreboding, System Center has won me over. SMS and MOM (now known as Configuration Manger and Operations Manager) have evolved into world-class management products, adding powerful (even surprising) new functionality with every release. And not only has their value not been diminished by the addition of new products—it's actually been significantly amplified.
In recent months, we've explored the new Configuration Manager and Operations Manager products, as well as some of the other early add-ons to the System Center lineup (such as Capacity Planner, Desired Configuration Monitor, and Essentials). As you'll see, this month we dive into some very powerful new additions.
Edwin Yuen begins our coverage by showing you how Virtual Machine Manager 2007 not only helps centralize the management of your virtualized infrastructure but also how it can help you break down some of those pesky migration barriers, allowing you to consolidate legacy hardware into new virtual machines. Calvin Keaton guides us through the new version of Data Protection Manager, which enables powerful disk-based backup solutions not only for standard user data (like documents) but also enterprise data, such as the critical information stored in Exchange Server. Finally, Paul Bourgeau introduces the first hosted System Center solution—the Asset Inventory Service.
Let me know what you think of the new additions to the System Center lineup. E-mail me at tnmag@microsoft.com. —Joshua Hoffman

Thank you to the following Microsoft technical experts: Karandeep Anand, Joseph Dadzie, Ray Hayes, KC Lemson, Bill Scheidel, Jeffrey Snover, Mike Stephens, Kevin Sullivan, Jim Truher, and Winni Verhoef.


 Letters: Readers Speak Out
Letters
Readers Speak Out

VMRCplus Problems
I downloaded VMRCplus, as described in Utility Spotlight, October 2007 (technetmagazine.com/issues/2007/10/UtilitySpotlight). But if I try to connect to a remote machine, I get RPC errors. Since the Virtual Server admin interface is Web-based, I assumed that this app would also use the Web interface, simply adding a richer client experience on existing Web technology. Alas, it uses the COM API.
—Via blogs.technet.com/tnmag.

VMRCPlus actually uses the same network path as the VMRC remote-control client that ships with Virtual Server (which is an actual client application, not a Web interface). That means you must have access to the following ports:
  • Port 5900, which is the default port for the VMRC server
  • Port 1024, which is the default port for the Administration Web site
  • Ports 137 and 138, the TCP and User Datagram Protocol (UDP) ports, for the Kerberos V5 ticket-granting authority
  • Port 135, which is used for the RPC endpoint mapper
You can read more about this at microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_using_VMRC_manageVMs.mspx.

Using Windows PE
I read your article "Getting Started with Windows PE" (September 2006, technetmagazine.com/issues/2006/09/WindowsPE). I am trying to get Windows® PE up and running in a VMWare workstation environment with network support, but I can't get Windows PE to access the network using the NIC driver. I boot from VMWare with the Windows PE image ISO file. It starts and a command console appears, but when I type ipconfig, it doesn't display an IP address. It can't resolve an address from my DHCP server, either.
—John C.

The problem is that the NIC that VMware installs by default is not supported by Windows Vista® (which is the basis for Windows PE 2.0). What you need to do is specify another NIC type in the Virtual Machine Configuration file (VMX file), as follows:
ethernet0.virtualDev = "e1000"
This has to be done manually by editing the VMX file in a text editor such as Notepad, for instance—you can't edit it via any GUI. This change will replace the existing built-in virtualized NIC with the Intel 1GB NIC that Windows Vista does support. Most importantly, replacing it with this value means you don't have to add any network drivers.

Optimizing Query Performance in SQL Server
In the article "Optimizing SQL Server Query Performance" (November 2007, technetmagazine.com/issues/2007/11/SQLQuery), the author has given a SQL Server™ 2005 example for finding the top 20 most expensive queries running. However, it does not run in SQL Server 2000. Can you give me an example that works with this older version?
—Arun N.

Unfortunately, there is no way to obtain this information on SQL Server 2000—SQL Server 2000 does not collect and expose such information for queries in its procedure cache. This information only became available with the new set of Dynamic Management Views introduced in SQL Server 2005.

The MIISWorkflow Application Won't Work
After reading "Build a Single-Step Provisioning Workflow" (May 2007, technetmagazine.com/issues/2007/05/Workflow), I have a few questions. Is the MIISWorkflow application supported? Is it compatible with the .NET Framework 2.0? I get a "Service Unavailable" error when I try to open the application outside of Visual Studio®. I have been running it successfully in debug mode, but if I close Visual Studio and try to open the app directly, the error appears. What would cause the application to stop the application pool and/or produce the Service Unavailable error?
—Cliff C.

The MIISWorkflow application is not an officially supported Microsoft product. It is provided as sample code for educational purposes only.
The best place you can go for discussion of problems related to identity management is on the TechNet Forums Identity Management site, at forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=540&SiteID=17. These forums are monitored by members of the Microsoft product groups, as well as community experts, and are among the best sources for direct support for issues such as this one.


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

Take Control of Windows PowerShell
PowerGUI
powergui.org
If you haven't started using Windows PowerShellTM yet, you most likely will be using it soon. Windows PowerShell is becoming a core administrative tool in the world of Windows Server®. For starters, it has become the basis for script-based management of Exchange Server 2007.
To get the most out of Windows PowerShell in its native format, you need to memorize a fair amount of syntax, cmdlets, and general structure. Of course, you may not have the time (or mental energy) to dedicate to this. But what if you had a centralized graphical administrative console for managing your scripts? A user interface that would give you customizable templates, IntelliSense®-like editing features, and a script-sharing community base? With this sort of environment, you would be able to quickly script the tasks you need and always know where they are located for future reuse and reference.
Don't worry—I'm not just teasing you here. This GUI-based environment for Windows PowerShell is what you get with PowerGUI, a freeware product sponsored by Quest Software. Though still in beta at the time of writing this column, this application offers an easy-to-use, extensible administrative GUI that has the feel of a Microsoft® Management Console (MMC) snap-in on steroids.
Within the GUI, you can double-click on any of the supplied scripts or one of your own customized scripts to have it run and provide a tabular view of the returned dataset. You can apply column and value filters to this data to drill into the information you need. In addition, you can add your own custom columns to supply computed values or custom results that suit your specific needs.
From within the GUI, you can launch a Windows PowerShell prompt or the application's built-in script editor. The script editor is where you get a basic IntelliSense-like environment that shows you the syntax of the available cmdlets as well as the standard file and editing features, such as search and replace, printing, and cut/copy/paste. You can also bookmark steps.
Furthermore, PowerGUI gives you a number of customizable and extensible actions that you can apply to your dataset. For example, the local system services script lets you start, stop, suspend, and set properties on the designated service. Another nice feature is the ability to add links between scripts, in effect allowing you to chain scripts by common elements to get the information you need. For instance, you can get a list of users from a certain Group and then link that to a script that shows you the amount of data in their home directory. In addition to those capabilities, PowerGUI has a few built-in common action scripts for reporting and reviewing that let you dump your data to XML, CSV, HTML, and the clipboard.
You can extend both the individual script actions and the common actions by adding your own scripts or customizing one of the provided templates. Bringing up the properties window on a script allows you to edit the script in place or simply see how it works.
Another valuable feature is the PowerGUI Web site community library, which offers a place for users to share and download scripts to aid in your system administration tasks. Here you'll find scripts and actions for Active Directory® management, Exchange server management, Microsoft Operations Manager tasks, general Windows Server tasks, and more. PowerGUI is a solid start to providing a GUI-based, extensible administrative tool for working with Windows PowerShell.

Price: Free
Simplify Windows PowerShell with a graphical UI
Simplify Windows PowerShell with a graphical UI

Think Green When Acquiring Products
Electronic Product Environmental Assessment Tool
epeat.net
When you think green, you need to consider the overall cost of a computer throughout its entire lifecycle. This means the collective energy consumed when manufacturing, using, and disposing of computers (not to mention other factors, such as the materials used and waste generated). The overall cost, in these terms, is quite astounding. (For an overview of the environmental and financial costs involved, see the article Dave Ohara wrote for the October 2007 issue of TechNet Magazine, available at technetmagazine.com/issues/2007/10/Green.)
Fortunately, more and more individuals and corporations are recognizing the impact, both financially and environmentally, of their infrastructure. And, as a result, they are beginning to look for products that reduce energy consumption. One tool for the IT professional that is trying to help companies address this concern is brought to us by the Green Electronics Council (greenelectronicscouncil.org ).
The organization's tool, dubbed EPEAT (short for Electronic Product Environmental Assessment Tool), evaluates electronics products according to 51 different environmental criteria—23 of these criteria are required and 28 are optional. The ratings are as follows: Bronze (which implies the product meets the baseline required criteria), Silver (which is the required plus 50 percent of the optional criteria), and Gold (which meets the required criteria plus 75 percent or more of the optional elements).
The criteria cover the gamut of a product's lifecycle, from the materials selected for manufacture to the power consumption during use and end of life management. The standard's required criteria predominately cover declarations of a product's impact, such as declaring how much of a product is made from recycled plastic, identifying materials contained in the product that require special handling, and declaring how much of a product's packaging is recycled material. (All EPEAT-registered products currently meet ENERGYSTAR 3.0 standards; and by the end of January 2008, all will be compliant with the new ENERGYSTAR 4.0 standard.)
Furthermore, certified products must have a "take-back" service in place for both the product and its rechargeable batteries (if applicable). Another interesting requirement is the availability of a three-year warranty or service agreement, which should, in theory, help prolong the life of a device, thus reducing the overall impact of a high turnover rate.
Some of the optional standards cover the elimination of certain heavy metals (such as cadmium), modular design, third-party certification of the company's environmental practices and policies, and various percentage levels of recyclability.
Currently, there are four categories of products available: desktops, integrated systems, monitors, and notebooks. The product categories will continue to expand, with server standards slated for sometime in 2009.
And most major manufacturers are participating. This was helped along by Executive Order 13423 of January 2007, which stipulates that any federal agency acquiring electronic products to meet its requirements should meet at least 95 percent of those requirements with an Electronic Product Environmental Assessment Tool (EPEAT)-registered electronic product (whitehouse.gov/news/releases/2007/01/20070124-2.html).
So, if you aren't already addressing the environmental impact of your purchases, you should take the time to check out the EPEAT assessment tool in order to start considering the environmental (and financial) gains that can be made with your next product acquisition.

Price: Free
Use EPEAT to assess the environmental impact of your hardware puchases
Use EPEAT to assess the environmental impact of your hardware puchases

Book Review
Windows Vista Administrator's Pocket Consultant
microsoft.com/MSPress/books/9588.aspx
If you are getting ready to roll out Windows Vista® in your organization, the Windows Vista Administrator's Pocket Consultant (Microsoft Press, 2006) by William Stanek can help get you up to speed quickly on the new features and functionality. Those of you who have read other books from the Administrator's Pocket Consultant series will find the format of this book familiar and its depth of content similar to the others in this series. It doesn't give you every intricacy, but it does give a good, broad overview of features and functionality, specific administrative task execution, and refreshers of how things work. And the content is definitely geared toward system administrators, as opposed to general end users.
The book starts out with an introduction to the Windows Preinstallation Environment 2.0, along with a brief overview of the utilities that you'll have at your disposal during automated or interactive installation. Then the book moves into managing Windows Vista systems, showing you how to use tools like msconfig to troubleshoot or tailor your installation, as well as showing you new features like Previous Versions, which allows you to restore a folder or file to a previous state. In addition, you get an introduction to the tools that help you manage the hardware and devices on target systems.
The book then covers how to tailor the Windows® experience for your end users by customizing the interface and desktop. For example, it shows you how to reduce screen-saver resource usage, tailor the startup and start menu programs, and configure the Windows sidebar. And the book also shows you how to create personal toolbars to give your end users quick access to shared folders and files from the taskbar.
The section on installation and maintenance of Windows Vista programs and features discusses tools like the Software Explorer, which allows you to speedily see a system's startup programs, currently running programs, Winsock service providers, and network-connected programs. It then moves on to managing users, profiles, mobility concerns, and computer and user policy, and also disk management, file security, and resource sharing. More specifically, it explains how to create users, manage Windows logon through group policy, and create key ring entries that will make it easier for users to access password-protected resources.
The section on mobility discusses how the new alternate network configuration lets you specify both an "at the office" configuration and an "on the road" configuration. Users are able to easily switch between the two modes.
In the chapter "Managing File Security and Resource Sharing," you get the basics on how to configure permissions on NTFS files and folders as well as how Windows Vista Special Permissions work (and how to control them). Here too, you learn how to create, connect to, and persist connections to shared resources.
In terms of disk management, the book contains an introduction to configuring disk quota, which teaches you not only how to create, view, update, and delete disk quotas but also how to import and export these settings for reuse.
There is a pretty detailed look at how the dual IPv4/IPv6 networking stack in Windows Vista works. Here, you also see how to configure your network adapters for your environment.
The book finishes up with a section on how to optimize Windows Vista to ensure the best experience for your users, followed by a short chapter on general troubleshooting techniques. Here, you can find out how to set up remote assistance, maintain a healthy system through scheduled disk checks and defragmentation, and how to create backups. Overall, this is an easy-to-follow, quick-reference for Windows Vista administration.

Price: $29.99 direct.

Monitor Your Web Site
Pingdom.com
pingdom.com
I've said this before, and I simply can't stress it enough: a proactive approach to systems administration will result in less stress and will help you avoid embarrassing moments, such as when the boss sends you an e-mail saying, "Did you know the site is down?"
A good network monitoring tool is essential to this approach. Most, if not all, of you probably already employ some kind of internal network monitoring server. But what about those of you who are concerned with a global presence in which you need to ensure availability of your Internet-facing services?
Pingdom.com, an application service provider (ASP), provides a simple-yet-effective automated monitoring service. The ASP's servers are distributed across multiple global locations, giving you a much better sense of what your users are really experiencing—as opposed to relying on a single-source external service monitor.
To get going, sign up for an account and set your locality, defining your time zone, country, date format, and the number format that meets your needs. Then set up your contacts by providing names, SMS phone numbers, and e-mail addresses for notification. After that, you create a monitoring check by defining a name, a check resolution, the type of monitoring check to be performed at the resolution, and the type, contacts, and periodic intervals of notifications for the check.
The default account package gives you check resolutions that range from 1 minute to 60 minutes, letting you tailor the requests to the service you are monitoring. Notification can be sent to your contacts via e-mail or SMS. And you can define the number of times the service ping should fail before notification is sent, along with how many failure cycles must pass before you are notified again (up to a maximum of four reminders). In addition, you can also have the pingdom notify you when your service comes back up—this is great for Web site or service maintenance window checks. Speaking of maintenance, you can also pause or stop the checks to avoid false positives during scheduled tasks.
The service offers users four basic types of checks: an HTTP sensor, a TCP port sensor, a ping sensor, and a UDP sensor. The HTTP sensor lets you set the URL/IP, whether the request is over SSL, the port, a basic authentication user name and password combination, or a basic inclusive/exclusive content check string. The TCP port sensor lets you define the service port and IP/domain to be checked. The ping sensor lets you set the IP or domain to check via ICMP. And the UDP sensor is determined by the IP/domain, a port, the string to send to that combination, and the expected response string. In effect, you could check the availability of your Web site, FTP server, SMTP server, and more from multiple locations around the globe.
The service also provides several reports to help you visualize historical data. With these reports, you can see your percentage of uptime for a specified month and the average response time for that time period. You can also get a detailed view of each check instance, displaying the timestamp, status, response time, and the server from which the check was performed. In addition, you get a view of notifications, showing you when, how many, to whom, and by what means they were sent for a specified time period. You can make these reports publicly available, so other members of your organization can see the service statistics. If you have your own tailored NOC, pingdom.com also provides a Web service API that you can query for this information, allowing you to integrate the service into your current dashboard views.

Price: $9.95 per month.
Pingdom.com monitors your Web services with a global perspective
Pingdom.com monitors your Web services with a global perspective

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


 Exchange Queue &amp; A: Adding Voice Prompts, Choosing a PBX , and More
Exchange Queue & A
Adding Voice Prompts, Choosing a PBX , and More
Seema Rahman

Q I've heard that Exchange Unified Messaging does not offer high availability or clustering. Is that true?
A While Unified Messaging is not supported in a cluster or network load-balancing configuration, from certain gateways you can certainly achieve a high availability solution. The key is to designate multiple Unified Messaging servers to round-robin the traffic. You can also arrange for certain traffic to be routed to a specific Unified Messaging server, provided the gateway has the necessary advanced routing features. For example, you can designate one Unified Messaging server for subscriber access and one for all automated attendant calls. This allows you to balance Unified Messaging traffic based on your infrastructure and trends in your environment.

Q Can I set up voice prompts for my company's public phone number with Exchange Unified Messaging?
A Yes, you can, and you can set up an auto attendant as well. The article "Managing Custom Audio Prompts" at technet.microsoft.com/aa998818 offers detailed steps on how to configure this feature.

Q How do I know if my Private Branch eXchange (PBX) is compatible with Exchange Unified Messaging?
A Certain gateways are tested by Microsoft and recommended for use with Exchange Unified Messaging. The vendors that produce these gateways provide a list of PBXs that work with their gateway. If your PBX is listed by any of the vendors, it is compatible with Exchange Unified Messaging.
The article "Telephony Advisor for Exchange Server 2007," available at microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx, provides a list of supported gateways and a lot of other pertinent information as well.

Q Do I need to add any special hardware to my phone system to use Exchange Unified Messaging?
A Exchange Unified Messaging server acts as your voicemail provider. In order to work with your current telephony system, it may require hardware you don't have.
If you are using a supported IP-PBX, you won't need additional hardware; however, you will probably need to configure some specific settings on your IP-PBX to make it work with Unified Messaging.
If you are using something other than a supported IP-PBX, you have to first determine if that hardware is compatible with one of the supported gateways. You will also need a supported VoIP gateway.
The information at microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx includes a list of supported hardware, specifically IP-PBXs and gateways. Remember to check back often because the list is updated frequently as Microsoft certifies new hardware. You can also consult your regional Unified Messaging specialist to determine the hardware requirements for your environment.

Q How does Unified Messaging provide fax support ?
A Currently Unified Messaging provides an incoming fax feature such that a fax sent to a Unified Messaging-enabled user's extension will end up in the user's Inbox as an e-mail message with the fax message attached in TIFF format. A detailed overview is available at technet.microsoft.com/ bb232022.

Q I have a Nortel CS1000 IP/PBX and want to use Unified Messaging in Exchange Server 2007. But I don't know how to bring these two systems together. Can I use the Nortel CS1000 IP/PBX as the gateway or are only Intel and Audio Codes supported as gateways? I also need the Exchange system to authenticate at the CS1000 Server.
A Nortel CS1000 is a supported IP/PBX provided you are running version 5.0 of the firmware for the IP/PBX. You will not need any additional hardware to make it work. The Nortel site has the configuration notes for configuring the IP-PBX at support.nortel.com/go/main.jsp?cscat=docdetail&id=626197&poid=14261. Supported gateways, PBXs, and supported firmware versions can be found at microsoft.com/technet/prodtechnol/exchange/pbx-partners.mspx.

Seema Rahman has been with Microsoft for six years. As a Support Escalation Engineer, she helps customers solve complex issues with Exchange Server. Seema especially enjoyed her time on the Exchange 2007 Beta team, where her focus was Unified Messaging.


 Utility Spotlight: Windows Easy Transfer Companion
Utility Spotlight
Windows Easy Transfer Companion
Lance Whitney
This article is based on a prerelease version of Windows Easy Transfer Companion. All information herein is subject to change.

It's time to migrate your users from their old Windows® XP computers to new Windows Vista® machines. The biggest chore in any migration is reinstalling your users' applications on their new PCs—and making sure those apps work. Now, a free tool from Microsoft can spare you those countless reinstalls. The Windows Easy Transfer Companion (WETC) can copy key software programs from Windows XP to Windows Vista.
Currently in beta, WETC is different from the Windows Easy Transfer wizard in Windows Vista. Whereas the wizard copies data files, program settings, and user profiles, WETC copies entire applications, though only from Windows XP SP2 to Windows Vista. You must run the transfer under an admin account.
You install WETC on both the source and destination computers. The PCs can talk to each other over a network or through an Easy Transfer USB cable. The driver for the Easy Transfer cable is included in Windows Vista; for Windows XP you'll need to install the driver from the product CD.
WETC provides a categorized list of transferable apps
WETC provides a categorized list of transferable apps
After connecting the cable, you start WETC on the Windows XP machine. The utility scans the hard drive, gathers basic system information, and analyzes all installed software. When that process completes, you run WETC on the Windows Vista computer. The utility communicates with the Windows XP machine to display a list of all discovered applications, divided into three categories (see the screenshot above):
  1. Programs that transfer well—software that will transfer without problems and run on the Windows Vista PC.
  2. Programs that transfer with possible limitations—software that's capable of being transferred but may not run properly.
  3. Programs that will not be transferred—software that won't run on Windows Vista and will not be included in the transfer.
For each program that can't transfer successfully, WETC briefly explains why. Typically, applications might not copy because they're missing installer information or other key data, are incompatible with Windows Vista, or are already on the Windows Vista machine. Also, WETC will not copy specific types of applications, such as antivirus and system utilities. Nor will it transfer OS frameworks, such as Microsoft .NET—you'll need to install those in Windows Vista before you copy any apps that require them.
From the list of programs, you check off the ones you want to copy. A help screen can assist in your decision and provide solutions to any problems. You can also save a pre-transfer report that lists all programs that will and will not be transferred.
The transfer then proceeds, copying the data related to each program. At the end, a status message tells you which programs were copied and whether errors occurred. You can save a detailed post-transfer report. After exiting WETC, reboot the Windows Vista PC, log in, and run the transferred programs to make sure they work.
Any problems? The WETC Programs folder on Windows Vista includes a shortcut to a Resources tool with an Undo feature that can remove all apps copied to the Windows Vista machine, but this information expires within three days. You can learn more about Windows Easy Transfer Companion and download the latest version at support.microsoft.com/kb/931696.

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: DNS Enhancements in Windows Server 2008
The Cable Guy
DNS Enhancements in Windows Server 2008
Joseph Davies
This article is based on a prerelease version of Windows Server 2008. All information herein is subject to change.

Microsoft has included a Domain Name System (DNS) Server service in versions of Windows Server since Windows NT 4.0. DNS is a hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as IP addresses. With Windows Server 2008, the DNS Server service includes new
background zone loading, enhancements to support IPv6, support for read-only domain controllers (RODCs), and the ability to host global single-label names.

Background Zone Loading
The DNS Server service in Windows Server® 2008 makes data retrieval faster by implementing background zone loading. In the past, enterprises with zones containing large numbers of records in Active Directory® experienced delays of up to an hour or more when the DNS Server service in Windows Server 2003 tried to retrieve the DNS data from Active Directory on restart. During these delays, the DNS server was unavailable to service DNS client requests for any of its hosted zones.
To address this issue, the DNS Server service in Windows Server 2008 retrieves zone data from Active Directory in the background after it starts so that it can respond to requests for data from other zones. When the service starts, it creates one or more threads of execution to load the zones that are stored in Active Directory. Because there are separate threads for loading the Active Directory-based zones, the DNS Server service can respond to queries while zone loading is in progress. If a DNS client requests data in a zone that has already been loaded, the DNS server responds appropriately. If the request is for data in a zone that has not yet been entirely retrieved, the DNS server retrieves the specific data from Active Directory instead.
This ability to retrieve specific data from Active Directory during zone loading provides an additional advantage over storing zone information in files—namely that the DNS Server service has the ability to respond to requests immediately. When the zone is stored in files, the service must sequentially read through the file until the data is found.

Enhanced Support for IPv6
IPv6, which has been covered in previous editions of this column, is a new suite of Internet standard protocols. IPv6 is designed to address many of the issues of the current version—IPv4—such as address depletion, security, autoconfiguration, and the need for extensibility.
One difference in IPv6 is that its addresses are 128 bits long, while IPv4 addresses are only 32 bits. IPv6 addresses are expressed in colon-hexadecimal notation. Each hexadecimal digit is 4 bits of the IPv6 address. A fully expressed IPv6 address is 32 hexadecimal digits in 8 blocks, separated by colons. An example of a fully expressed IPv6 address is FD91:2ADD:715A:2111:DD48:AB34:D07C:3914.
Forward name resolution for IPv6 addresses uses the IPv6 Host DNS record, known as the AAAA record (pronounced "quad-A"). For reverse name resolution, IPv6 uses the IP6.ARPA domain, and each hexadecimal digit in the 32-digit IPv6 address becomes a separate level in the reverse domain hierarchy in inverse order. For example, the reverse lookup domain name for the address FD91:2ADD:715A:2111:DD48:AB34:D07C:3914 is 4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.1.1.2.A.5.1.7.D.D.A.2.1.9.D.F.IP6.ARPA.
The DNS Server service in Windows Server 2003 supports forward and reverse name resolution for IPv6; however, the support is not fully integrated. For example, to create an IPv6 address record (the AAAA record we just discussed) in the Windows Server 2003 DNS Manager snap-in, you must right-click the zone, click Other New Records, and then double-click IPv6 Host (AAAA) as the resource record type. To add a AAAA record in the DNS Manager snap-in for Windows Server 2008, right-click the zone name, and then click New Host (A or AAAA). In the New Host dialog box, you can type an IPv4 or IPv6 address. Figure 1 shows an example.
Figure 1 New Host dialog box
Figure 1 New Host dialog box
Another example of better support for IPv6 is for reverse IPv6 zones. To create a reverse lookup zone in the DNS Manager snap-in for Windows Server 2003, you have to manually type the reverse zone name in the Reverse Zone Lookup Name page of the New Zone Wizard. An example of a DNS reverse zone name is 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa (for the IPv6 subnet prefix 2001:db8:0:1::/64, fully expressed as 2001:0db8:0000:0001::/64).
IPv6 reverse zones in the DNS Manager snap-in for Windows Server 2008 are now fully integrated into the New Zone wizard. There is a new page of the wizard that prompts you to select an IPv4 reverse lookup zone or an IPv6 reverse lookup zone. For an IPv6 reverse lookup zone, you just need to type the IPv6 subnet prefix and the wizard automatically creates the zone for you. Figure 2 shows an example.
Figure 2 Naming an IPv6 reverse lookup zone
Figure 2 Naming an IPv6 reverse lookup zone
Another enhancement for reverse zones is the way in which the DNS Manager snap-in displays IPv6 pointer (PTR) records. Figure 3 shows how the DNS Manager snap-in for Windows Server 2003 displays a PTR record.
Figure 3 PTR record for IPv6 in Windows Server 2003
Figure 3 PTR record for IPv6 in Windows Server 2003
Although this display accurately reflects the structure of the DNS namespace for IPv6 reverse domain names, it makes PTR record management for IPv6 addresses more difficult. Figure 4 shows how the DNS Manager snap-in for Windows Server 2008 displays a PTR record.
Figure 4 PTR record for IPv6 in Windows Server 2008
Figure 4 PTR record for IPv6 in Windows Server 2008
The DNS Server service in Windows Server 2003 supports operation over IPv6, but it must be manually enabled with the dnscmd /config /EnableIPv6 1 command. Windows Server 2008, conversely, supports operation over IPv6 by default. The Dnscmd.exe command-line tool has been updated to accept IPv6 addresses in command-line options. Additionally, the DNS Server service can now send recursive queries to IPv6-only servers, and the server forwarder list can contain both IPv4 and IPv6 addresses.
For more information about IPv6 and how it is supported in Windows®, see microsoft.com/ipv6.

Read-Only Domain Controller Support
Windows Server 2008 also introduces the RODC, a new type of domain controller that contains a read-only copy of Active Directory information and can perform Active Directory functions but cannot be directly configured. RODCs are less vulnerable to attack and can be placed in locations where the physical security of the domain controller cannot be guaranteed or where the network contains potentially malicious hosts.
For RODCs, the DNS Server service in Windows Server 2008 supports the new primary read-only zone type. When a computer becomes an RODC, it replicates a full read-only copy of all of the application directory partitions that DNS uses, including the domain partition, ForestDNSZones, and DomainDNSZones. This ensures that the DNS Server service running on the RODC has a full read-only copy of any DNS zones stored in the directory partitions of a domain controller that is not an RODC. You can view the contents of a primary read-only zone on an RODC, but you cannot change them. You must change the contents of the zone on a domain controller that is not an RODC.

GlobalNames Zone
Name Resolution with the GlobalNames Zone
After the GlobalNames zone is deployed, when a Windows Vista-based DNS client attempts to resolve a single-label name, it appends the primary DNS suffix to the single-label name and submits the name query request to its DNS server.
If the name is not found, the DNS client sends additional name query requests for the combination of the single-label name with the suffixes in its DNS suffix search list (if configured). If none of those names resolve, the client requests resolution using the single-label name.
The DNS server searches for the single-label name in the GlobalNames zone. If it appears there, the DNS server sends the resolved IPv4 address or FQDN back to the DNS client. Otherwise, the DNS client computer converts the name to a NetBIOS name and uses NetBIOS name resolution techniques, including WINS. No changes to the DNS Client service are required to enable single-label name resolution in the GlobalNames zone.

Windows Server 2008 and Windows Vista® support the NetBIOS over TCP/IP (NetBT) protocol. NetBT uses NetBIOS names to identify Session-layer NetBIOS applications. Although NetBIOS name resolution with WINS is not required for current versions of Windows that rely on Windows Sockets-based network applications and DNS for name resolution, many Microsoft customers deploy WINS in their networks to support older NetBT applications and to provide name resolution for single-label names across their organizations. Single-label names typically refer to important, well-known, and widely used servers for an organization, such as e-mail servers, central Web servers, or the servers for line-of-business applications.
In order to allow these single-label names to be resolved across an organization using only DNS, you might find it necessary to add A records to the multiple DNS domains of your organization so that a Windows-based DNS client can resolve the name regardless of their assigned DNS domain suffix or suffix search list.
Suppose, for example, that the contoso.com organization has a central Web server named CWEB that is a member of the central.contoso.com domain. To implement a single-label name for the server CWEB when DNS clients can be assigned the DNS domain suffix wcoast.contoso.com, central.contoso.com, or ecoast.contoso.com, the network administrator must create two additional A records for both cweb.wcoast.contoso.com and cweb.ecoast.contoso.com. However, don't forget that manually created A records for single-label names must be maintained for changes in IPv4 address assignment or for new names.
If contoso.com is already using WINS for older NetBT applications, a network administrator can implement name resolution for the single-label name CWEB by adding a single static WINS record to their WINS infrastructure. If the IPv4 address changes, only the single static WINS record needs to be changed. Because single-label names are easier to manage on WINS, many Windows-based networks use static WINS records for single-label names.
To provide a single-label name solution on DNS that's as easily managed as static WINS records, the DNS Server service in Windows Server 2008 supports a new zone called GlobalNames to store single-label names. The replication scope of this zone is typically a forest, which provides single-label name resolution across an entire Active Directory forest. Additionally, the GlobalNames zone can support single-label name resolution throughout an organization that contains multiple forests when you use Service Location (SRV) resource records to publish the location of the GlobalNames zone.
Unlike WINS, the GlobalNames zone is intended to provide single-label name resolution for a limited set of host names, typically the central and critical servers of an organization that are managed by its IT department. The GlobalNames zone is not intended to be used to store the names of desktop computers or other servers whose IPv4 addresses can change, and under no circumstances does it support DNS dynamic updates. It is most commonly used to hold alias (CNAME) resource records to map a single-label name to a Fully Qualified Domain Name (FQDN). For networks that are currently using WINS, the GlobalNames zone usually contains resource records for IT-managed names that are already statically configured in WINS.
The GlobalNames zone provides single-label name resolution only when all authoritative DNS servers are running Windows Server 2008. However, other DNS servers that are not authoritative for any zone can be running older versions of Windows or other operating systems. The GlobalNames zone must be unique in the forest.
To provide maximum performance and scalability, the GlobalNames zone should be integrated with Active Directory and you should configure each authoritative DNS server with a local copy of it. Accomplishing this is required in order to support deployment of the GlobalNames zone across multiple forests.
For more information about DNS support in Windows and about deploying the GlobalNames zone, see the Microsoft DNS Web page at microsoft.com/dns.

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 online TechNet Cable Guy column.


 Windows PowerShell: Heading Off Malicious Code
Windows PowerShell
Heading Off Malicious Code
Don Jones

Remember back when Windows Vista was still in beta and there was buzz about a very early version of a new command-line shell code-named "Monad"? (This, of course, would eventually come to be known as Windows PowerShell.) At the time, there were many mainstream media reports about the "first Windows Vista virus." In
reality, the "virus" was just a proof-of-concept malware script that targeted "Monad." In order to run the script, "Monad" itself would have had to have been specially configured—the script wouldn't work under default settings. Moreover, by the time those reports surfaced, Microsoft had already announced that "Monad" would not ship as part of Windows Vista®. In short, the whole situation was much ado about nothing (or, at least, about very little).
As Windows PowerShellTM becomes more popular, though—it has already been downloaded more than a million times—the odds increase that someone will use it to create a malicious script. The ability to write a potentially damaging script in Windows PowerShell is a given; any admin tool—including Windows PowerShell, cmd.exe, and VBScript—can be used maliciously. So you can't just assume a given PS1 file is harmless.
Fortunately, Windows PowerShell is configured by default not to run any scripts, so that malicious script needs help from you if it is going to run. This month, I'd like to predict how this will probably happen. This isn't to make Windows PowerShell look bad—I think Microsoft has done a good job designing a scripting shell that avoids many of the risks. However, this is a discussion worth having just to help you prepare and be ready to head off this potential attack.

Secure by Default
It's worth noting that Windows PowerShell was the first language designed by Microsoft after the famous Trustworthy Computing initiative. Security guru Michael Howard (author of the book Writing Secure Code) was the Windows PowerShell team's "security buddy." He helped to make sure the code was written to be as secure as possible and, most importantly, that the shell was configured as securely as possible right out of the box.
First, let's quickly review the initial Windows PowerShell security settings. By default, the shell will not run files with a PS1 file name extension when you double-click on them. That extension is associated with Notepad. In fact, by default, the shell won't run scripts at all because of a built-in feature called the Execution Policy, which describes the conditions under which a script will run. It is set to Restricted out of the box, which prohibits all scripts from running and enables the shell only for interactive use. The Execution Policy can be changed using the Set-ExecutionPolicy cmdlet, or through a Group Policy administrative template (ADM file) supplied by Microsoft. (You can obtain the ADM file at go.microsoft.com/fwlink/?LinkId=102940.) Figure 1 shows the Execution Policies you can set.
Figure 1 Choosing a secure Execution Policy
Figure 1 Choosing a secure Execution Policy
The Execution Policy has only a few exceptions. Specifically, even when set to Restricted, it will allow the shell to import a few particular XML configuration files that are provided by Microsoft and installed along with the shell. These files are used to provide specific functionality, such as extensions to Microsoft® .NET Framework types and default formatting layouts for most .NET object types. Thus, these are files you definitely want the shell to load at startup.
While these files can and do contain executable code, they've been digitally signed by Microsoft. Tampering with them in any way renders the signature useless, and, if that happens, the shell will not import the files at startup. This design makes the files pretty secure against malware that might try to insert malicious code into them.
Of course, the Execution Policy, if left at Restricted, will also prevent your own Windows PowerShell profile scripts from being executed at startup. Windows PowerShell doesn't create a profile script by default, but it does search four specific locations for specific file names and, if it finds them, attempts to execute them every time the shell starts. (The documentation installed along with Windows PowerShell provides details about the folder and file names that are used for profile scripts.) The profile is the key to the exploit I'm going to discuss.

Modifying the Execution Policy
Cmdlet of the Month
The companion of Set-AuthenticodeSignature is Get-AuthenticodeSignature. This cmdlet is designed to examine a digitally signed script and give you details about the signature. Just point it to the file in question and you'll see not only if a file has been signed but whether the signature is intact, what certificate was used to sign the file, and so on. Besides working with Windows PowerShell scripts, this cmdlet also works with signed executables, like so:
PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *
By running this command, I can see that the executable was signed by Microsoft Corp. using a certificate issued by the Microsoft Code Signing CA.
Command results

Let me stress that under default conditions, it's very difficult—if not impossible—to get Windows PowerShell to execute any code, let alone malicious code. It's not until you modify the Execution Policy that malicious scripts even become possible. To be clear, this column is not a warning bell about security holes in Windows PowerShell; instead, it's meant to share some best practices for keeping your systems hardened.
The lowest Execution Policy is Unrestricted, which permits all scripts to run without restriction or question—essentially offering the same undesirable scenario you've had with VBScript and batch files for years. Set the shell to Unrestricted and you're just asking for a malicious script to come along and cause damage. If you do choose the Unrestricted setting, and a script comes along and clobbers you, be sure you can justify why you chose the Unrestricted setting, and be prepared to own up to your decision when you're explaining how a virus wiped out your environment!
To be fair, Windows PowerShell will still try to detect scripts downloaded from the Internet and warn you before running them, even when set to Unrestricted. But the point is that having an Execution Policy set to Unrestricted is a bad idea.

Signing Scripts
The most secure Execution Policy that permits scripts to be executed is AllSigned. This setting, as the name suggests, only executes scripts that carry an intact digital signature that was created using a trusted certificate (not just any old signature will do). Signing scripts requires you to acquire a Class III digital certificate—more specifically, a Microsoft Authenticode code-signing certificate. Such certificates can be obtained from the internal Public Key Infrastructure (PKI) of your company, if you have one, or purchased from commercial certificate authorities (CAs), such as CyberTrust, Thawte, and VeriSign.
If you want to know if you have any certificates installed on your machine that can be used for signing scripts, the following cmdlet will show you:
Get-ChildItem CERT: -recurse –codeSigningCert
After installing the certificate on your Windows® computer, you use the Set-AuthenticodeSignature cmdlet to create and apply a digital signature, which shows up as a series of gibberish-seeming comment lines at the end of the script. Some script editors may offer the option to apply a signature to a script file, including an opportunity to automatically sign scripts as you save them, which can be convenient.
AllSigned is the best Execution Policy to use in a production environment. While it doesn't prevent malicious scripts outright, it does ensure that a malicious script is signed and, therefore, you'd be able to track down the script's author (assuming your Windows computers are configured to trust only trustworthy CAs, but that topic is a bit beyond the scope of this column). Interestingly, Windows Script Host (WSH) 5.6 and later can be configured with a similar TrustPolicy setting that also requires digital signatures, but I've met few administrators who actually use this setting.
So here's a quick recap so far. With an Execution Policy set to Restricted, you're safe from malicious scripts, but you can't run beneficial ones, either. With your Execution Policy configured to AllSigned, the shell permits signed scripts, which is pretty safe since few malicious script authors want a verified, traceable identity applied to their work. The Unrestricted setting, on the other hand, is extremely unsafe and if you're using it, you can expect to get hit by some malicious script eventually. (Note that I don't regard the Unrestricted setting as a particular vulnerability because it doesn't pretend to be anything but insecure and if you're using this setting, you presumably know what you're in for.)

Sneaking in the Side Door
There's one more Execution Policy setting: RemoteSigned. This is the one I believe most administrators are using these days, simply because it's perceived as more secure than Unrestricted and less of a hassle than AllSigned. RemoteSigned does not require a signature for local scripts. PS1 files residing on your local drives will run without being signed. Remote scripts—primarily those downloaded from the Internet using Internet Explorer® or Outlook® (these apps mark downloaded files with a special flag)—won't run unless they're signed.
The RemoteSigned setting can give you a false sense of security, however. To begin with, it's easy to download remote scripts without having the special flag applied. Non-Microsoft browsers, for example, typically don't set this flag, nor do most non-Microsoft e-mail clients. It's important to note that without that flag, Windows PowerShell treats downloaded scripts as local ones—meaning a signature won't be required. Still, I don't regard this as a significant vulnerability. You have to actually download the script, open Windows PowerShell, and manually execute the script for it to run. It's a bit tough to trick someone into performing all these steps, and administrators—generally the only users on a network who have Windows PowerShell installed—should know better.
RemoteSigned does, however, offer a significant "side door" that malware can sneak through. Remember those Windows PowerShell profile scripts? If they exist—whether they were created by you or by a piece of malware—they'll execute every time Windows PowerShell runs. And under the RemoteSigned Execution Policy, your profile scripts—which are local—don't need to be signed.
Here's the scenario:
  1. Some piece of malware makes it onto your system and either creates a shell profile script or inserts malicious code into an existing profile script. Malware typically runs under your logged-on user account, which generally has permission to modify your profile script.
  2. You open Windows PowerShell, not realizing your profile script has been created or modified to include malicious code. The code executes, and the damage is done. The damage is worse if you're in the habit of opening Windows PowerShell under Administrator credentials—a common practice because when you're using the shell, you need administrative privileges to perform whatever tasks you're using the shell for.
The profile, then, presents a way for arbitrary and malicious code to execute without your knowledge, and the RemoteSigned Execution Policy allows it to happen.

Protecting the Profile
There is only one good way to protect your profile: Use the AllSigned Execution Policy. Under AllSigned, even your profile scripts must be digitally signed; otherwise, Windows PowerShell won't execute them at startup. And if you have signed your profile scripts, malicious modifications to them will break their digital signatures, leaving them unable to run—in fact, Windows PowerShell will alert you to the problem at startup. AllSigned really is the only safe Execution Policy setting for production environments that need to allow scripts to run.
There is another approach, but it's more complicated and less trustworthy. You can create blank profile script files for each of the four files Windows PowerShell looks for. Use a new user account (I'll call it "Profile Editor") to create these files and set the NTFS permissions of the files so that only the Profile Editor account can modify them. Other accounts can have read-only access.
Now, don't ever log on to your computer using the Profile Editor account except to edit your profile. With this approach, your normal user account (or accounts) won't be able to modify your profile scripts. And any malware that runs while you're logged on with a normal account won't be able to modify the scripts, either. What if malware happens to run while you're logged on as Profile Editor? Well, considering you'll be logged on as Profile Editor to edit your profile scripts anyway, you should notice the changes.
You can roll your own safety net, too, by creating an all-users profile script that's controlled with tight file permissions, as I just described. Within that script, write code that uses the Get-AuthenticodeSignature cmdlet to examine the digital signatures on the other profiles the shell looks for. This essentially lets you require signatures on profile scripts, without requiring them for other scripts.
The AllSigned Execution Policy, however, is a much more thorough way to protect your profile. My recommendation is that any computer connected to your network should have an Execution Policy of Restricted, preferably applied by Group Policy. This overrides any local setting and ensures that new domain computers are automatically set to disallow scripts. Computers on which scripts must be permitted should have an alternate Group Policy that sets the AllSigned Execution Policy. You must digitally sign all scripts, but you can rest easy knowing that only trusted scripts from identifiable authors are executing in your environment.

Don Jones is the Lead Scripting Guru for SAPIEN Technologies and coauthor of Windows PowerShell: TFM (SAPIEN Press, 2007). You can contact him at www.ScriptingAnswers.com.


 Hey, Scripting Guy!: There's No Mistaking Regular Expressions
Hey, Scripting Guy!
There's No Mistaking Regular Expressions
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2008_01.exe (150KB)

Everyone makes mistakes. (What, you thought the Scripting Guys team was created on purpose?) However, if there's anything positive that can be said about mistakes, it's—what's that? You thought we were going to say that the one positive thing about mistakes is that you can always learn from those mistakes? Oh, heavens no: about the only thing you can learn from a mistake is that you would have been way better off having never made that mistake in the first place.
Note: Sorry; no jokes about Microsoft Bob, not today. We made the mistake of poking fun at Microsoft Bob once before, and, in that case, we did learn from our mistake. When it comes to Microsoft Bob, our lips are sealed.
To be honest, the Scripting Guys can't really think of anything good to say about mistakes; that's why we've devoted our lives to minimizing the mistakes that we make. (Admittedly, the only way we could minimize our mistakes was by minimizing the number of things that we actually do. But that's another story.)
Now, it's all well and good that we've tried to minimize our own mistakes; however, that might not do us much good if the people we work with continue to make mistakes. (No, we already told you: no jokes about Microsoft Bob!) If you've ever written a front-end to, say, a database program or to Active Directory® (and we know that many of you have), then you know exactly what we're talking about: your front-end data entry program is only as good as the people doing the data entry.
Suppose you want first names to be entered like this: Ken, with an uppercase first letter and all subsequent letters in lowercase. What happens when a user enters that name like this: KEN? Suppose dates are supposed to be entered like this: 01/23/2007. What happens when a user enters a date like this: January 23, 2007? Suppose—well, you get the idea. Like we said, your front-end data entry program is only as good as the people doing the data entry. And, like it or not, data entry people are going to make mistakes. Unless, of course, you take steps to help ensure that they don't.

Make Sure Your Data Is Valid
Let the Games Be Over
Have you ever wondered what the one event is that the Scripting Guys look forward to all year? If you've been to the Script Center in February either of the past two years, you might guess that event is "The Winter Scripting Games." Well, you'd be wrong. The Scripting Guys look forward to the end of the Scripting Games, when—after two weeks of non-stop fun and excitement—the Scripting Guys get to bask in the glow of another successful Scripting Games competition and sleep for the next month.
So, in preparation for our favorite event of the year—the end of the Scripting Games—it's time to start the 2008 Winter Scripting Games! Join us February 15-March 3, 2008, at the Script Center for more than two weeks of scripting fun and the best scripting competition in existence.
The Scripting Games are a great way to test—and improve—your scripting skills. And because this year the Scripting Guys want to sleep for an extra few days after the competition is over, we're making this year's competition even bigger and better than last year! Once again, we'll have two divisions: Beginner and Advanced. That means that whether you're brand new to scripting, an old (or young) pro, or somewhere in between, this competition is for you.
So what's new this year? We're adding yet another scripting language. You can enter the competition in VBScript, Windows PowerShell, or—here's the new one—Perl. (We know Perl isn't new, but it's new to this competition.) There will probably be even more fun, but since we had to put this sidebar together months ago we have no idea what it will be. You'll have to come to the Script Center to find out what we came up with.
In case you're wondering, yes, there will be prizes! What will they be? Hey, we're not spoiling the surprise here—come to the Script Center and find out! microsoft.com/technet/scriptcenter/funzone/games/default.mspx.

A lot of you are probably already doing rudimentary data entry validation. And, for many things, this simple data entry validation is perfectly fine. Need to make sure that the string value strName has 20 or fewer characters in it? This tiny block of code will do:
If Len(strName) > 20 Then
    Wscript.Echo "Invalid name; a " & _
    "name must have 20 or fewer characters."
End If
But suppose strName is a new part number, and part numbers must meet a specified pattern: four digits followed by two uppercase letters (something like 1234AB). Using plain vanilla VBScript, can you verify that strName follows the required pattern for part numbers? Yes, you can. But trust us, you don't want to. Instead, you want to use a regular expression.

Make Sure that Only Numbers Appear in a Value
Regular expressions date back to the 1950s, when they were first described as a form of mathematical notation. In the 1960s, this mathematical model was incorporated into the QED text editor as a way to search for character patterns in a text file. Sometime after that—what's that? Oh. Apparently not everyone finds the history of regular expressions as fascinating as we do. Okey doke. In that case, we'll just show you what we're talking about.
Want to make sure a variable (in this case, the variable strSearchString) contains only numbers? Figure 1 shows one way to do that.
Figure 1 Numbers only, please (Close Figure 1)
Set objRegEx = _
  CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\D"

strSearchString = "353627"

Set colMatches = _
  objRegEx.Execute(strSearchString)

If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
As you can see, the script starts out by creating an instance of the VBScript.RegExp object, the object that—well, yes, you're right, the object that enables us to use regular expressions in our script. (Ah, we wanted to be the ones to explain that.) After that, we assign values to two key properties of the regular expressions object: Global and Pattern.
The Global property determines whether the script should match all occurrences of a pattern or should simply find the first such occurrence and then stop. In general, you're better off setting this value to True, meaning you want to search for all occurrences of a pattern. (The default is False.) More often than not, you will want to find all occurrences of a pattern. Even if you don't, the only advantage to finding just the first occurrence of a pattern is that the script will run faster if it stops partway through the string rather than searching all the way to the end. In theory, that sounds good. In practice, though, the search typically completes so quickly that you won't notice much of a difference.
This is the good part: the Pattern is where we specify the characters (and the character blueprint) we're interested in. In our sample script, we're looking for any character that isn't one of the digits 0 through 9. If we find such a character (a letter, a punctuation mark, whatever), then we know the value assigned to strSearchString isn't valid. With regular expressions, the syntax \D is used to match any non-digit character; thus we assign the value \D to the Pattern property.
Note: How did we know that \D matches any non-digit character? Well, there's a long history behind that. You see, several years ago—oh, right. We looked this up in the VBScript language reference on MSDN® at msdn2.microsoft.com/1400241x.
After assigning values to the Global and Pattern properties, our next step is to assign a value to the variable strSearchString:
strSearchString = "353627"
So how do we know whether there are any non-digit characters in this string? That's easy. We just call the Execute method, which searches our variable for any non-digit characters:
Set colMatches = _
objRegEx.Execute(strSearchString)
When you call the Execute method, any matches—that is, any instances of the Pattern—that are found are automatically stored in the Matches collection. (In our sample script, we gave this collection the name colMatches.) If we want to know whether or not our variable contains any non-digit characters (and we do), all we have to do now is check the value of the collection's Count property, which tells us how many items are in the collection:
If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
If the Count is greater than 0, that can mean only one thing: a non-digit character was found somewhere in the variable value. (If all the characters in the value were digits, then the collection would be empty and thus have a Count of 0.) In our sample script, we then echo back the fact that a non-numeric character was discovered. In an actual script or database front end, you'd probably echo a similar message and loop back around to have the user try again. But we'll let you worry about that; as Scripting Guys, we have plenty of other things to worry about.
Like what? Like the thought that someday the people at TechNet Magazine might actually start reading the articles we send to them each month. We'd just as soon they not learn from their mistakes.
Ah, good question: couldn't we just use the IsNumeric function to determine whether or not strSearchString contains a number? Sure, provided that strSearchString can be any number. But what if strSearchString must be a positive integer? That could be a problem; IsNumeric identifies both of these as valid numbers:
-45
672.69
Why are these identified as valid numbers? Because they are valid numbers; they just aren't positive integers. Our regular expression will flag these as invalid entries, however, because the regular expression catches the non-digit characters minus sign (–) and period (.). If you've been reading this column and thinking, "Why am I reading this column?" well, there's a pretty good reason right there.
What's that you said? That's not good enough? Wow, tough crowd this month. OK, let's take a look at a few other types of data entry validation that can be accomplished using regular expressions.

Make Sure that No Numbers Appear in a Value
We just showed you how to ensure that only numbers appear in a value. What if we wanted to do the opposite; what if we wanted to make sure that no numbers appear in our value? Well, here's one search pattern we can use:
objRegEx.Pattern = "[0-9]"
What's going on here? Well, in the wild and wacky world of regular expressions, the bracket characters ([ and ]) enable you to specify a set of characters or, as we've done here, a range of characters. What does the Pattern [0-9] mean? That means we're searching for any characters in the range 0 through 9—in other words, any numeric value. If we wanted only even numbers (that is, if we wanted to ensure that our value doesn't include any 1s, 3s, 5s, 7s, or 9s), we would use this pattern:
objRegEx.Pattern = "[13579]"
Note that because we didn't use a hyphen, we aren't looking for a range of characters. In fact, we're looking for the actual characters 1, 3, 5, 7, and 9, specifically.
Of course, the pattern [0-9] looks only for numbers; it won't find punctuation marks or other characters that aren't letters but aren't numbers, either. Do you think we can create a pattern that looks for any non-letter characters? Of course we can. You can do practically anything you want with regular expressions:
objRegEx.Pattern = "[^A-Z][^a-z]"
In this case, we're actually combining two criteria in our pattern: we're searching for [^A-Z] and [^a-z]. As you probably figured out, A-Z means the range of characters from, well, uppercase A to uppercase Z. What does the ^ character mean? Well, when included in a pair of square brackets, the ^ means, "Look for any character not in the character set." Thus, [^A-Z] means, "Look for any character that isn't an uppercase letter." Meanwhile, [^a-z] means, "Look for any character that isn't a lowercase letter." The net result: this pattern means that we're looking for anything that isn't an uppercase letter or a lowercase letter. That includes numbers, punctuation marks, and any other weird characters you might find on your keyboard.
Alternatively, we could have set the IgnoreCase property to True:
objRegEx.IgnoreCase = True
By doing that, our search would ignore letter case. In turn, we could then use this Pattern, which—combined with the IgnoreCase property—would look for anything that isn't an uppercase or lowercase letter:
objRegEx.Pattern = "[^A-Z]"

Make Sure a Part Number Is Valid
Now let's get a little fancier. (And, trust us, you can get really fancy with regular expressions; take a look at the Web site regexlib.com for some examples.) Earlier in this article we said something like this: Suppose strName is a new part number, and part numbers must meet a specified pattern: four digits followed by two uppercase letters (for example, 1234AB). How can you verify that a variable meets this pattern? Why, like this, of course:
objRegEx.Pattern = "^\d{4}[A-Z]{2}"
What does this pattern mean? What a coincidence: we were just about to explain what this pattern means. In this case, we have three criteria we're searching for:
^\d{4}
The \d means we're looking for digits (a character in the range 0 through 9). What does the {4} mean? That means we want to match exactly four of the characters (that is, exactly four digits). Thus we're looking for four consecutive digits.
And what about the ^ character? Well, outside a pair of square brackets, the ^ indicates that the value must begin with the subsequent pattern; that means that AA1234AB would not be flagged as a match. (Why? Because the value actually begins with AA, not with four consecutive digits.) If we wanted to, we could use the $ character to indicate that the match must occur at the end of the string. But we just don't want to. (Well, at least not with this example.)
[A-Z]{2}
You already know what the [A-Z] component means; that's any uppercase letter. And the {2}? You got it: the four digits must be followed by exactly two uppercase characters.
Pretty easy, huh? By the way, in this case, if the Count is 0 then we have an invalid value. Why? Well, this time we're not searching for a single character that would invalidate the string; instead, we're searching for an exact pattern match. If we don't get such a match, that means we have an invalid value. And it also means that the collection's Count property will be 0.
Note: Two other useful constructions are these: {3,} and {3,7}. The {3,} means that there must be at least 3 consecutive characters (or expressions); however, while there is a minimum of 3, there is no maximum. This \d{3,} matches 123, it matches 1234, and it also matches 123456789. The {3,7} means there must be at least 3 consecutive characters (or expressions) but no more than 7. Thus 123456 is a match, but 123456789 (which has more than 7 consecutive digits) is not a match.
Here's another useful pattern. Suppose your part number starts off with 4 digits followed by the letters US followed by two final characters (which might be letters, or might be numbers, or might be anything). Here's one way to match that:
objRegEx.Pattern = "^\d{4}US.."
As you can see, this pattern starts off with four digits (\d), which must be followed by the characters US (and only the characters US; anything else will not be a match). After the characters US, we then need two more characters of some kind. How do we indicate any character in a regular expression? Hold on a second; we know this one ... wait, we've got it: any single character is indicated by a period (.). Logically enough, that means two characters can be indicated by two periods:
..
OK, that one was easy. Let's try a harder one. Suppose those internal two characters indicate the country where the part was manufactured. If you have manufacturing plants in the U.S., the U.K., and Spain, that means that any of these two-character codes are valid: US, UK, ES. How the heck can we do multiple-choice in a regular expression?
Well, how about like this:
objRegEx.Pattern = "^\d{4}(US|UK|ES).."
The key here is this little construction: (US|UK|ES). We've placed the three acceptable values (US, UK, and ES) inside a set of parentheses, separating each value with the pipe (|) character. That's how you do multiple-choice with a regular expression.
But wait: didn't we say that you could place multiple options inside square brackets? Isn't that what the whole [13579] thing was for? Yes, it was. However, that works only for single characters; [13579] will always be interpreted as 1, 3, 5, 7, and 9. To use 135 and 79 as the choices, you need to use this syntax: (135|79). You can also use parentheses to delineate a single word to be searched for:
objRegEx.Pattern = "(scripting)"
Or, just leave the parentheses off:
objRegEx.Pattern = "scripting"
Note: OK, that's good to know but what if the parentheses need to be included as part of the search term; that is, what if I want to search for (scripting)? Well, because both the open and close parentheses are reserved characters in regular expressions, you need to preface each character with a \. In other words:
objRegEx.Pattern = "\(scripting\)"

Freedom of Expression
That's all the time we have for this month. If you'd like to learn more about regular expressions, well, you might want to take a peek at the webcast String Theory for System Administrators: An Introduction to Regular Expressions (microsoft.com/technet/scriptcenter/webcasts/archive.mspx). And as you start to learn, and use, regular expressions, be sure to keep in mind the immortal words of Sophia Loren: "Mistakes are part of the dues one pays for a full life."
Wow. The Scripting Guys have lived much fuller lives than we realized!

Dr. Scripto's Scripting Perplexer
The monthly challenge that tests not only your puzzle-solving skills, but also your scripting skills.

January 2008: Winding Nouns
This month Dr. Scripto decided to work with Windows PowerShell. Of course, you can't work with Windows PowerShell—not if you're using it right anyway (and Dr. Scripto always does everything right)—without using cmdlets. For this puzzle, Dr. Scripto has wound some cmdlets around a grid, and you need to find them.
Now, we have to admit this puzzle would be a little more confusing if we were to use the whole cmdlet. Because of the verb-noun construct of cmdlets, there are dozens that start with Get-, Set-, and so on. So we've left off the verb part of the cmdlet (and the hyphen), leaving only the nouns. (But we'll tell you that all of the verbs were "Get-".)
Your task this month is to unwind the cmdlet nouns. We've provided you with the list of nouns hidden in the puzzle. (Are we generous or what?) Each word can wind around vertically and horizontally, forward and backward, but never diagonally. We've given you the first word (Location) as an example. Good luck.

Word List
Alias
ChildItem
Credential
Date
EventLog
ExecutionPolicy
Location
Member
PSSnapin
TraceSource
Unique
Variable
WMIObject

Dr. Scripto's Scripting Perplexer
Answer: Winding Nouns, January 2008

The Microsoft Scripting GuysThe 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: Island Hopping: The Infectious Allure of Vendor Swag
Security Watch
Island Hopping: The Infectious Allure of Vendor Swag
Jesper M. Johansson

The technique of island hopping—penetrating a network through a weak link and then hopping around systems within that network—has been around for years. But it continues to take on new dimensions. In today's security-conscious IT environments, people are often the weakest link, and malicious users are
finding ways to use this to their advantage (think phishing and other forms of social engineering). This combination of carbon and silicon can prove fatal to your network.
One of my favorite implementations of leveraging the human element was perpetrated by Steve Stasiukonis of Secure Network Technologies during a penetration test for a customer. He seeded the customer's parking lot with USB flash drives, each of which had a Trojan horse installed on it. When the employees arrived for work in the morning, they were quite excited to find the free gadgets laying around the parking lot. Employees eagerly collected the USB drives and plugged them into the first computers they came across: their own workstations.
Maybe some employees were wise enough to ignore these USB drives, and perhaps some of the USB drives were discarded, but it really only took one user with one drive to infect his own system and provide a gateway into the network. Stasiukonis did this exercise as a test, of course, but this technique has been used by real criminals to infiltrate large corporate networks.
USB flash drives are everywhere these days. At almost every conference, some vendor is giving them away like candy. Those drives may not have a lot of capacity, but you don't need a lot of storage space to take over an entire network. In this two-part series, I will investigate this type of attack and show ways you can help mitigate the risk. In this month's installment, I will discuss what exactly USB flash drives can do and what you can do to control them. In next month's issue of TechNet Magazine, I will show you how to contain an attack to a single or small set of systems on the network.
The technical details of the attack are actually quite simple. It all starts with an infected USB flash drive being inserted into a single computer. What happens then depends on the payload on that drive and, of course, how gullible the user is.

In the Beginning
On the podium was an unattended laptop. The speaker was busily trying to ingratiate himself with the audience before beginning his presentation. The laptop itself was locked, but that hardly mattered. The attacker went up to the podium and lingered a bit, looking like he was just waiting for the speaker to return. Since those podiums are designed to hide ugly things like computers, the USB ports and the attacker's hands were shielded from view. Once the USB flash drive was inserted into the computer, it took only a few seconds to complete the attack.
There are some obvious variations on this particular theme. For example, when I used to travel the world doing presentations on a weekly basis, almost every time I finished, there were a few people asking for a copy of my slides. My answer was always to hand them a business card and ask them to send me an e-mail message. Why would I do that when every one of them was eagerly holding a USB flash drive toward me? Because I know about tools like USB Hacksaw and Switchblade. (If you aren't familiar with these, look them up at wiki.hak5.org.)
Basically, these tools make it really easy for just about anyone to exploit people who leave their USB ports unprotected. For example, Switchblade can dump the following:
  • System information
  • All network services
  • A list of ports that are listening
  • All product keys for Microsoft products on the computer
  • The local password database
  • The password of any wireless networks the computer uses
  • All network passwords the currently logged on user has stored on the computer
  • Internet Explorer®, Messenger, Firefox, and e-mail passwords
  • The Local Security Authority (LSA) secrets, which contain all service account passwords in clear text
  • A list of installed patches
  • A recent browsing history
All of this goes into a log file on the flash drive, and takes about 45 seconds.
Hacksaw is a slightly modified version; it installs a Trojan on the computer, which monitors all USB flash drive insertion events. It then e-mails all documents from all flash drives subsequently inserted into the computer to the attacker.
The tools I have discussed so far use U3 (u3.com), a technology designed to enable users to bring programs with them on a flash drive. In a nutshell, a U3-enabled flash drive lies about itself. It tells the OS that it is actually a USB hub with a flash drive and a CD plugged into it. Windows® versions prior to Windows Vista® will, by default, automatically run programs designated in the autorun.inf file on CDs, but not on USB drives. By lying about itself, the U3-enabled USB flash drive fools the OS into autorunning something called the U3 launcher. The U3 launcher, in turn, can start programs, give you a menu, or do pretty much anything that you could do with the computer yourself.
All the exploit tools do is replace the launcher with the exploit code. As soon as the flash drive is plugged into a Windows XP system, the exploit tool automatically runs. On Windows Vista, the AutoPlay decision flow works differently. AutoRun is actually enabled on removable devices, just like on CDs. That means you will have some sort of action happen when the device is inserted. By default, the AutoPlay dialog will appear, as shown in Figure 1.
Figure 1 Default AutoPlay dialog appears when a user inserts a removable drive with pictures
Figure 1 Default AutoPlay dialog appears when a user inserts a removable drive with pictures
Notice that the dialog in Figure 1 has an option to "Always do this for pictures." This sets an AutoPlay option, which can be configured in the Control Panel, shown in Figure 2.
Figure 2 AutoPlay configuration on Windows Vista
Figure 2 AutoPlay configuration on Windows Vista
The AutoPlay configuration is particularly interesting for "Software and games." By definition, it means the removable drive has an autorun.inf file that specifies some program to be executed. The settings in Figure 2 related to "Software and games" are stored in the following registry key:
Hive:    HKEY_CURRENT_USER
Key:    \Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\
UserChosenExecuteHandlers\AutorunINFLegacyArrival
Value: (Default)
Data:
MSAutoRun – automatically executes the program specified in the autorun.inf file

MSPromptEachTime – prompts the user, using strings specified in the autorun.inf file, if available
As you do not need to be an administrator to modify these settings, users can set them to whatever they want, including automatically running whatever malware is on the drive they found in the parking lot. In fact, they can do it by checking the appropriate box in the AutoPlay dialog.

Managing AutoPlay in Your Network
As an administrator, there are a couple of ways you can manage AutoPlay throughout your network. First, you can prevent a user from enabling AutoPlay on removable media and CDs by modifying the NoDriveTypeAutoRun setting that controls which drive types AutoPlay is enabled for. Windows XP shipped with NoDriveTypeAutoRun set to 0x95, which disables AutoPlay on unknown drive types, network drives, and removable devices. Starting with Windows XP SP2, the NoDriveTypeAutoRun setting is configured to 0x91 by default. This enables AutoPlay on removable storage devices. Using Group Policy, there is a setting under User Configuration\Administrative Templates\Windows Components\AutoPlay Polices that allows you to manage the NoDriveTypeAutoRun setting. Enabling the "Turn off AutoPlay setting and select CD-ROM and Removable Drives" will disable AutoPlay on both types of drives.
As a result, though, the user does not get the AutoPlay dialog from Figure 1. In fact, nothing at all happens when the user inserts the drive. That may not be an ideal solution, however, as it can cause confusion for the user who isn't sure how to access the necessary information on the drive.
What you probably want to do is control which types of content can be played automatically. You can do this to some extent on Windows Vista, as this OS effectively has two levels of controls over automatically running software. Another control in Group Policy, shown in Figure 3, allows you to disable AutoPlay of software using autorun.inf files, while leaving the remainder of the Windows Vista AutoPlay behavior intact.
Figure 3 Disable autorun.inf files with Group Policy
Figure 3 Disable autorun.inf files with Group Policy
The decision flow is a bit complicated when it comes to AutoPlay, and perhaps it is easiest to show with a flowchart. Figure 4 depicts the decision flow used when determining whether to automatically execute a file on removable media.
Figure 4 The AutoPlay decision flow
Figure 4 The AutoPlay decision flow

Other Beginnings
Of course, these are just some of the tools that can be used to compromise a computer with a USB flash drive. All sorts of tools can be added to this scenario, such as a tool that dumps out the currently logged-on user's Windows NT® password hash (see microsoft.com/technet/community/columns/secmgmt/sm1005.mspx).
Many USB controllers are actually Direct Memory Access (DMA) devices. This means they can bypass the operating system and directly read and write memory on the computer. Bypass the OS and you bypass the security controls it provides—now you have complete and unfettered access to the hardware. This renders device control implemented by the OS completely ineffective. I am unaware of any hacking tools that currently use this technique, but I very much doubt that this has not already been done.
Another way to exploit the user/removable device combination is to simply present an enticing option. For example, how many users would click the dialog in Figure 5? Not all, but probably many. The point is, it's a fairly trivial task to concoct a dialog that will be too enticing for users to ignore.
Figure 5 How many users would fall prey to this?
Figure 5 How many users would fall prey to this?

Device Blocking
New in Windows Vista, Group Policy now has a set of policies to govern device installation (see Figure 6). As shown, the administrator can block all new removable devices from installing if the driver specifies that they are removable. If the driver states that they are not, however, the policy does not take effect. Thus, this policy can be circumvented using custom drivers.
Figure 6 Windows Vista device installation policies
Figure 6 Windows Vista device installation policies
For more granular control, the administrator can use the policies to act on specific device setup classes. However, those require you to know the GUID for the specific device class you wish to block (or allow), making this approach considerably more difficult to manage.

Least Privilege Really Matters
Ignoring the DMA scenario for a moment, the success of the attacks I have discussed, as well as the success of the countermeasures, will depend on the privileges of the user using the computer. If the user is a standard user, the amount of damage the exploit can do is limited. It can still steal that user's data and anything that user has access to. However, the attack will likely not impact the network at large.
However, if the user being exploited is an administrator, the consequences can be a whole lot worse. In the worst-case scenario, the user is a Domain Administrator, and taking over the entire network is trivial. For instance, the attacker could extract the user's password hash from memory. The system caches the hash within the LSA process space at logon so that it can be used to transparently access network resources on behalf of the user. An attacker with administrative privileges can extract this hash and access any network resources with it. In other words, if the user is a Domain Administrator, the entire domain has been compromised.
This leads me to the topic of dependencies. So far, I have outlined a specific attack on workstations. I have not, however, explored what the attack can lead to on a network scale. In next month's column, I will explore the concept of dependencies, showing you what they mean for the environment as a whole and, more importantly, what you can do to harden these dependencies.

Jesper M. Johansson is a Security Engineer working on software security issues and is a contributing editor to TechNet Magazine. He holds a PhD in MIS and has more than 20 years of experience in security.


 The Desktop Files: Shared Computing with Windows SteadyState
The Desktop Files
Shared Computing with Windows SteadyState
Wes Miller

I know if you've been anywhere near a computer lab in the last 10 years or so, you're familiar with this problem. It was something I first saw when I was in college. At the time, the labs were open all hours of the day (with your student ID) and were effectively unattended once you were in the library. The student gamers of that era
would come in and make modifications to the key Windows® and MS-DOS® files to run their games. The end result was a machine that might run their game well, but didn't run Windows well, if at all. We've all experienced it at some point—the shared-use computer that has been beaten down to the point that trying to use it is no longer an effective use of time.
Recently I took a vacation to South Padre Island here in Texas. The hotel I stayed at had three computers in a "guest computer room" running Windows XP. Everyone running on these Windows systems was an administrator and they had no policies in place—meaning each of these poor computers had been abused pretty heavily by visitors installing rogue software and removing or changing core apps—most likely not the experience the hotel had intended. Whether in a lab or a hotel, the truth is that shared-use computers in a public environment are put through a punishing life that often bests what some home computers see.

Solutions to the Problem
Getting and Using SteadyState
Windows SteadyState is available as a free download from go.microsoft.com/fwlink/?LinkId=104721. More information about SteadyState is available from microsoft.com/windows/products/winfamily/sharedaccess.
Windows SteadyState will run on any system that can run Windows XP. The most significant improvement over the SCT is that SteadyState does not require a second partition to function as SCT did for Windows Disk Protection.
The following table provides an overview of the system requirements for SteadyState. Note that SteadyState does need an NTFS-formatted file system, though any version of Windows XP is supported. SteadyState does not currently work with Windows Vista®.

Component | Requirement
Processor | 300 MHz or higher (233 MHz minimum).
Memory | 128MB of RAM or higher (64MB minimum; may limit performance and some features).
Hard disk | Minimum of 1.5GB of available hard disk space without Windows Disk Protection, or a minimum of 4.0GB of available hard disk space with Windows Disk Protection.
Operating system | Windows XP Home Edition, Windows XP Professional. or Windows XP Tablet PC Edition. Windows XP SP2 must be installed.
Supported localized languages | English, Dutch, French, Italian, Japanese, Portuguese Brazilian, Simplified Chinese, and Spanish.
File system | NTFS formatted file system.
Access | Administrator level access.

If you've been reading my column for the past year, or if you're familiar with Windows deployment in general, you might be thinking, "big deal—I'll just re-image the systems." But those of you who have lived that life know it's not always that simple. Hitting the big red reimage button every day or every week doesn't really scale.
Years ago, a friend and I looked into starting a cybercafé. This was back in 1995 when it was still a somewhat unique idea. My biggest concern was actually ensuring system reliability and availability. Unfortunately, the options at that time were largely all reimaging or slightly more robust solutions; there wasn't anything plug-and-play to solve the problem.
Breaking down the issue, when securing shared-use computers, you want to be able to do three things:
  • Ensure that users run only as non-administrators. This should always be the case on shared computers.
  • Put policy into place so the systems are as secure as possible. That way, there's a low potential of users being able manipulate areas of the system they shouldn't have access to.
  • Be able to roll back any random changes made by users. Even if users are running as non-administrators, they can still make rogue changes to menus, favorites, and so on.
Fortunately, Microsoft has been working for several years on a toolset designed to help in just this scenario.

History of SteadyState
A little over a year ago, Microsoft released the Windows Shared Computing Toolkit (SCT). Available as a free download for Windows Genuine Advantage verified systems, the toolkit was designed specifically with libraries, cybercafés, labs, and other shared computing environments in mind. You may have seen coverage of the SCT back in the July 2006 issue of TechNet Magazine (technetmagazine.com/issues/2006/07/UtilitySpotlight).
A new version, now renamed Windows SteadyStateTM (microsoft.com/windows/products/winfamily/sharedaccess), shipped in June 2007. The new version was renamed in part because the toolset changed significantly between versions. It still performs the same tasks that I'll drill into in a moment, but the team focused on overall ease of use in the newest release. As a result, SteadyState is integrated tightly into a new console, and is easier to install and manage. It is more powerful and flexible, and it supports Active Directory® integration for one of its key components—meaning increased flexibility in several entirely new enterprise scenarios. It also now supports Windows Update integration so SteadyState has the intelligence to know when to turn Windows Disk Protection off to apply updates on its own. This reduces the management overhead you have to dedicate to your SteadyState-managed systems.

Features of SteadyState
Windows SteadyState consists of four key components: Computer Restrictions locks down per-computer security and configuration options; Windows Disk Protection caches (and reverts) changes to the Windows system partition; User Account Manager creates, edits, imports, or exports a user; and finally, User Restrictions and Settings locks down per-user security and configuration options.
One immediate improvement you'll notice over the Shared Computing Toolkit is the user help. A startup guide helps you get SteadyState up and running. Then SteadyState offers four key tasks to dive deeper into (mirroring the key features I outlined above):
  • Set Computer Restrictions (Computer Restrictions).
  • Schedule Software Updates. (Allows you to specify whether SteadyState automatically applies Windows Updates. This is recommended, since it handles dealing with Windows Disk Protection for you, and also updates the signatures of several popular Antivirus programs.)
  • Protect the Hard Disk (Windows Disk Protection).
  • Add User (User Account Manager).
Under Add User you'll find User Restrictions and Settings, which gives you a per-user configuration option.

Computer and User Restrictions and Settings
If you are familiar with Windows Group Policy, you are already familiar with the Set Computer Restrictions and User Restrictions and Settings aspects of SteadyState. Rather than forcing SteadyState administrators to use the Group Policy Object Editor (GPEdit.msc), which is not a feature that is available on Windows XP Home Edition (though SteadyState is supported on it), SteadyState bubbles up several key security and configuration options that are common in the shared computing scenario.
Figure 1 shows the configuration screen for Set Computer Restrictions. Note that these are all generic settings that will apply to the entire computer. These settings are primarily selected to minimize the security risks to the system—and in the case of USB drive access, the ability to remove things from the system. (When you look at per-user settings, you'll see a way to block read access to some or all drives, too.)
Figure 1 Computer restrictions in SteadyState
Figure 1 Computer restrictions in SteadyState
It's important to note that the USB setting is only active while running under the actual Windows installation where SteadyState is configured. In order to secure against offline attacks, you should properly configure the BIOS to block booting from USB or CD devices and password-protect the BIOS itself.
Of course, this is not foolproof. Remember the third law from the "10 Immutable Laws of Security" (microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx): "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." A dedicated individual with enough time and the right tools can often bypass a BIOS password.

Windows Disk Protection
If you've ever used Windows XP Embedded from a CD, or Windows PE 2.0, what I'm about to describe is going to sound familiar, and for good reason—they have a shared history. Windows Disk Protection works to provide a full "undo" of the Windows system partition by saving all changes made to the system partition to a cache on the same partition. This aspect of SteadyState is critical, since it is the component that allows you to undo the changes made by users of the system over time.
Windows Disk Protection is useful primarily if you want to ensure that over time you can rapidly roll back (either after an unscheduled restart or at a scheduled interval) to the initial deployed state of the system. It has four modes you can set in the dialog shown in Figure 2:
Figure 2 Configuring Windows Disk Protection
Figure 2 Configuring Windows Disk Protection
Off Windows Disk Protection is completely disabled, and all changes are written to disk normally.
On—Discard changes at reboot Windows Disk Protection is enabled, and every time you restart the computer, all changes will be discarded. In essence, this means the system will revert to exactly where it was when you checked and saved this option.
On—Discard changes at set time Almost identical to the previous options except changes are discarded at a set time, not at the next restart. This would be a logical choice if you wanted to discard changes daily or weekly.
On—Retain changes permanently Conceptually confusing with Off, but the difference here is that this is a temporary mode. For example, you could use this mode if you want to apply application updates, install new applications, or configure the system. This is not a mode you would generally run in for any significant length of time.
Note that Windows Disk Protection requires a reboot to change between any of these modes.

Schedule Software Updates
The Schedule Software Updates setting is handy in that SteadyState now has the ability to turn Windows Disk Protection off or on automatically for you. If you allow SteadyState to handle your updates, it sets Windows Disk Protection to keep the changes during the update and then returns Windows Disk Protection to what was previously set. I definitely recommend this setting since it eliminates one chore on your management task list.
The following security software is supported via the update feature in Software Updates: Computer Associates eTrust 7.0, McAfee VirusScan, Windows Defender, and TrendMicro 7.0.

User Account Manager
The Add User option lets you configure new users for the system. Figure 3 shows the options available for your new user: name, password, an image to represent the user, and the location of the user profile. Once you've created users, you can set User Restrictions and Settings for each of these local accounts. The nice thing is that once you've added and configured an account on your system, you can export it and then import it to another system as needed (or to archive it).
Figure 3 Adding user accounts
Figure 3 Adding user accounts
A handy aspect of the User Account Manager is that user profiles can be created on a secondary partition via the User Location menu shown in Figure 3. Usually profiles must be created on the Windows partition unless you manually specified a different Documents and Settings location during setup via an unattend.txt file. This approach is particularly useful with SteadyState since it discards changes made to the Windows system partition when Windows Disk Protection is enabled. If you want to have a user's profile remain consistent through Windows Disk Protection cache purges, you can simply specify the user's profile to be stored on another local partition when creating the user via User Account Manager.
This process works by rebooting to clear the Windows Disk Protection cache, applying the updates and then rebooting again to restart Windows Disk Protection. In addition to Windows Update, SteadyState will update the signature files for several popular antivirus applications that are supported (see the "Getting and Using SteadyState" sidebar). If your application is not supported or you need to run another updater, you can take care of the update manually—just ensure that Windows Disk Protection is disabled when you do so, or the signature update will be lost.

User Restrictions and Settings
Once you've selected a user, SteadyState breaks down User Restrictions into four categories. These are derived from Group Policy settings and will probably seem familiar to you.
The General settings control user profiles and forced logoff configurations. This includes settings for locking the profile and setting timeout intervals for logging out after either a configured duration of use or idle time.
The Windows Restrictions settings, shown in Figure 4, control Windows-specific configuration items. Examples include removing access to Windows user interface items such as components of the Start Menu, and Windows Explorer functionality. The ability to block access to specific drives by drive letter is also available, as is the ability to disable CD burning.
Figure 4 Windows-specific user restrictions
Figure 4 Windows-specific user restrictions
The Feature Restrictions tab, shown in Figure 5, controls granular access to most Internet Explorer® functionality, allows you to set the Internet Explorer home page, and to control Microsoft® Office functionality to a degree—largely around controlling the ability for Visual Basic® for Applications (VBA) scripts to be executed.
Figure 5 Feature restrictions
Figure 5 Feature restrictions
The Block Programs settings (see Figure 6) control the ability to run specific applications—basically you create a blacklist. This is populated with several common applications, and you can add others. Note that these items are blocked based on a definition of their path. If a user is allowed to move an application somewhere else on the system, the path rule won't apply any longer. Correctly applied file and directory ACLs and access restrictions to the system in other ways will prevent the easy ability to do this, however.
Figure 6 Blocking programs from executing
Figure 6 Blocking programs from executing
Another important new capability of SteadyState is based on the preconfigured templates that specify Restriction Levels related to both Windows Restrictions and Feature Restrictions. The templates make it easier to get a baseline configuration working depending on your desired level of feature/function lockdown. Of course you have the ability to build custom templates as well.

Limitations of SteadyState
SteadyState does a great job of helping an organization stabilize its shared computing systems. For a commercial tool, it would be good. For a free tool, it's very admirable. But, remember, it doesn't do everything.
Shared computing systems are easy targets for attack or even non-intentional abuse. You should ensure that these systems are isolated from information they don't need to be able to access. While SteadyState also has the ability to block access to applications, these enforcements are handled via Software Restriction Policies. And as Mark Russinovich noted a few years back, there are techniques whereby a savvy user can craft an app that looks benign, but even as a Limited User will still allow them to bypass these policies (blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx). Short of blocking all device access and Internet access, this is a vulnerability you'll need to bear in mind. Always remember Law #3 ...
Obviously, SteadyState is just one component of a well-configured shared computing system. Regular application of updates via Windows Update and proper configuration of Windows Firewall (or another firewall) are important. Also, be sure to install and configure antivirus, anti-spyware, and other security countermeasures necessitated by analyzing the potential risks to the computer. Likewise, control access to the computer—if you can't control that, control what the computer can see. And don't store confidential data locally.
Finally, when qualifying your platform, make sure your testing includes using SteadyState (with Windows Disk Protection enabled, unless you plan to not use it) and all additional software you plan to run on the system. You will want to ensure that the software and SteadyState work optimally together.

Support for SteadyState
The user feedback I've seen for SteadyState is very positive. There are a few minor gotchas I've heard of so far, some involving the order in which you need to add users. Many of these gotchas (along with other tips and tricks) are covered in the very active Windows SteadyState Community (conveniently linked to from several places in the SteadyState application and documentation) at forums.microsoft.com/windowstoolsandutilities.
I'd also recommend before starting that you review the SteadyState handbook, which is available at go.microsoft.com/fwlink/?LinkId=104722. It provides quite a few tips and tricks to using SteadyState successfully.

Wrap-Up
SteadyState provides a great package of functionality for any Windows XP system for which you need to control access to—and it's free! The dramatically improved Windows Disk Protection functionality and user interface enhancements mean easier deployment and easier overall management of your shared-access systems.
Whether your needs are for computer lab systems, visitor or employee shared-access kiosks, training rooms, or any other shared computing needs, SteadyState can help you get—and keep—the systems up and running easier. And it won't require you to do any more weekly reimaging just to jumpstart a system over again. That's a huge improvement in my book.

Wes Milleris a Technical Product Manager at Initiate Systems (InitiateSystems.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager for Microsoft. Wes can be reached at technet@getwired.com.


 Field Notes: Your Most Important Task of the Day
Field Notes
Your Most Important Task of the Day
Eric N. Bush

Bill Gates gets away from the office twice a year for what he calls his "think week." He isolates himself from people, phone calls, and e-mail, and he devotes this time to reading. He ponders the state of technology at Microsoft and in the world. He tries to understand what his company and others are working on and how they can move forward in a more strategic manner. Gates knows the value of pondering and planning.
Each of us can benefit by reserving time every day to simply think and plan—time to formulate ideas, problem solve, prioritize tasks, set goals, and daydream. Try to carry out this exercise at the same time and place each day, and avoid all other interactions during this period. Your most important task is to plan and prioritize what you will do with your day. If you are in a management role, you may actually spend most of your time planning and prioritizing the work of others.
Whether you are managing the corporate network, administering a mission-critical database, or designing and managing the enterprise information systems, there are issues that come up daily that can divert your attention from making progress on the work that really counts. By the end of the day, you can't really tell if you have actually gotten ahead or just fallen further behind.
Your goal should be to become more be preemptive, better organized, and better prepared to respond to IT emergencies. By planning, you can move from being reactive to proactive. In order to make that switch, though, you have to ponder, plan, and prioritize. It helps to maintain a task list—organized under three categories—and to start each day by reviewing this list: In Progress, ASAP, and Wish list. Using these lists, you can make time to create solutions that prevent crises from happening in the first place.
The In Progress list is the one that's critical to get right. It's vital that you make progress on these critical tasks each day. Deliver first on your company's and group's primary goals. Tasks that don't directly affect that priority can move lower down the list. If you are in a management position, put a process in place that helps all employees stay in sync with the top priorities.
The ASAP and Wish lists are usually for those strategic plans that will save your company time and money and thus make it more competitive. Identify these tasks and go after them slowly and methodically, moving them into your In Progress list as they become more of a priority.
Don't forget, though: just because you have these prioritized lists doesn't mean that anything will actually get done. Here are some tips to help you work through your tasks:
  • Get the fast and easy tasks out of the way first.
  • Next, do those things you are not as motivated to do.
  • Finally, get on to the exciting tasks.
  • Avoid context switching. Serialize your work if at all possible.
  • However, if you get blocked on one thing, go on to the next task until you can switch back.
  • Delegate or refuse tasks that don't make sense for you to do, or suggest alternatives.
  • Know when you work best and are most productive. Reserve this time to focus on important tasks.
Knowing how to plan your time wisely will help you do your best work. People who drift through life without a plan are never really happy with where they arrive because they never really knew where they were going in the first place.

Eric N. Bush is a Software Development Lead in the Engineering Excellence group at Microsoft. He works as an internal consultant and classroom instructor driving engineering and organizational improvements in the areas of people skills, process, and technology. Reach him at ericbush@microsoft.com.


 Windows Confidential: Remind Me Never to Do That Again
Windows Confidential
Remind Me Never to Do That Again
Raymond Chen

There's an old tool for the Windows® 95 series of operating systems that's known the as Automatic Skip Driver. Your first reaction to the tool may have been to its clumsy name, and you may even have suspected that the letters ASD started out meaning something else. And you'd have been exactly right.
Windows 95 had to deal with a lot of non-Plug and Play devices because the vast majority of systems out there at the time predated the Plug and Play specification. Hardware detection in the absence of proper Plug and Play devices was a very scary undertaking.
For example, modem detection was accomplished by issuing queries for the values of dozens of modem registers. Although there was a fairly well-established basic modem command set, there was significant variation in the implementation of the darker corners of the command language. Not surprisingly, this inconsistency was frustrating for communications programs, since it required adding special cases for various modem models to accommodate their individual quirks; however, the inconsistency was an accidental boon for Windows: since each modem behaved subtly differently, Windows could investigate those dark corners and compare the modem's behavior against a table of known modems and their responses.
There was one person on the Windows 95 team whose job was to install what felt like every modem known to mankind and run a little program that put the modem through its paces, explored the dark corners, and collected the results from each one so that an exhaustive modem database could be built up. If you still have access to a machine running Windows 95, you can take a peek into the Windows\Inf directory and look at all those files whose names begin with MDM. There's over a megabyte of device information files devoted to modems. That's a few years worth of somebody's life collapsed into a megabyte of unreadable hex numbers.
Detecting modems was pretty safe, since nearly all modems behaved roughly the same at a high level; all the excitement was in the details. Much scarier were the devices that used I/O ports. For example, to detect whether a specific video card was installed, the Windows 95 Configuration Manager's video card detection module would send carefully selected values out specific I/O ports and listen for any responses from the device. If the device responded in just the right way, then it assumed it found what it was looking for. If not, then it moved on to the next video card model.
Of course, if the device installed on that I/O port was not the video card that Configuration Manager was testing for, it might get very upset that somebody sent it values that made no sense. Depending on how petulant the device was, it might hang or reboot the machine. This did not bode well for the Configuration Manager. Thus was born the module known as ASD.
Before performing these potentially catastrophic hardware probes, the Configuration Manager created a file that said, basically, "Oh no! I'm about to do dangerous thing X!" This was the computer version of the classic "Open in the event of my death" envelope that the hero of an action movie leaves with his girlfriend before he goes off on a suicide mission to fight the bad guy.
If dangerous thing X did, in fact, cause the computer to hang or crash or reboot, then the next time the system started up, it saw this magic file and "opened the envelope" to see that it was dangerous thing X that caused the computer to crash. The system then concluded that the attempt to detect device X was catastrophic and knew not to do that ever again!
The module that did this work was named ASD. The letters ASD stood for "Attempting Something Dangerous."

Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He is careful because the plate is very hot.