August 2007
System Center: SMS Evolved: A Powerful New Solution to Manage Your Systems
Systems management is about to get a lot easier. Take a guided tour of System Center Configuration Manager 2007 and see how it can simplify key tasks, such as deploying software updates, managing mobile devices, and maintaining system configurations. John Orefice
System Center: Deploy Apps and Updates to Your Branch Offices
Branch distribution points, one of the new features in Configuration Manager 2007, might appear at first to be a fairly minor addition. But if you take a closer look, you’ll find that it offers new, indispensible capabilities for managing software distribution to branch offices. Steve Rachui
System Center: Getting Started with System Center Essentials 2007
Designed specifically for midsized businesses, System Center Essentials offers a unified solution for monitoring, managing, and troubleshooting systems. Here’s a detailed guide to installing and configuring Essentials 2007 for your network. David Mills
System Center: Keep an Eye on Your Servers with Operations Manager 2007
Operations Manager 2007, the newest incarnation of MOM, introduces some major improvements, including new management interfaces, better reporting, support for line-of-business applications, new security options, and more. Pete Zerger
System Center: Migrating from MOM to Operations Manager 2007
Ready to make the switch to Operations Manager 2007? Due to architectural changes, there’s no simple in-place upgrade path from a previous version of MOM. Instead, follow one of the migration plans presented here. Andy Dominey
System Center: Take Your Apps Virtual with Microsoft SoftGrid
Virtualized applications offer numerous benefits, from improved user experience to simplified system administration. Get a detailed overview of how Microsoft SoftGrid delivers virtual applications, how it can fit into your infrastructure, and how it can save your company time and money. Ahmer Sabri and Kedar Shah
Columns
From the Editor: Dynamic and Optimized: | Toolbox: New Products for IT Pros: | SQL Q&A: Finding Locks, Large Queries, I/O Statistics, and More:
Utility Spotlight: BGInfo: Wouldn’t it be great if you could see everything you need to know about a PC—its name, IP address, gateway, free disk space, and so on—in a single place. You can, with this free tool from Sysinternals.Lance Whitney | The Cable Guy: IPv6 Autoconfiguration in Windows Vista: There's more to IPv6 than just extending the address space from 32 bits to 128 bits. Here's a look at how IPv6 hosts can automatically configure themselves, even without the use of an address configuration protocol.Joseph Davies | Windows PowerShell: The Power of Filtering: The pipeline isn't just for cmdlets. Take a look at how you can use the Windows PowerShell pipeline to add handy filtering capabilities to your scripts.Don Jones
Hey, Scripting Guy!: Who Are You?: With Active Directory, users can have a variety of identities, such as givenName, displayName, userPrincipalName, or distinguishedName. As a system administrator, how do you get all this information about a user? With a script, of course.The Microsoft Scripting Guys | Security Watch: PKI Enhancements in Windows: In Windows Vista and Windows Server 2008, the Windows PKI platform offers support for advanced algorithms, real time validity checking, and better manageability. Check out the new PKI features and see how they can be used to lower costs while improving security.John Morello | The Desktop Files: Getting to Know RDP: The Remote Desktop Protocol, which allows you to access machines remotely, is a useful piece of technology that gets better with every version of Windows. Get an overview of Remote Desktop, looking at many of the benefits and limitations it has to offer.Wes Miller
Field Notes: IM Interviews: You have one position to fill and a large stack of resumes from around the globe. How do you quickly narrow your search? The answer may be to do interviews over IM. Here's one developer's success story.Nathan G. Jensen | Windows Confidential: Windows Explorer Doesn't Do Text: Why can't you copy a list of files in Windows Explorer and then paste them as text to get their file names? The Windows team tried to include this functionality, but it didn't work as planned.Raymond Chen


System Center
SMS Evolved: A Powerful New Solution to Manage Your Systems
John Orefice
At a Glance:
  • Operating system deployment
  • Software update management
  • Desired configuration management

Systems Management Server (SMS) 2003 has become an important configuration management and software delivery tool for administrators around the world. Now Microsoft is preparing
to introduce a new version of its enterprise management solution, and the new version brings both new capabilities and a new name: System Center Configuration Manager 2007.
System Center is a family of Microsoft products 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.
Configuration Manager 2007 is just one part of the System Center family. System Center Data Protection Manager provides enterprise system backup and recovery. 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. And the list continues to grow (have a look at www.microsoft.com/systemcenter for more information).
In this article I will walk you through several of the new and enhanced features planned for Configuration Manager 2007, based on the most recent beta release. I'll give you a broad look at what you can expect in this exciting release and I hope to get you thinking about how Configuration Manager will be able to save your organization time and money.

New Administrative User Interface
Since SMS 1.0, one of the most frequently requested new features in SMS has been a new and improved UI. Microsoft is answering that request by making several improvements to the System Center Configuration Manager 2007 administrative UI. To enable these new features, the new console in Configuration Manager 2007 is built with C# and the Microsoft .NET Framework, and it runs on top of Microsoft Management Console (MMC) 3.0 technology. In addition, like SMS 2003, the UI is extensible via an SDK so that users of the console can create their own add-ons to meet their individual needs.
Figure 1 shows the new console with the Computer Management node expanded, depicting all of the new management functions available. In addition, take note of the new appearance of the SMS Site Configuration section, which outlines common tasks that need to be completed before Configuration Manager will be operational after installation. The Links and Resources section contains relevant tasks that reduce the time it takes to navigate throughout the console for common functions.
Figure 1 Configuration Manager administration interface
Figure 1 Configuration Manager administration interface
Some of the benefits and features enabled by this new console are multiple item selection and drag and drop (great for collection management), search folders for organizing items in the console virtually rather than physically, the Actions pane for performing tasks appropriate to the current section, the Preview pane for viewing summary information on a specific item (for example, an operating system image), homepages for summarizing information on a particular topic such as software deployment, and an improved organizational structure to greatly simplify navigation.
As noted, the Actions pane is one of the major enhancements inside the newly revamped console. It provides a way to see the actions that are contextually appropriate for the section of the console you are currently using. For example, if you are viewing the All Systems collection, the Actions pane will have actions such as Update Collection Membership and Install Agent (see Figure 2).
Figure 2 Available actions are specific to the current view
Figure 2 Available actions are specific to the current view
In addition, Configuration Manager 2007 introduces a new concept called homepages, which give you the ability to very quickly review the status of a specific function such as Software Updates, Software Distribution, or Desired Configuration Management. You can do this within the console without running reports or looking elsewhere for the data. Look for more examples of homepages throughout this article as I outline the different features of the product.

Server Roles and Distribution Points
Configuration Manager 2007 introduces several new server roles to enable some of the new features I'll discuss here. These include the Fallback Status Point (FSP), the PXE Service Point (PSP), the Branch Office Distribution Point (DP), the State Migration Point (SMP), the Software Update Point (SUP), and the System Health Validator (SHV). As with all SMS and Configuration Manager server roles, these roles can be hosted on the same server as long as appropriate capacity planning exercises are performed.
The Branch Office DP is important and differs from the traditional DP for two reasons. First, it doesn't have to be installed on a server operating system—it can be installed on Windows Vista® or Windows® XP. It is the only Configuration Manager role that can be installed on a client operating system. This is great for a branch office without a local server or in cases where an IT department wants to remove servers from smaller branch offices to save money and reduce administrative overhead. In these cases where there are only machines running Windows XP or Windows Vista, the Branch Office DP can be used to reduce WAN traffic by ensuring that clients are not pulling packages from across the WAN when they are made available locally.
The second way that the Branch Office DP differs from a standard DP is through its connectivity to other DPs. Traditional distribution points replication data is not throttled or scheduled unless it's going from a primary site to a secondary site. Because of this, many organizations only replicate packages to branch offices at night, thereby delaying software distribution until those packages are available locally.
The Branch Office DP uses Background Intelligent Transfer Services (BITS) to download the information from other DPs. This is exceptional for throttling bandwidth over a WAN link between a branch office and a DP sitting in the central datacenter, especially when there is no Configuration Manager secondary site located at the branch office. Figure 3 shows the new DP Properties dialog box used to make a standard DP into a Branch Office DP.
Figure 3 Configuring a Branch Office DP
Figure 3 Configuring a Branch Office DP
SMS 2003 introduced a replication technology that allowed for file delta replication of packages from a site server to a distribution point. This technology worked well for SMS packages that were composed of several smaller files. If, for example, an SMS administrator needed to make a change to just one file, or to several smaller files in a larger SMS package, only those changed files in the package were replicated rather than the whole package.
As operating system deployment becomes more mainstream in Configuration Manager 2007, you'll want to make sure that replicating operating system image packages and other larger packages throughout your infrastructure and over WAN links happens as efficiently as possible. With that goal in mind, Configuration Manager 2007 introduces binary delta replication from site server to site server, from site servers to DPs, and from DPs to Branch Office DPs.
For example, start with a new Windows Vista deployment image that has several applications preinstalled. This package may be 6GB in size and, because it's a Windows Imaging Format (WIM) image, it is also a single 6GB file. As described previously, in SMS 2003, if the new WIM image was opened up to change a setting or add a new 2MB patch that was released, because the image is one single WIM file, the entire 6GB SMS package would have to be replicated to the DPs. In contrast to this, with binary delta replication in Configuration Manager 2007, if a setting is changed or a single patch is added to the WIM image package, just that single 2MB patch or setting will be replicated throughout the infrastructure rather than the entire 6GB.

Common Processes for Mobile Devices
Shortly after the release of SMS 2003, Microsoft released the Device Management Feature Pack (DMFP) for managing Windows CE and Pocket PC mobile devices. As mobile devices become more pervasive within enterprise organizations, the need to manage them becomes a higher priority. Given this trend, Configuration Manager 2007 improves upon the SMS 2003 DMFP and delivers a great new integrated solution for managing mobile devices including Windows Mobile® smartphones and Pocket PC phones, much as you would manage servers, laptops, and desktop computers.
Basic management of mobile devices includes hardware and software inventory, file collection capabilities, software distribution, and settings for password and security policy management. Using Configuration Manager 2007 Internet-Based Client Management, all devices can now be managed on your intranet as well as over the Internet. This is great for smartphones or other devices that are very rarely, if ever, on the corporate LAN.
The process for deployment of the agent has been enhanced as well. Over-the-air client upgrades are now supported and client distribution can be automated via the Configuration Manager console.

Maintenance Windows
Many of the enterprise customers I work with have predefined maintenance windows for both servers and certain mission-critical desktops. In addition, they regularly ask for advice on how to deploy larger applications such as the 2007 Microsoft Office system, without interrupting the end user during typical business hours.
Configuration Manager 2007 introduces a new feature called maintenance windows. This allows you to define windows of time during which installations can occur for a particular collection. This gives you the freedom to make an advertisement mandatory without worrying about the repercussions of the package being installed during normal business hours or during times that are inconvenient for the users.
As an example, consider a 2007 Office system package deployment. You want to be able to push this application out to your end users as quickly as possible, but you do not want the application push to interfere with work during the day. You can set the maintenance window to state the timeframe during which you want the system to perform the installation—perhaps 8:00 P.M. to 6:00 A.M. If, for whatever reason, the system is not available during this maintenance window on a particular day, Configuration Manager will wait until the next time defined inside of the maintenance window to ensure that business is not interrupted unexpectedly. You also have the option to ignore maintenance windows at an advertisement level, allowing you to deploy a critical update as soon as possible despite any restrictions that may be in place.

Operating System Deployment
Operating system deployment functionality is the single largest focus area for Configuration Manager 2007. Microsoft has designed Configuration Manager to be the primary means to deploy operating systems for both server and workstation platforms. The best features from the SMS 2003 Operating System Deployment (OSD) Feature Pack were integrated into Configuration Manager 2007 to fundamentally change the way that OS deployments are managed.
As you may know, Windows Vista introduced a new Windows Imaging (WIM) format for operating system deployment. There are several benefits to using this format, starting with the fact that Configuration Manager 2007 imports the WIM image format natively so that administrators can work on the images and deploy them directly from the console.
Another important new deployment feature in Configuration Manager is the integrated Task Sequencer. If you're familiar with the Microsoft Solution Accelerator for Business Desktop Deployment (BDD), you'll find many similarities with the features and options available to you in Configuration Manager, but with one major difference: no longer will you need to write scripts for deploying or capturing operating system images. And by taking advantage of the Task Sequencer, the operating system deployment process becomes completely hands-off.
The Task Sequencer can help lay out all of the steps that you need to execute throughout your OS deployment, including steps executed in the older OS prior to deployment (user state migration and application settings transfer), steps to deploy the new operating system (formatting, disk partitioning, product key, user name, company, licensing settings, drivers installation), and steps required after the new system is deployed (additional application installation, update installation, user state migration). As an example of this functionality, Figure 4 shows the Task Sequence Editor highlighting some of the features you can take advantage of in a Windows Vista deployment.
Figure 4 Editing steps for an operating system deployment
Figure 4 Editing steps for an operating system deployment
In addition to the Task Sequencer, there are several other enhancements to operating system deployment in Configuration Manager 2007, as outlined in Figure 5. For example, Configuration Manager supports bare-metal deployment with Pre-Boot Execution Environment (PXE) for x86 and x64 platforms with device driver management. The device driver management option allows your organization to significantly reduce the number of images that need to be maintained for different kinds of hardware. Combined with the single-image support introduced with the Windows Vista WIM image format, you are almost guaranteed to save time and money when you are doing operating system deployments.
Figure 5 Operating system deployment features

Scenario | SMS 2003 | Configuration Manager 2007
End-to-end deployment | Yes | Yes
Fully automated | Yes | Yes
Wipe-and-load upgrade | Yes | Yes
Bare-metal deployment with PXE | Loose integration with Remote Installation Services (RIS) | Built-in integration with Windows Deployment Services (WDS)
Side-by-side | BDD scripts | Yes, via built-in State Migration Point
Full offline deployment | No | Yes
Windows Vista upgrade planning | No | Yes
Full server deployment | No | Yes
Device driver management | No | Yes

Software Update Management
Like many other features in Configuration Manager 2007, software update management has been dramatically revamped. Configuration Manager separates the way that updates and regular packages are pushed to a managed agent by creating a new state-based high-priority channel for all software updates and desired configuration management information. No longer will pushing another software package interfere with pushing software updates or receiving patch status from managed workstations, laptops, or servers.
The state-based method for software update management also means that patch and update status is no longer tied to hardware inventory scans and, as a result, the current Inventory Tool for Microsoft Updates (ITMU) and scan catalog will no longer be needed. Instead, Configuration Manager uses the new Software Update Point (SUP) server role running Windows Server Update Services (WSUS) on the back end as its software update engine and database.
WSUS enables you to have one central location for all update management in Configuration Manager. This gives you the ability to download all content available on Microsoft Update including non-critical updates, drivers, and other software packages for the Microsoft platform. In addition, Microsoft is also encouraging its partners to release software updates via this method. Adobe and Citrix are just two of the companies that are currently publishing manifests for the Inventory Tool for Custom Updates (ITCU) in SMS 2003 R2 and plan to do so for Configuration Manager moving forward.
This new software update engine also provides near real-time update status to enable better reporting and enhanced homepage views. These customized views can show you quick graphical charts of patch status throughout an IT infrastructure or for a specific collection of computers. Figure 6 shows how easy it is to view patch compliance data for a specific bulletin via one of the new homepage views customized for software update management.
Figure 6 Viewing software update status
Figure 6 Viewing software update status
Finally, software update deployment templates dramatically reduce the number of steps required to push new updates to a system or collection. By using software update deployment templates to store common configuration information such as whether to force a restart or whether the client should download patches from the DP locally before executing the installation, this feature reduces the number of steps from the 18 required with the ITMU in SMS 2003 down to just 6 in Configuration Manager 2007.

Desired Configuration Management
Configuration management is another terrific feature that has been greatly improved in Configuration Manager 2007. SMS 2003 Desired Configuration Monitoring was released in the fall of 2006 and provided many of the key features that are included in Configuration Manager 2007 Desired Configuration Management. For background on Desired Configuring Monitoring, see the TechNet Magazine article at microsoft.com/technet/technetmag/issues/ 2006/09/HighStandards. Figure 7 depicts the Desired Configuration Management homepage showing compliance for two specific configuration baselines.
Figure 7 Reporting desired configuration baseline compliance
Figure 7 Reporting desired configuration baseline compliance
The key driver for Desired Configuration Management in Configuration Manager comes from a significant amount of research with Microsoft customers showing that most service outages are caused by operating system or application misconfiguration on mission-critical servers and desktops. By using the Desired Configuration Management functionality in Configuration Manager, administrators can quickly catch configuration drift by running periodic baseline scans on systems. These baselines are created using configuration items (CIs) and provide compliance information for a collection of computers in your organization.
In addition to catching configuration drift, Desired Configuration Management can help with both regulatory compliance reporting as well as change verification. In most organizations, chances are good that you have a need for regulatory compliance reporting such as Sarbanes-Oxley (SOX), the Payment Card Industry Data Security Standard (PCI DSS), and the Health Insurance Portability and Accountability Act (HIPAA). Configuration Manager 2007 can help provide you with the reports you need though Desired Configuration Management.
Here's how Desired Configuration Management works. An administrator will define CIs—units of configuration that can be detected, applied, and removed from computers. Once these CIs are defined, you can create a configuration baseline that is made up of one or more of these CIs. These baselines are then assigned to Configuration Manager collections for compliance monitoring and regulatory reporting.
The CIs can look at several different aspects of a computer to gather information, including Active Directory®, file metadata, script results, data stored in SQL Server™, software update data, WMI, XML, registry values, IIS metadata, and Microsoft Installer presence and configuration. The information gathered from these different locations is stored in the Configuration Manager database and used to verify whether a system is in compliance.
As an interesting note, the Desired Configuration Management process and the process for pushing new updates through Configuration Manager 2007 are now fully integrated. As with the new software update engine, all Desired Configuration Management data is using the state-based high-priority channel. The integration of these two mission-critical features allows an administrator to define a new Desired Configuration Management baseline or update an existing one with new updates as part of the update deployment process.

Internet-Based Client Management
Have you ever had a computer disconnected from the network for so long that the computer object inside SMS became obsolete? Based on conversations with my customers, this seems to happen far too often. Fortunately, Configuration Manager 2007 introduces new Internet-based client management. This feature works much like the way Microsoft Office Outlook® communicates with Exchange Server over HTTPS without a virtual private network (VPN). If you're not familiar with that scenario, it simply means you get a more secure communication with client machines without requiring the complication of a VPN connection.
Internet-based client management enables you to manage computers on the Internet with the same level of control as computers on the intranet. In fact, all features discussed in this article will work with Internet-based client management except for operating system deployment, wake-on-LAN, and remote tools since they use different ports for communication and cannot be tunneled over SSL or TLS. Some great examples of situations where Internet-based client management comes into play are point-of-sales devices for restaurants, retail stores, and gas stations; employees' home computers; and road warriors such as a distributed sales force or team of consultants.
There are some requirements you'll need to put in place before enabling Internet-based client management in your Configuration Manager 2007 infrastructure. First, you'll need a Public Key Infrastructure (PKI) to assign digital certificates to all agents managed by Configuration Manager. This enables you to use mutual authentication between the Configuration Manager servers and all management agents to ensure the data you are receiving is encrypted and from a trusted source. You will also need an SSL terminator to work as the connection point between the Configuration Manager servers and all Internet-based clients. Microsoft Internet Security and Acceleration (ISA) Server 2006 is a software-based solution that meets these requirements.
Internet-based client management is where the new Fallback Status Point (FSP) server role is used. Should any of your Internet-based agents fail to communicate correctly or if a certificate should expire, the agent will report the problem to the fallback status point available in your organization's perimeter network. This ensures you will never lose contact with your Internet-managed systems. In addition, the clients can roam in and out of the Internet-based management to intranet-based management automatically to best utilize the appropriate resources at the appropriate times.

Other New Features
Although not seen as a mission-critical feature, wake-on-LAN is an extremely valuable one to have in an administrator's arsenal of tools to get a software distribution, software update, or OS deployment accomplished quickly and quietly. Configuration Manager 2007 enables wake-on-LAN functionality for all intranet-based managed agents that have a compatible network card. Figure 8 shows an example of how you can use wake-on-LAN for an advertisement in the newly designed New Advertisement Wizard. In this case, I am deploying a new package to a group of computers. If a wake-on-LAN-compatible device is turned off, with this setting enabled in the wizard Configuration Manager will start the system to deploy the package which was defined by the advertisement.
Figure 8 Wake-on-LAN in a software distribution advertisement
Figure 8 Wake-on-LAN in a software distribution advertisement
Remote Control was completely rewritten in Configuration Manager to deliver a more secure and reliable solution with significantly faster performance. Rather than the old tools that have been in place since SMS 1.0, Configuration Manager now uses the Windows Vista native collaboration technology built on the Remote Desktop Protocol (RDP). The basic functionality is the same as with SMS 2003 in that there is no need for end user acceptance of new sessions. However, three new levels of access are being introduced: full control, view only, and none. In addition to this new technology, Configuration Manager 2007 is still integrated with Remote Assistance for times when that functionality is needed.

Wrap-Up
I've walked you through several of the new features and enhancements in System Center Configuration Manager 2007. These features were designed to help ease administrative effort, enable new workloads, and lower costs within your IT environment. With Configuration Manager 2007, as well as the other products in the System Center family, you will be equipped to handle the most demanding IT infrastructures while giving your business a competitive edge.
In addition to the features outlined in this article, there are many more enhancements in the product, such as Windows Server® 2008 Network Access Protection (NAP) integration and enhanced software asset management (SAM) capabilities based on the same Asset Intelligence technology included in SMS 2003 SP3. I encourage you to download the Configuration Manager 2007 release candidate or RTM trial version to see these features at work in your infrastructure.
For more information and an overview of all of the products in the System Center family please visit microsoft.com/systemcenter. From here you can navigate to any solution in the System Center family, including Configuration Manager.

John Orefice is a Technology Solution Professional in the Microsoft mid-Atlantic states district. He has worked with Microsoft management solutions for several years first as a consultant with Microsoft Consulting Services (MCS) and now in his current role. He can be reached at john.orefice@microsoft.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


System Center
Deploy Apps and Updates to Your Branch Offices
Steve Rachui
At a Glance:
  • Configuring a branch distribution point
  • All about boundaries
  • Three approaches to provisioning data

Microsoft is set to release its next-generation solution for systems management. Formerly known as Systems Management Server (SMS), the new System Center Configuration Manager 2007
has a good number of new features that are sure to impress. One of these handy features is the branch distribution point (BDP), a new type of distribution point that is specifically designed to meet the needs of small or distributed office settings. At first glance, and compared to other new features, the BDP may appear to be just a minor addition, but don't overlook this feature too quickly.
With previous versions of SMS, server systems were the only supported platforms for hosting distribution points. As a result of this, administrators who needed to provide service to branch offices, which often lack local servers and communicate via slower WAN links, struggled to design and put together an infrastructure that would allow timely and efficient software distribution. This scenario is exactly the need the BDP is designed to address.
The BDP, which is designed to operate on both workstation and server-class systems, is a component made available, though not enabled by default, on every Configuration Manager 2007 client. While every Configuration Manager 2007 client has the code necessary to operate as a BDP, not every client should be configured as such.

Setting Up a BDP
Activating the BDP function on a client is basically the same as configuring any server-based distribution point. You start by configuring a client as a new site system (as shown in Figure 1) and then indicate that it is a branch distribution point (as in Figure 2). This configuration causes the BDP to be listed as an available distribution point for packages, software updates, Operating System Deployment (OSD) images, and so on. Policy will be prepared by the site server and targeted to the selected client that will turn on the BDP function. Once this policy is downloaded, the client will begin acting as a BDP.
Figure 1 Configure client as a new site system
Figure 1 Configure client as a new site system
Figure 2 Configure site system as a branch distribution point
Figure 2 Configure site system as a branch distribution point
A BDP, or any site system, can be configured to service a particular boundary (formerly called site boundaries in SMS 2003) or a group of boundaries, or it can be configured to operate without being boundary-specific. Boundaries in Configuration Manager 2007 are generally defined by IP subnet or Active Directory® site.
To configure a BDP to service a particular set of boundaries, select the "Enable this site system as a protected site system" option on the site system configuration window and then specify the boundaries that should be served, as shown in Figure 1. Note that this is a required step if you are planning to use the BDP for on-demand content provisioning (which I'll describe in a moment). If this step is omitted, the BDP will essentially function as any standard distribution point.

About Boundaries
Protected boundaries on a BDP only serve to define which clients are able to access content on the BDP; they do not play a role in determining which standard distribution point a BDP can access to download the content it needs. Suppose, for example, there is an environment with a BDP installed on Boundary A. Now suppose that Boundary B contains the only standard distribution point using the Background Intelligent Transfer Service (BITS), and this distribution point is configured to serve only clients in Boundary B. When the BDP attempts to download content, will it succeed? According to the expected rules of protected boundaries, you might think that it would fail. However, in this scenario, the download would succeed, for BDP downloads do not honor any protected boundaries that have been configured on standard distribution points.
BDPs also provide a great deal of flexibility. It is possible to enable a single BDP per branch office location or, if necessary, enable multiple BDPs within a single branch office (boundary). When multiple BDPs are configured to service the same boundaries, they work together somewhat like load balancing to provide content to the clients within those boundaries.

Provisioning Data
Once enabled, a BDP can obtain the content it needs in three different ways: administrator provisioned, on-demand provisioned, and manually provisioned. Regardless of which method you use to obtain content, at least one standard distribution point that is BITS-enabled must be available and provisioned with the content that the BDP will receive. Let's take a look at the three methods that can be used to obtain content.
Administrator Provisioned This is the familiar method of staging content on a distribution point. Using this approach requires an administrator to manually select the BDP as a distribution point. Doing so will cause a policy to be prepared alerting the BDP to download the content being provisioned from a standard BITS-enabled distribution point within the same site during the next policy update cycle.
On-Demand Provisioned This is a new method of staging content and is specific to the BDP. This approach allows content to be downloaded on demand to the BDP when requested by a client. The administrator does not take action to provision the content onto the BDP—meaning the BDP is not selected as a distribution point within the packages node. On-demand provisioning will effectively cause the BDP to be selected as a distribution point when the request for content is made. This happens behind the scenes and is automatic.
On-demand provisioning can only take place if the package is configured to support this option (see Figure 3) and the BDP is protected to ensure that the clients requesting the content are only able to access the BDP and cannot access any standard distribution points that have the content. Note that if multiple BDPs are configured within the same protected boundaries, an on-demand provisioning request to one will result in content being provisioned to all.
Figure 3 Enabling on-demand distribution of a package
Figure 3 Enabling on-demand distribution of a package
Manually Provisioned As its name implies, this method of staging content requires manual action from the administrator. The package must be configured to indicate that the content will be transferred manually, as shown in Figure 3. The content must then be manually copied to the BDP into the packages folder using a directory structure that would be expected for a typical package.
The BDP will recognize the new package and make it available to requesting clients. Because this method allows content to be transferred to the BDP using removable media, this method is ideal for environments with limited bandwidth between the standard distribution point and the BDP.
You can configure a BDP to store downloaded content on a particular partition; if no partition is specified, the BDP will automatically choose a partition to use. When content is configured to be staged on a BDP or when an on-demand request is processed, the target content is not immediately available on the BDP. Rather, policy is prepared to alert the BDP that content is available for download. At the next policy cycle, the BDP will receive the policy and initiate a BITS download of the content. You can use Group Policy to control with great precision the bandwidth that is used and the schedule for BITS downloads. Note that the distribution point share on the BDP looks just like the share on a standard distribution point—which means the content is not encrypted.

The Right Setup for Your Organization
As mentioned, the BDP role was created for the branch office and is fully functional on workstation systems. However, it's also possible to operate a BDP on a server-class system. The underlying OS will have an impact on the number of connections that can be made to the BDP. Workstations have a limit of 10 simultaneous connections, while servers are not bound by this limit. Thus, depending on the number of simultaneous connections you need to support, you may want to use a server system—or perhaps multiple workstation systems within the branch office. Regardless of the platform you use, there still must be at least one BITS-enabled standard distribution point with the content being requested.
However your infrastructure is configured, the BDP will give you much more control over the flow of software distribution throughout any organization. Built-in support for BITS, which allows for throttling and scheduling of downloads, offers a key advantage for administrators that require more granular control and predictability.

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


System Center
Getting Started with System Center Essentials 2007
David Mills
At a Glance:
  • Installing and upgrading
  • Configuring Essentials 2007
  • Troubleshooting steps

System Center Essentials 2007 is a new IT management solution specifically designed for midsize businesses with 50 to 500 PCs and 5 to 30 servers. Essentials 2007 came about in response to extensive feedback from IT professionals regarding their specific needs for a unified
management solution. Essentials 2007 addresses those needs and enables you to get up and running quickly with a single install and easy configuration.
More specifically, Essentials 2007 delivers monitoring, troubleshooting, and asset tracking functionality to help keep your IT environment secure and up-to-date. Essentials 2007 also provides a unified management console, where you manage your servers, clients, hardware, software, and IT services (see Figure 1). In addition, Essentials can make complex management tasks like troubleshooting end-user issues, monitoring, and server and client software deployment simpler and more efficient.
Figure 1 The Essentials 2007 management console
Figure 1 The Essentials 2007 management console

Essentials 2007 Requirements
Before you start your Essentials 2007 installation and configuration, check to see that your systems meet the minimum software and hardware requirements. Your server operating system should be Windows Server® 2003 SP1 or R2 or Windows® Small Business Server 2003 SP1 or later. You will also need Active Directory®, IIS 6.0, the Microsoft® .NET Framework 2.0 and 3.0 or later, and SQL Server™ 2005 SP1. The server itself requires at least 1GB RAM, 12GB of free disk space, and a 1.8 GHz processor. A computer with 2GB RAM, 20GB of free disk space, and a 2.8 GHz or faster processor is recommended.
Managed client computers need to be running Windows 2000 Professional SP4, Windows XP SP2, or Windows Vista®. Both x86 and x64 operating systems are supported.
Managed server computers need to be running a Windows 2000 Professional SP4 or newer operating system. Both x86 and x64 operating systems are supported. Since many of you will probably want to monitor and manage your IT environment from your own desktop or laptop computer, you'll want to run the Essentials 2007 console-only installation on your machine. Before starting, just make sure it's running Windows XP SP2, Windows Vista, or Windows Server 2003 SP1.
Also, when you're planning your Essentials 2007 server configuration, allow enough disk space for handling update downloads and your reporting database. For updates, your update database can grow beyond 2GB and your update content can grow beyond 6GB. The Essentials operational and reporting databases can grow to 4GB. Plan accordingly so you don't run out of storage space.

Installing Essentials 2007
Setting up Essentials 2007 is straightforward because of its effective use of wizards that quickly guide you through critical tasks like installation and configuration, computer discovery, and update configuration. When you run the setup wizard, Essentials 2007 automatically checks for these prerequisites and lets you know if you're missing anything (see Figure 2).
Figure 2 Checking setup prerequisites
Figure 2 Checking setup prerequisites
If a required item isn't on the Essentials 2007 disk, there's a link from the setup screen to the missing software for you to install. As you move through the setup wizard, you'll need to enter a path for the installation location of Essentials 2007 and information for an account with administrative privileges. Managing computers using Essentials 2007 can be a much simpler task if this account has administrator rights on the management server and all the managed computers. Essentials supports using a single account to perform tasks such as installing agents on managed computers.
If you don't currently have SQL Server 2005 installed and available to use with Essentials 2007, either locally or remotely, you can choose to have Essentials 2007 install SQL Server 2005 Express with Advanced Services locally during setup. This version of SQL Server is included on the Essentials 2007 disk. You can also purchase a version of Essentials 2007 with SQL Server 2005 Standard that's licensed specifically for use with Essentials 2007.
The only other major decision you need to make during installation is where you want Essentials 2007 to store your updates. You can store updates locally and they'll be delivered to the managed computers over the network from your Essentials 2007 server. This is probably the best choice, especially if Internet access tends to be a bottleneck for your network. Updates can also be downloaded directly from Microsoft Update each time a computer needs to be updated. Selecting this option means one update for 50 computers is downloaded 50 times, once to each computer. This can be cumbersome, but the advantage is that you use less disk space on your management server.
The baseline deployment topology supported by Essentials 2007 is to install all management components on a single server (see Figure 3). However, you can also choose to install the Essentials 2007 management console on the desktop or laptop computer in your office and remotely control the management server. Before you install the remote console, you must run the Feature Configuration Wizard on the Essentials 2007 server. This process establishes whether domain Group Policy or local Group Policy is used to configure the remote console. If you select domain Group Policy, make sure that enough time has passed for it to update on the computer on which you are installing the remote console. You can install multiple remote consoles if necessary.
Figure 3 Baseline Essentials 2007 configuration
Figure 3 Baseline Essentials 2007 configuration
If you manage an IT environment with more than 200 computers, you'll need to install SQL Server 2005 on a remote server (not on the Essentials 2007 management server) and use this remote instance as your Essentials 2007 database (see Figure 4). This will give you increased performance as you scale up. Just remember that this remote server must be in the same domain as the Essentials 2007 management server.
Figure 4 Using a remote SQL Server database
Figure 4 Using a remote SQL Server database
If you choose to use an existing SQL database instance during Essentials 2007 installation, you must make sure that SQL Server 2005 SP1 Reporting Services is installed and configured on the Essentials 2007 management server.

Upgrading to Essentials 2007
It's likely that you are already running Windows Server Update Services (WSUS) 2.0 or 3.0 to handle your Microsoft updates. If so, and you want to upgrade to Essentials 2007 for a more comprehensive management solution, Essentials allows you to upgrade during the setup process. This in-place upgrade preserves existing update information including binaries, groups, and approvals.
If you are using Microsoft Operations Manager (MOM) 2005 or MOM 2005 Workgroup Edition to monitor critical servers, but you want the added Essentials 2007 features for asset inventory, software distribution, and updating, you can easily migrate your management packs by exporting, converting, then importing them directly into Essentials 2007. Just like MOM 2005, Essentials 2007 makes use of management packs for monitoring computers and devices. The management packs also contain the information you need to successfully diagnose and resolve IT problems. If you don't want to completely migrate to Essentials 2007, you can maintain side-by-side operation to preserve mission-critical monitoring and migrate at your convenience.
Be forewarned that some WSUS settings are not preserved during the upgrade to Essentials 2007. You will lose information about computers, automatic approvals and settings, and any existing approvals for groups named All Clients or All Servers. So, delete All Clients and All Servers groups from WSUS before upgrading. Next, you'll have to re-create these approvals after Essentials 2007 setup completes.
Please note that you can't perform this upgrade from WSUS if the existing server has active downstream servers. Essentials 2007 does not support WSUS Upstream Server (USS) mode. Because this cannot be reliably detected, you will be warned if the WSUS server has downstream servers. Also, do not proceed with an upgrade if you are using WSUS 2.0 or 2.0 SP1 with a remote database server that is not running SQL Server 2005 SP1 to store WSUS data.
A backup copy of the current database is created automatically during the upgrade process. If the upgrade is not successful, you can restore the previous environment using the backup copy. Make sure you have sufficient space to back up the current WSUS database by checking the current database file size and confirming that enough space exists to make a copy.

Configuring Essentials 2007
Essentials 2007 provides many wizards that help you with configuration and management tasks. The Feature Configuration Wizard takes you for a quick walk through some configuration steps that would be difficult if you had to perform them manually, such as configuring Group Policy. Figure 5 shows the first page of the wizard.
Figure 5 Starting the Feature Configuration Wizard
Figure 5 Starting the Feature Configuration Wizard
If you want to use a proxy server when connecting to the Internet, one of the first steps is to enter the server name and port number. Next, you can choose a Group Policy type to configure managed computers—either local or domain Group Policy. You can also create a Windows Firewall Exception if you've chosen to use domain Group Policy to configure managed computers.
Next up is the optional step of enabling remote assistance of computers. This applies if you chose to use domain Group Policy to configure clients. Note that this creates a firewall exception on all managed computers to allow DCOM over TCP port 135.
You can choose whether to collect Agentless Error Monitoring from managed computers. If you select Yes and pick a location for storing the errors, then managed computers will send error reports to the Essentials 2007 server and you can view reports to see which applications are having problems.
There are options specifying whether to forward your error report to Microsoft, and whether to configure and send a Daily Health Report, which contains information about alerts, updates, software, and inventory. If you configure the Daily Health Report to be sent to you via e-mail, you can quickly determine what is going on in your IT environment when your workday begins.
Finally, you can choose to set daily scheduled discovery of new computers. I would recommend selecting this option as it tells Essentials 2007 to run a daily scan of Active Directory for new computers and configure them to be managed automatically.
Running the Computer and Device Management Wizard configured for automatic computer discovery prompts the Essentials 2007 server to query Active Directory and discover all listed computers in the domain to be managed (see Figure 6). If you select the Advanced discovery option, you can filter discovered devices by types such as clients only or network devices, search within an IP address range, or create advanced queries. I would recommend selecting Automatic computer discovery and running that first to discover all clients and all servers. Since Essentials 2007 also monitors Simple Network Management Protocol (SNMP)-enabled network devices, you can then run the wizard again in the advanced mode and discover network devices.
Figure 6 Starting the Computer and Device Management Wizard
Figure 6 Starting the Computer and Device Management Wizard
If your network is larger than approximately 300 computers, you should probably choose Advanced discovery and provide more specific criteria to locate your computers. When specifying an Administrator account, ensure the account has administrative privileges on the computers you want to discover and on which you want to install agents. Once discovery is complete, choose the computers you want to manage and click Finish.
If you've used WSUS, some of the settings in the Update Management Configuration Wizard will be familiar to you. If a proxy server is required when connecting your server to the Internet, enter the Proxy server settings. Select the products for which you want to download and deploy updates, then select the languages you need for updates (the language of the server is the default). Select the categories of updates you want to download and deploy (Critical Updates, Security Updates, and Service Packs is the default). Select which, if any, categories of updates you want to automatically approve and to which groups. (Critical and Security Updates for All Computers group is the default). Finally, set the schedule for synchronizing updates (daily is the default).
If you can log on with Domain Administrator or Group Policy Administrator credentials when configuring Essentials 2007, you should select domain Group Policy to configure managed computers; this makes configuration much easier. If you select domain Group Policy, you can automate configuration of Windows Firewall and Remote Assistance settings on all managed computers. This option directs Essentials 2007 to create the policy configurations for you. If you select local policy, you'll have to perform quite a bit of manual configuration.

Troubleshooting Essentials
There are several things to consider when troubleshooting problems with computer discovery, agent deployment, and communication. First, here's a quick look at how the computer discovery process works. Essentials 2007 takes your search input parameters and creates a Lightweight Directory Access Protocol (LDAP) query, (LDAP is the query language used to search for objects in Active Directory). The LDAP query is then passed to the local domain controller and submits a search task, and Active Directory returns the results to the management server. The management server then tries to connect to each computer returned in the list to ensure it can communicate with these discovered computers so management agents can be installed. Once a computer is verified, it is added to the list of discovered computers for you to manage.
Be aware, however, that the Essentials 2007 server may not be able to discover computers if there are issues with Active Directory, the network and DNS, or verification.
Open the Active Directory Users and Computers management console to see if the computer is listed. This tool is installed by default on Windows Server 2003 and can be installed on Windows XP Professional from the Windows Server 2003 Administration Pack. Select the Saved Queries folder, right-click on it, point at New, then click Query. Enter a name for the query, then click the Define Query button. Click the dropdown list marked Find and select Computers. Enter the name or search prefix and click OK a few times to generate the query.
Now verify that the computer appears in the list of results. If not, add the computer to Active Directory. Make sure the DNSHostname property is set correctly for the computer; this property can be found on the General tab of the computer's property dialog in the Active Directory Users and Computers management console.
If you need to contact a computer through the network, use the ping command to try reaching the computer using the same name provided to the discovery wizard. If the machine responds to a ping command, run ping with the -a switch and the IP address:
ping -a <IP address>
The following command will display the DNS of the machine; it should match what was used in the original ping command. Use this command to see the registered NetBIOS name and domain for the computer:
nbtstat -a <computer name>
This will accomplish the same task with the IP address of the machine.
nbtstat -A <IP address>
The command switch, –a, is case-sensitive. Note that you use –A when using the IP address. If the machine does not respond to a ping request or fails a remote agent install with the message "RPC Service Unavailable," then Windows Firewall is turned on. In the event that a firewall is enabled in the Essentials 2007 deployment environment, exceptions must be created so that the Essentials 2007 management server can successfully install agents on managed computers and so that managed computers can communicate with the management server. (When using a managed computer, you do not need to create any firewall exceptions manually if you are using domain Group Policy rather than local Group Policy.)
If the agent installation fails, navigate to the Administration space (the gold cog in the lower-left corner of the main Essentials 2007 management console next to the Reporting navigation button), then click Pending Management. This view will provide troubleshooting steps, as well as offering you the ability to re-push the agent to computers that failed to install on first try.
Make sure you allow up to several hours for the firewall policy to be applied to all of the computers to be managed. If you try to run the Feature Configuration Wizard, select domain Group Policy, and the Computer and Device Management Wizard, all in quick succession, the firewall policy may not have had a chance to get applied to the computers you are discovering and thus cause discovery to fail if the firewall is still enabled.
One way to see whether an agent can be successfully pushed to a computer is to try to telnet to that computer from the management server. If you can telnet via port 135 from the management server to the computer, you are ready to go. If not, the firewall on that computer may be blocking TCP port 135. To run telnet, just launch a command window and type:
telnet <computer_name> 135
This will connect you to the computer name you specify with telnet via port 135. Port 135 is important because that's the port you use when installing the agent remotely.
If this doesn't work, make sure that the proper Windows Firewall exceptions have been created to allow agent deployment and communication with the management server. If not, you need to create the port exceptions shown in Figure 7. For all these exceptions, limit scope to the Essentials 2007 management server's IP address using the Custom list option.
Figure 7 Port exceptions

Protocol | Name | Port
TCP | Port 6270 | 6270
TCP | Port 135 | 135
TCP | Port 445 | 445
If your computers use firewall software from a third-party manufacturer, you should refer to the documentation for that product on how to create exceptions. However, the port exceptions listed in Figure 7 still apply.
If the NetBIOS name and fully qualified domain name (FQDN) do not match, then the DNS records for the machine must be corrected. If the agent installs, but fails to contact the management server, connect via Terminal Services or Remote Desktop to the agent computer and use the ping and nbtstat commands to verify that the agent can resolve the NetBIOS and FQDN names of the management server.
If the IP address of the Essentials 2007 management server is dynamically assigned, you must update firewall policies on managed computers when the IP address changes. To update firewall exceptions for a new management server IP address, enable the following two policy settings in Group Policy Object Editor, and configure them as I describe here. For "Windows Firewall: Allow remote administration exception," set Allow unsolicited incoming messages from to the new IP address of the Management Server. For "Windows Firewall: Allow file and printer sharing exception," set Allow unsolicited incoming messages from the new IP address of the Management Server.

Summary
I hope you find the information in this article helpful in getting started with System Center Essentials 2007. For more information about this new System Center product, go to microsoft.com/sce.
Just remember that there's no substitute for careful planning before deployment. In this case, you'll be deploying a brand new solution to manage your IT environment, so you need to take some time to think about your current network configuration, the way your users work, and the way you want to manage your IT resources. Considering these things first will help you successfully configure Essentials 2007 for your needs.

David Mills has been with Microsoft for seven years and is the Senior Technical Product Manager for System Center Essentials 2007. Before joining the System Center Marketing team, David led User Assistance teams in the Windows Server division shipping IT professional technical documentation for Core Networking and Management technologies.


System Center
Keep an Eye on Your Servers with Operations Manager 2007
Pete Zerger
At a Glance:
  • New features in Operations Manager 2007
  • Using the operations console
  • The role of roles
  • Powerful new reporting

System Center Operations Manager 2007 offers a great leap forward in the Microsoft operations management platform. Operations Manager 2007 represents a paradigm shift in strategy, moving from computer-focused monitoring to a true service-oriented
monitoring platform. While the new model bears some resemblance to its predecessor as an agent-based monitoring solution, carrying forward concepts familiar to any Microsoft® Operations Manager (MOM) 2005 administrator, much has changed. As you'll see, there are exciting new features, new management interfaces, and lots of additional resources for learning more about this latest addition to the Microsoft System Center Family.

Management Interfaces
In no place are the changes more apparent than in the new management interfaces. Gone are the separate Operations and Administrator consoles, and in their place is a consolidated Operations Console that delivers administrative, authoring, operational, and reporting functions (see Figure 1). Also gone is the single, often confusing folder tree of the MOM 2005 Administrator Console. An interface that looks much like Outlook® takes its place, exposing five function-specific workspaces: monitoring, authoring, reporting, administration, and my workspace.
Figure 1 Operations Console
Figure 1 Operations Console
The monitoring workspace exposes alert, state, performance, and diagram views of the network infrastructure in a clean interface, similar to what you'd see in the Operator Console in MOM 2005.
The Authoring workspace is where you configure new rules and create groups on which rules and monitors will operate. A dramatically improved reporting interface is integrated into the Operations Console, eliminating the need to visit a separate reporting Web site. An interface for executing administrative tasks, such as computer and network device discovery and configuration of security and notification settings, is also included. Finally, My Workspace allows users to create custom views, save frequently used views and searches, and configure custom alert notification subscriptions.
The Operations Console is loaded with context-sensitive help, including links to product documentation, online webcasts, and conceptual guidance. The Operations Console also includes rich search functionality, allowing users to define advanced search criteria for any object type, returning results based on object type and value characteristics defined in the search.
The Actions pane in the Operations Console offers a host of context-sensitive tasks that provide information on object configuration and state, and it allows you to launch the new Health Explorer for the targeted object (see Figure 2). In Health Explorer, the tree structure representing the health of the monitored objects for a given entity (monitored object) is hierarchical. Every entity is monitored on at least four parameters: Availability, Configuration, Performance and Security. These values cascade up; the state of each of these parameters is calculated based on the state of monitors that reside underneath it in the hierarchy.
Figure 2 Health Explorer
Figure 2 Health Explorer
Health Explorer diagnoses failures on monitored objects and gives you the ability to act on error conditions by clicking hyperlinks within the event detail. You also run any diagnostic or recovery task appearing in the details pane of the Health Explorer (as in Figure 3) on demand, or configure the task to run automatically when an alert is generated. The output of any diagnostic task (such as retrieving a list of running processes) will be displayed automatically in the details pane when the state change event is highlighted.
Figure 3 Diagnostics and recoveries
Figure 3 Diagnostics and recoveries

Web Console
The Web-based management capabilities of Operations Manager are greatly expanded in this release. The Web Console exposes the functionality of the Monitoring and My Workspace areas of Operations Console through Internet Explorer®, providing the same views available in Operations Console, including a fully functional Actions pane for executing context-based tasks, along with the ability to put monitored objects into maintenance mode (see Figure 4).
Figure 4 Web Console
Figure 4 Web Console
A mobile Web Console that allows access from any Web-capable mobile device is also included. The Web Console provides an RSS feed that delivers alerts to the Outlook 2007 Inbox or the RSS aggregator of your choice.

Command Shell
The Operations Manager Command Shell is a powerful interface that allows complete administrative control from the command line. Many complex tasks can be initiated in a single line of code (known as a one-liner). The Command Shell is a specially configured instance of Windows PowerShell™, the object-oriented command-line environment based on the Microsoft .NET Framework. This gives you access to a host of functions, called cmdlets, that can execute any task available in the Operations Console GUI—and a whole lot more. These cmdlets allow you to quickly and easily execute a task against multiple target objects (such as putting large numbers of agents in maintenance mode) that would be more time-consuming to perform through the Operations Console. For example, to export a list of all open critical alerts to a Web page, execute the following in the Operations Manager Command Shell window:
get-alert | where {$_.Severity -gt "Warning" -and $_.ResolutionState -eq 0 } | format-table
monitoringobjectdisplayname,name,severity,
description
The object-oriented nature of Windows PowerShell is what makes the Command Shell so powerful. You get the power of the Operations Manager .NET class libraries without the need to know C# or Visual Basic® .NET.

Computer and Device Discovery
Computer discovery and agent deployment have evolved in Operations Manager as well. You can discover agents using the Computer and Device Management Wizard from the Operations Console, allowing administrators to search Active Directory® or manually enter a target computer or list of computers (see Figure 5). Detailed Lightweight Directory Access Protocol (LDAP) queries allow for more granular targeting of specific computers for agent deployment.
Figure 5 Advanced discovery via Active Directory query
Figure 5 Advanced discovery via Active Directory query
The wizard lets you discover Simple Network Management Protocol (SNMP)-enabled devices, which can then be targeted for monitoring in management pack rules.
Integration with Active Directory is another significant improvement. It lets administrators register management group information in Active Directory (via a simple utility) so Operations Manager agents can locate the appropriate management server by querying Active Directory at startup. The new integration also allows administrators to automate and simplify agent deployment by including an Operations Manager agent in a machine image, deploy agents via popular systems management platforms (such as Systems Management Server 2003 or System Center Configuration Manager), or through Group Policy.

Security
Operations Manager 2007 can be used to monitor many types of applications, some of which may need to be restricted to certain support personnel. Fortunately, the new role-based security model has five default user profiles that group access based on common job functions, ranging from read-only operator to administrator. Each of the default user roles is based on one of these default profiles. User roles define which types of operations can be performed by a user and the scope of these rights. You can also create custom roles by selecting one of these default profiles and then setting the scope of the role to restrict visibility of monitoring data to the desired subset of monitored objects, tasks, and views. Both standard and custom user roles based on these user profiles can be assigned to Active Directory security groups, placing user provisioning tasks back into the hands of security administration staff.
Run As Execution, also new in Operations Manager 2007, provides a secure infrastructure for managing the credentials required to perform specific actions. For example, some monitoring tasks may require highly privileged credentials or even non-Windows-based credentials.
Run As Accounts must be associated with a Run As Profile, which can in turn be associated with a rule or task that requires special privileges. The Run As Profile lets management pack authors abstract the account requirement during the authoring process so the admin can associate an appropriate Run As account after the management pack has been installed in Operations Manager.
Operations Manager 2007 delivers greater security than its predecessor in communications between agents and management servers by requiring mutual authentication. In trusted environments, mutual authentication can be achieved through Kerberos. For untrusted and perimeter network environments, the situation can become more complicated. Mutual authentication requires certificate-based authorization using x.509 certificates, which will require organizations to consider their Public Key Infrastructure (PKI) options if they don't have this in place.

Server Roles
While the management server, operations database, and reporting server roles from MOM 2005 remain in Operations Manager, new management server roles have been introduced. The root management server role isolates critical functions such as user authorization, notification, and management of console connections to a dedicated role in the infrastructure. For best performance, the root management server should be dedicated to this role and no agents should be configured to report to this server.
The new gateway server role accommodates more efficient use of management computers across untrusted domains and perimeter environments by providing a single communication back to the management server. In many cases, agents in the target domain can be authenticated to the gateway server via the Kerberos protocol, minimizing the need for certificate-based authentication and reducing administrative effort and total cost of ownership.

Reporting
Users will find that Operations Manager 2007 delivers notable improvements in reporting, with an integrated Reporting space in the Operations Console. Likewise, security for reporting is integrated with overall Operations Manager security.
There are a number of major architectural changes, including when and how data is delivered to the reporting database. Gone is the nightly Data Transformation Services (DTS) task that transferred the previous day's reporting data from the operations database. Instead, data is inserted directly into the reporting database at the same time it is inserted into the operations database, resulting in almost no latency.
Operations Manager reports contain new smart parameter headers, providing the flexibility to define and report on specific and relative date and time ranges, including restricting report output to a user-defined range of business hours. The object picker in the smart parameter header provides search, in order to simplify the task of targeting objects for reports. In scheduling reports, the flexible date picker eliminates the need to modify report definition files to achieve a specific relative date range in recurring reports (see Figure 6).
Figure 6 Configuring business hours
Figure 6 Configuring business hours
Another reporting improvement aims to ensure that reports render quickly, even when they executed on extended date ranges. To that end, Operations Manager reporting data is automatically pre-indexed and aggregated into hourly and daily summary data points, which are used in all Operations Manager reports. In addition to having the data already compiled, this improves data warehouse scalability as the raw data points can be compressed in the database much more aggressively without impact to historical reporting capability.
By far, the most impressive improvements involve the content and features of the rendered reports themselves, which present historical performance and availability data in a format relevant to network engineers and IT managers.
Figure 7 shows a standard performance report, which consists of a graph with a table. Both the lines in the graph and the descriptions in the table provide click-through to a detail report, as shown in Figure 8.
Figure 7 Standard performance report
Figure 7 Standard performance report
Figure 8 Performance detail report (drill-down)
Figure 8 Performance detail report (drill-down)
Availability reporting in Operations Manager is based on object state. Any object that can have state can be targeted in an availability report out of the box. You can move from the detail report to an availability report in a single click (see Figure 9).
Figure 9 Availability report
Figure 9 Availability report
For management packs without reports, there are generic reports that will accommodate reporting of availability and performance of almost any managed object, sharply reducing the need to author custom reports.
Administrators will be pleased to find that out of the box, Operations Manager 2007 supports multiple management groups reporting to a single reporting data warehouse. Reporting security is integrated with the role-based security of the product, allowing administrators to control report access through Active Directory security groups.

Notification
The Notification engine has undergone a complete retooling in Operations Manager 2007, emerging with new features that administrators have been clamoring for, including additional notification options (called notification channels) such as instant message and SMS (this requires a third party SMS provider be installed on the management server). Notification subscriptions now include a scoping option so administrators can limit the visibility of object types and groups available to operator roles and more accurately target notification subscriptions.
Alert aging (escalation) allows notification to be sent when an alert that meets the criteria defined in the subscription remains in a given resolution state for a period of time defined by the user.
Message formats can now be customized on a per-subscription basis, allowing message format customization down to the individual user level. Plus, self-service notification in the My Workspace pane of the Operations Console allows users to define their notification device and subscription settings. These are just some of the notification features you'll find extremely convenient.

Management Packs
Management packs still represent the base framework of service and application monitoring in Operations Manager 2007, delivering application knowledge direct from the Microsoft product teams. However, they shift from server monitoring to service-oriented monitoring—focusing on the health of the service being delivered.
Space constraints preclude going into depth here, but you should note that the simple object type model of MOM 2005 (computers and computer groups) has been revamped as an extensible model with dozens of monitored object types that can be targeted. The end result is a rich development environment for third-party ISVs to deliver outstanding line-of-business, network, and cross-platform offerings.
Simple monitoring rules, similar to those available in MOM 2005, are used for a variety of common monitoring tasks, such as text and Event Log monitoring, WMI event queries, scripts executed on a schedule, and a vastly improved SNMP trap provider that eliminates the need to compile SNMP management information bases.
However, in Operations Manager monitors detect change in the state of managed objects. Monitors include many functions not seen in MOM 2005 providers, such as TCP port checking, synthetic transactions for database and Web site connectivity, ASP.NET application and Web service monitoring, and perhaps most importantly, service-oriented monitoring for distributed line-of-business applications. I'll cover these in a bit more detail momentarily.

Self-Tuning Thresholds
Sometimes behavior is not known for a given counter. For such situations, Operations Manager provides self-tuning threshold monitors. A self-tuning threshold monitor uses a learning process over the defined business cycle (usually one week, but perhaps as short as one day) to determine the normal values for a specified performance counter object and to then define thresholds based on operational norms recorded during the learning period. These thresholds represent expected activity, including sharp drops or spikes in resource utilization, as might be experienced during nightly application and system maintenance.

Synthetic Transactions
For a more dynamic picture of application health, Operations Manager offers synthetic transactions, which are actions run in real time against monitored objects. Synthetic transactions can be created for Web site browsing sequences, database connectivity and TCP port monitoring. You can specify the server nodes from which the transactions will run (called watcher nodes) as well as the desired monitoring interval. If multiple watcher nodes are chosen, the results can then be compared to determine if the experience from each node is the same.
The Web Application Editor used to capture Web browser sequences also allows administrators to define warning- and error-level response-time thresholds, as well as specify performance counter collection for individual operations within page load and link retrieval. Secure (SSL) browser sequences requiring a variety of authentication methods (such as Basic or NTLM) are supported.
Overrides, a familiar MOM 2005 concept, are used to adjust the configuration of Operations Manager settings for monitors, attributes, and rules for an object or a group of managed objects (see Figure 10). The use of overrides is key to controlling the amount of data that is collected by Operations Manager. You can use groups and overrides together to narrow the focus of the monitor, rule, attribute, or object discovery to a target group of objects not only in your own management packs, but in those of Microsoft and third-party ISVs as well.
Figure 10 Override parameters for a service monitor
Figure 10 Override parameters for a service monitor

Line-of-Business Application Monitoring
The new Distributed Application Designer lets you create a service-level picture of critical applications, and then delivers a summary health indicator of distributed application components. This includes any discovered object type, such as a Web service, SQL Server™ database, and even non-Windows devices such as network routers and switches. Object relationships and current health state can then be viewed in a diagram.
To make this powerful feature more accessible, Microsoft offers several distributed application templates to give administrators a starting point for defining their own line-of-business applications. Templates for many common scenarios are available, including ASP.NET Application and ASP.NET Web service, Line of Business Web Application, Messaging, SharePoint® Portal Farm, and Terminal Services Farm.
New templates can be added to the Management Group through Microsoft or third-party management packs, which then appear in the Add Monitoring Wizard. Distributed application monitors for Active Directory, Exchange, and Operations Manager are pre-deployed and cannot be edited.

Management Pack Availability
Management packs written specifically for Operations Manager 2007 (called optimized management packs) are designed to take advantage of the new features in Operations Manager 2007 and are scheduled to be available for new software releases starting in 2008. However, existing MOM 2005 management packs can be converted to Operations Manager 2007-friendly format using the MPConvert utility, or they can be transferred from an existing MOM 2005 installation using the MOM 2005-to-Operations Manager 2007 migration tool; both tools can be found on the Operations Manager 2007 CD. Microsoft is actually converting the MOM 2005 management packs to Operations Manager 2007-compatible format, so this should generally be necessary only for home-grown management packs.

Audit Collection
Audit Collection delivers the solution to automate collection and centralized archival of distributed Windows Security Event Logs. It is designed for medium and large enterprises requiring collection and analysis of a high volume of Security Event Log data for internal and external compliance auditing. Audit Collection consists of four roles: the Collector, Forwarders, the database role, and the reporting role. The Collector is the server that "catches" events and inserts them into the Audit Collection database. The Forwarder is a service that sends Security Event Log events in near real time, minimizing the likelihood that local administrators can interfere with Security Log Events. The Forwarder service is included in the Operations Manager 2007 agent, but is disabled until Audit Collection is enabled for a given agent.
Audit Collection employs automatic nightly database maintenance, ensuring consistently good report-rendering performance across large datasets. Audit Collection maintains a rolling dataset (stored for 14 days by default) that can be adjusted by administrators to meet their organizational requirements. For analyzing collected events, Audit Collection includes a Reporting role including a base set of about 20 audit reports as well as a high-performance WMI subscriber, providing an easy interface for ad hoc queries without the need to grant administrators database access directly.

Client Monitoring
The new client monitoring features in Operations Manager 2007 enable administrators to monitor desktop operating systems and applications, to help determine which errors are occuring most frequently so efforts can be directed to achieve the greatest benefit for the organization. The error data collected is used to produce detailed views and reporting, giving the administrator a readily available source of information to facilitate support decisions.
Client monitoring in Operations Manager 2007 actually consists of three levels that can be enabled individually:
Agentless Exception Monitoring (AEM) enables the administrator to monitor operating systems and applications for crashes and errors. The administrator can direct these reports that would previously have gone directly to Microsoft to a Management Server, from which they can then be forewarded on to Microsoft if you choose to do so.
Customer Experience Improvement Program (CEIP) When you participate in the CEIP, you configure clients with Group Policy to redirect reports to an Operations Manager 2007 Management Server, instead of sending reports directly to Microsoft. The Management Servers are then configured to forward these reports to Microsoft.
It is important to note that the AEM and CEIP client monitoring components can be performed agentlessly.
Client Monitoring for Business-Critical Workstations involves actually deploying an Operations Manager agent to business-critical desktops. Management packs include those for Windows 2000, Windows XP, and Windows Vista, and the Microsoft Information Worker which monitors Microsoft Office, Internet Explorer, and other Microsoft desktop applications.

Give It a Try
As you can see, System Center Operations Manager 2007 brings a host of features designed to deliver service-oriented monitoring with integration in all the right places, allowing you to take advantage of existing investments in Active Directory, streamline administration, and reduce total cost of ownership. I encourage you to try this great new release and explore its possibilities.
You can download a 180-day trial copy of Operations Manager 2007 at microsoft.com/technet/opsmgr/2007/downloads/trials/privacy.mspx. For more information on Microsoft System Center technologies, visit the System Center Operations Manager homepage at microsoft.com/systemcenter/opsmgr. See System Center success stories (videos and case studies) on the new "Designed for BIG" Web site at designedforbig.com.

Pete Zerger is a consulting partner with AKOS Technology Services. Pete has nine years of experience in the IT industry, and he focuses on design and deployment of enterprise operations management, directory services, and messaging solutions. Pete holds an MCSE for Messaging, an MCTS for SQL Server 2005, and he is a Microsoft MVP for Microsoft Operations Manager.


System Center
Migrating from MOM to Operations Manager 2007
Andy Dominey
At a Glance:
  • Planning an Operations Manager deployment
  • Assessing hardware needs
  • Preserving historical data
  • Testing plans

Server monitoring and management is a critical part of any modern IT infrastructure. It is vitally important to ensure that your IT infrastructure is not only working correctly but that it is adequate to support the load exerted on it by users. Gathering this information is easier
said than done, however, and knowing what to do with the information once you have it is another story altogether. Fortunately, there's help. Microsoft® Operations Manager (MOM) has been making this possible for seven years, and its latest incarnation, System Center Operations Manager 2007, expands on that foundation.

Why Migrate?
System Center Operations Manager 2007 offers numerous significant improvements over the previous version, MOM 2005. The core architecture has been redesigned and greatly improved to allow the product to be more aware of applications spread across multiple devices and also to be aware of not just servers but all the components that make up a server.
Furthermore, Operations Manager boasts a powerful collation engine that is able to aggregate alert data, greatly reducing the number of spurious alerts, as well as a Health Explorer that helps streamline the process of locating and resolving issues.
There are self-tuning thresholds and a baselining engine that allow you to easily track performance usage across your environment, and the reporting engine is much improved, offering superior graphics and drill-through reporting. Take a look at Figure 1 for a taste of the visual presentation of report data.
Figure 1 Availability Report in Operations Manager 2007
Figure 1 Availability Report in Operations Manager 2007
Operations Manager can even be used to monitor desktop machines as well as servers. Here are some additional features offered by Operations Manager 2007:
  • Excellent monitoring for the Windows Server System™ platform
  • Powerful application monitoring capabilities and functionality
  • Automation of common tasks
  • Next-generation database engine facilitating enterprise-level scalability and control
  • Security enhancements and Active Directory® integration
For even more information about the new features that are available in System Center Operations Manager 2007, check out the article "Keep an Eye on Your Servers with Operations Manager 2007" by Pete Zerger in this issue of TechNet Magazine.

Migrating to Operations Manager
Before you plan your migration to Operations Manager 2007, you need to be aware that there is no direct upgrade path for the product. With such significant architectural changes to Operations Manager, the product could not remain compatible enough with previous versions to allow an in-place upgrade. Therefore, if you are currently running either MOM 2000 or MOM 2005, you will need to consider one of the migration strategies described later in this article.
If you are not running a previous version of MOM, however, you can simply install the new version of the product. Keep in mind that you'll have to decide very early on in the project whether you have sufficient in-house skills to carry out the installation or migration or whether you'll need to obtain assistance from a third party. Obviously, this will have an impact on the overall cost of the project, so it should be considered at the begining of this process.

Migration Scenarios
For those who are not currently running MOM, the deployment is straightforward: plan and design the architecture and then deploy the software. However, if you are using MOM, Microsoft supports two migration scenarios; side-by-side on the same hardware and side-by-side on different hardware. Let's explore both.
Side-by-Side on the Same Hardware In this scenario, you install Operations Manager on the same physical hardware as your existing MOM 2000 or MOM 2005 architecture. This approach is useful for sites where the MOM infrastructure is not heavily utilized and where the server hardware is sufficiently powerful to co-host both old and new versions. You should only consider this path if the installation of Operations Manager will not seriously impact the performance of the current MOM servers.
Side-by-Side on Different Hardware In this case, the new installation is performed on new or different hardware. This is the preferred approach as it ensures that there will be little impact on the current management infrastructure while the migration is taking place. It is worth noting that additional hardware is not necessarily required. The new Operations Manager 2007 servers can be staged on virtual machines until the old server hardware can be reallocated.

Considerations
Before you commit to a particular migration strategy, there are some important points to consider.
First, you need to think about hardware and software requirements and the associated costs. Even if you decide to stage or provision some or the entire Operations Manager infrastructure onto virtual machines, you still need to allow for OS and application licenses as well as OMLs (Operations Management License) for each agent to be monitored by Operations Manager.
Second, you need to plan for resourcing to carry out the work. In a small business, this may not be a particularly complex or difficult plan, but in larger companies it will be a key part of the overall migration strategy.
You also need to consider the potential impact this migration might have on either the current monitoring infrastructure or the server estate as a whole. You should plan for every eventuality, including the possibility of server reboots or even failures of critical production servers.
Note that if you are using either the Microsoft Access™ database in MOM 2000 or the SQL Server™ data warehouse in MOM 2005 for archive data storage and reporting, migration of this data to Operations Manager 2007 is currently unsupported.

Planning for a Successful Migration
As a consultant, one of the biggest problems I see is inadequate deployment planning. Therefore, once you decide whether you will install on new or existing hardware, the next step is to create a project plan.
Your project plan should list the stages of the project suggested in this article—though this is not an exhaustive list. Be sure to allocate sufficient time for each stage of the project, and to account for any resources that are required.
As I noted, System Center Operations Manager 2007 has a significantly different architecture than MOM 2000 and 2005. For starters, there is an additional server role in Operations Manager, the Root Management Server (RMS). The RMS manages the configuration for the Management Group, handles all connections to other Management Groups and third-party products, and is also responsible for security across the Management Group. This role can be held on an existing System Center Operations Manager Management Server, but in large, complex environments it should be given its own physical server. Also, the concept of tiered Management Groups that existed in MOM 2005 has been replaced with Connected Management Groups. In this new architecture, no alert data is actually passed between the Management Groups; instead, alerts from Connected Management Groups are simply presented in the UI of the requesting Management Group. In addition, if you're thinking about installing agents on machines in untrusted domains or workgroups, you will have to use certificates to allow the agent and Management Server to mutually authenticate (a feature that is forced in Operations Manager).
In order to design the architecture for System Center Operations Manager, you will need to consider the number of servers and clients you plan to monitor, whether they are located in a trusted domain, which applications and platforms you need to monitor, and whether you want to monitor your network infrastructure. You also need to identify any applications that will require custom rules or management packs.
This is the stage at which you should identify your management pack requirements. Once you have determined the applications you'll monitor, you can decide which management packs you are going to install. Management packs contain rules, monitors, tasks, and classes that apply to a particular application or operating system and should be imported if their associated application or operating system is in use in your environment. The choice of management packs at this stage will impact the hardware and software requirements and the amount of time that should be allocated to installing and configuring the software.
Once you have an idea of the architecture of your Operations Manager infrastructure, you should break out the System Center Capacity Planner 2007 tool (in beta at the time of this writing). Use the tool to map out your network and server infrastructure and simulate running it against your planned Operations Manager deployment to ensure that it is sufficient to monitor and manage your infrastructure.
It is at this point you should also pay particular attention to architectural design if you are planning to migrate. You need to consider the fact that MOM 200x will be running alongside Operations Manager, resulting in additional network traffic.

Deployment
Deployment is the next stage to think about. You need to be sure that adequate hardware is provisioned before you install the software. If you are installing into a new environment, physical hardware is better, especially for the database server. However, Management Servers can be virtualized if physical hardware is not an option. In a migration scenario, the use of virtualized servers is a good alternative to purchasing hardware to stage the new infrastructure. In this situation, you can use virtual machines to stage Operations Manager while the old MOM servers are decommissioned and rebuilt.
Once the servers have been provisioned, you can begin to install the software. First, make sure that the servers that will run Operations Manager have the required software prerequisites to support it. For example, if you are running SQL Server 2000 and are planning to install Operations Manager on the same server, you will need to first upgrade to SQL Server 2005 with SP1. To check this, you can run the Operations Manager prerequisite checker from the System Center Operations Manager installation media.
After all of the software prerequisites are in place and you've configured SQL Server and Reporting Services, you can begin to install the Operations Manager software. In a single-server environment, this is easy; you simply run the Operations Manager setup file on the server, then run the Operations Manager reporting setup if you want to use that feature. In a distributed environment, however, the Operations Manager components need to be installed on the individual servers in the correct order. First, you install the database, then the first Management Server, which will automatically be assigned the Root Management Server role. After this, any additional Management Servers can be installed. As the final step, you install the Web console and the reporting components.

Migration
At this stage, you should make sure that your new infrastructure mirrors your existing monitoring before attempting to take advantage of any new features. Any management packs used in the legacy environment should be duplicated in the new Operations Manager deployment. If there is an Operations Manager management pack available, you may wish to import it, but any management packs that do not have newer versions will need to be exported from the current Management Group, converted using the MPConvert tool from the installation CD and imported into Operations Manager—unless you have a small or simple custom management pack, in which case it would be better to simply recreate it. There is also a tool that is useful when duplicating configuration. The MOM 2005 to Operations Manager migration tool helps to duplicate configuration from an existing MOM Management Group to Operations Manager; you'll find it on the Operations Manager installation CD as well. Figure 2 shows a typical configuration during a migration.
Figure 2 Typical configuration during migration
Figure 2 Typical configuration during migration
Once your configuration is duplicated, you need to ensure that you are actually getting the same alerts and collecting the same data with Operations Manager as with MOM. Fortunately, the Operations Manager agent can coexist with legacy MOM agents so both agents can run simultaneously. You can collect data from both and compare them side-by-side for accuracy before decommissioning the legacy system.
Next you should formulate a testing plan. Testing may consist of simply comparing the alerts from the legacy system with those of the Operations Manager system, but may also go as far as to require the purposeful generation of alerts to thoroughly assess the new infrastructure. Once you are satisfied with the test results, you can begin to uninstall the legacy MOM agents, by using either the MOM console or Add/Remove programs on the agent machines.
Reporting is a big part of a MOM and System Center Operations Manager deployment and also needs to be addressed. The existing SystemCenterReporting database can't currently be migrated to Operations Manager 2007, so you can create a new instance of Reporting Services for Operations Manager and keep the existing MOM 2005 (SystemCenterReporting) database in a dedicated SQL Reporting Services instance to display the legacy reports. The new reporting console in System Center Operations Manager 2007 is integrated into the product so it is not recommended to use the Reporting Services console for anything other than Operations Manager. The migration of reporting data is something that may be addressed in the future by means of a data migration script, but in the meantime you might have to say goodbye to your archived reporting data and simply take comfort in the fact that when you start generating your new flashy reports, management will be so excited they may not even notice that your old data is gone.

Conclusion
System Center Operations Manager offers significant improvements over MOM 2000 and 2005, but these advances can come at a cost. A major change in the underlying architecture (and the resulting lack of a direct in-place upgrade path) means that deployment costs have the potential to be higher. The key to minimizing these costs is to that you adequately plan and ensure that you have the right people for the job. Do this and you can reap the benefits of Microsoft's hard work with System Center Operations Manager.

Andy Dominey has been in the IT industry for eight years and is currently employed at 1E as a Windows Management Specialist based in the UK. He has been working with MOM since MOM 2000. Andy received the Microsoft MVP award for the past two years for MOM.


System Center
Take Your Apps Virtual with Microsoft SoftGrid
Ahmer Sabri and Kedar Shah
At a Glance:
  • Benefits of application virtualization
  • Overview of the SoftGrid architecture
  • Streaming software packages

The concept of software virtualization, in some form or another, has been around since the 1960s. However, it has taken the IT industry decades to begin to realize the potential of application
virtualization. People are now catching on, and major developments are being made.
Microsoft threw some weight behind application virtualization when it acquired Softricity back in July 2006. From this acquisition comes Microsoft® SoftGrid, a solution for application virtualization. With SoftGrid, applications are served from a datacenter or another network location and run locally on remote clients in a virtual environment. The virtualized applications run in silos and operate independent of the operating system and other applications on the local desktop.
There are many benefits to implementing application virtualization with SoftGrid—too many to discuss here. However, the following are some of the most notable and immediately recognized benefits:
Simplified Regression and Compatibility Testing By running multiple versions of the same application in parallel on a single machine without conflicts, you can dramatically reduce the complexity, time, and costs associated with testing and deploying new applications (see Figure 1).
Figure 1 Streamlining application deployment with SoftGrid
Figure 1 Streamlining application deployment with SoftGrid
Easier Systems Management IT has great control over the environment in which these applications run, making it easier to maintain the ideal desktop environment.
Fewer Help Desk Calls With better managed desktop environments and fewer conflicts (thanks to virtualized apps running in a controlled silo), users require fewer calls to the help desk.
Enhanced Desktop Security Applications are never installed on the OS, improving overall OS security. Apps are only provisioned to authorized users, thus preventing unauthorized access. And most apps are rendered under standard security context.
Free Seating Experience User preferences (profile and other settings) are stored on the network, thus allowing users to access their applications, preferences, and controls from any PC.
Improved Fault Tolerance and Disaster Recovery Applications are turned into data files that can be stored and replicated like any enterprise data. Applications and their updates can be synchronized automatically between live and Bulk Copy Program (BCP) sites using third-party tools, enabling instant access to applications in case of a disaster.
Ultimately, these characteristics ease the burden of system administration, reduce costs, and allow your organization to adopt new technologies more quickly and reliably. Now let's look more closely at just how SoftGrid works.

How Virtualized Applications Are Served
The SoftGrid architecture is composed of a number of components that work together in symphony. It involves SoftGrid components such as the data store, virtual application server, sequencer, management consoles, the management Web service, and client app, working in conjunction with standard infrastructure components, such as Active Directory® (see Figure 2). We'll give you an overview of the SoftGrid architecture and explain how the various components work together.
Figure 2 Overall SoftGrid architecture
Figure 2 Overall SoftGrid architecture
The SoftGrid data store acts as a central repository for the entire virtualization environment. Installed on either SQL Server™ (version 2000 or 2005) or the Microsoft SQL Server Desktop Engine (MSDE), the data store holds records, applications, configuration, licensing data, reporting information, and logging information.
Virtualized applications are served to the user's machine and rendered in a client. SoftGrid offers two types—Microsoft SoftGrid Application Virtualization for Universal Desktops and Microsoft SoftGrid Application Virtualization for Terminal Servers. Each approach has advantages but also has certain performance trade-offs, which we'll cover in the section Setting Up the Client.
One of the most critical components in the SoftGrid environment is the SoftGrid Virtual Application Server (SVAS). This is used to handle user requests for applications and to stream the application data to the users on demand.
SVAS runs as a Windows® service called Microsoft System Center Virtual Application Server and has very modest hardware requirements. By default, all the application data itself (which we'll discuss in a moment) is located in the \Program Files\Softricity\SoftGrid Server\content directory.
The typical SoftGrid experience is initiated when a user logs on to a workstation. SoftGrid Client captures the user's security token and domain group membership and passes this information via a secure channel to SVAS. SVAS assigns the user access to applications, provided the user's Security Identifier (SID) exists in the application's group membership directory, and a shortcut for each application is placed on the user's desktop (or in whatever other location the administrator may define, such as the start menu, quick launch toolbar, and so on).
Actual delivery of an application is generally started when a user clicks the shortcut icon, which is associated with an Open Software Description (.osd) file. This is an XML-based file that contains information about the application package. The client retrieves the virtual application server name from the .osd file and initiates a connection. At this time, SVAS authenticates the client and contacts the data store to determine license compliance. Once the user is authenticated, SVAS streams the application data to the client in data blocks—by default, the data blocks are 32KB each but can be configured at the time of sequencing.
Note that the entire application is not streamed to the client. Instead, SoftGrid streams only the portion of the application that is immediately required to launch the app on the client. This is typically about 20 to 40 percent of the total code, though this can certainly vary by application. For example, Microsoft Word 2003 only requires 15MB of data to be streamed to the client before it can be launched, compared to the 800MB total size of the package. If the user accesses a portion of the application that is not already in the client's cache, the necessary code is then streamed to the client. To avoid the Monday morning effect, in which too many simultaneous requests clog the network, organizations can choose to pre-cache common applications on user desktops.

Active Directory
SoftGrid relies on Active Directory (or Windows NT® 4.0) domain users and groups for provisioning applications to authorized users. In a multi-domain environment, users can be provisioned using the appropriate group memberships (SoftGrid supports local, global, and universal group memberships) and trust relationships with the domain where SVAS is installed.
When installing SVAS, you are prompted for different service accounts and groups, which help with the integration with Active Directory and are subsequently used for administrative purposes. Thus, there are three groups and accounts that you should create prior to installation: a SoftGrid Browser Account, a SoftGrid Administrators Group, and a SoftGrid Users Group.
The SoftGrid Browser Account is responsible for browsing Active Directory and, therefore, requires read-only rights to all the Active Directory domains in a multi-domain environment. The SoftGrid Administrators Group is used to grant administrative access to SoftGrid Management Console and SoftGrid Management Web Service. And the SoftGrid Users Group is used to assign default provider policy, which is used to give all users in the domain access to applications published through the management console.

The Virtual Environment
SystemGuard is at the core of SoftGrid Client, which runs on the local desktop. SystemGuard is responsible for providing a fully functional virtual environment for applications to run in isolation. Contained in this siloed environment are the virtualized OS components—registry, files, fonts, INI, COM, embedded services, and environment variables—that are required for the application to run properly (see Figure 3).
Figure 3 Virtualized environment for application to run in isolation
Figure 3 Virtualized environment for application to run in isolation
SystemGuard creates virtualized registry keys for every application it runs. These keys are not accessible to other applications running on the local OS, nor are they visible to registry editing tools such as regedit. Registry reads and writes are redirected to the virtual keys as needed. Note, though, that virtualized applications are allowed to pass through to the local registry for information not contained in the virtualized registry keys.
Similarly, SystemGuard creates a virtualized file system and redirects the majority of the application's reads and writes to this file system. This virtualized file system is isolated and provides the environment you need if you want to run multiple versions of the same application on a single client.
We should point out, however, that while the applications are isolated from the local OS, the user still has access to all the local services, such as print, cut and paste, and network drives.

Packaging Applications
Now you might be wondering how you create a fully functional independent environment for your virtualized application to run in. For this task, you use SoftGrid Sequencer. This wizard-based tool allows you to package applications in a virtual environment that can be delivered and executed on the client.
The sequencing process involves three steps: Installation, Configuration and Test, and Execution. In the first step, Installation, the SoftGrid Sequencer uses an active watch process to monitor the installation of the application and assess application dependencies. Once complete, the Configuration and Test phase is used to make any necessary changes to the default configuration in order to ensure the desired first-run experience. Finally, in the Execution phase, the SoftGrid Sequencer compiles and orders the code block necessary to launch the application. Feature Block 1 (FB1) is the essential code required to launch the application, allowing the user to run the application without downloading the entire package.
Once an application has been sequenced, four files are created: a virtualization-enabled application file (.sft), an Open Software Description file (.osd), an Icon file (.ico), and a project file (.sprj). These are then copied to the content directory of SVAS. Alternatively, an administrator can publish .ico and .osd files to the clients using an HTTP server.
While SoftGrid typically provisions applications to run independently of each other in isolated environments, SystemGuard does permit some application interaction. You should carefully examine any dependencies applications may have on one another and sequence applications together if they rely on interacting with each other. This process is commonly referred to as suiting. Note that not all applications that require interaction with one another can be sequenced together. Suiting is a very intricate process and should be done only after careful examination of the dependencies, as sometimes sequencing two or more applications defeats the purpose of virtualization.

Simplifying Administration
The SoftGrid management console provides a single tool for performing all the administrative tasks. The management console is installed on the SVAS by default and can be installed on any other server or workstation. It is an MMC 3.0 snap-in and uses the SoftGrid Management Web Service to connect to the SoftGrid DataStore (see Figure 4), giving authorized administrators full access to data stored in the database for management purposes. The connection between the management console and the SoftGrid Management Web Service uses Microsoft .NET Framework remoting, making it possible to install the management console and the Web service on the same or different servers. Figure 2 illustrates how these various pieces fit together and provide access to the entire SoftGrid implementation. Note that larger organizations should run more than one instance of the SoftGrid Management Web Service.
Figure 4 SoftGrid Management Web Service provides the connection to the data store
Figure 4 SoftGrid Management Web Service provides the connection to the data store
The SoftGrid Management Web Service runs on Windows 2000 or later with IIS 5.0 or later. The .NET Framework 2.0 or later is required, as well as Microsoft Data Access Components (MDAC) 2.7 or later for data store connectivity.
The management console provides a single administrative tool from which applications can be published, terminated, and so on. Tasks are organized into nine main categories or containers, as shown on the menu in Figure 5.
Figure 5 Managing SoftGrid from a single management console
Figure 5 Managing SoftGrid from a single management console
Here's a quick rundown of the types of management tasks found in each container. The Applications container is where the administrator can do things such as import .sprj files to publish newer applications, specify .osd location, remove applications, and so on. By default, this container includes a published package you can use to test client connectivity to the application server.
A file type association is created when the applications are sequenced. Once the package is imported, the file type associations become available in the management console. The File Type Association container provides a single place for administrators to modify all file type associations.
The Packages container controls versions of packages for active upgrades; these are application upgrades that can be done without the user disconnecting or the server being shut down. The administrator can also delete a package from the management console using this container. Note that deleting a package from the Packages container will remove the .sft file from the management console and the data store but will not delete it from the content directory on the application server.
As we mentioned earlier, when a user launches an application, SoftGrid Client checks for license availability and launches the application only if a license is available in a data store. The Application Licenses container is where administrators can associate licenses with applications—unlimited licenses, concurrent licenses, and named licenses are all supported.
Server Groups contains a logical grouping of application virtualization servers and logging information. Administrators can add new server groups or modify properties (such as ports used for communication or allocated memory and processes) of an existing group.
In the Provider Policies container, the administrator can create a set of rules called policies. The custom provider policies are used to give users access to numerous applications under different sets of conditions. You can use the Account Authorities container to specify a domain and credentials that will be used when SoftGrid needs access to read the domain's directory information. SoftGrid Administrators contains the user groups responsible for administering the SoftGrid environment. In this container, administrators can add or remove groups to control access permissions.
Lastly, the Reports container, as its name implies, allows administrators to generate reports to check the overall health of the SoftGrid environment. The following reports are available: Application Utilization, Software Audit, System Utilization, User/Group Activity, and System Error.

Setting Up the Client
The SoftGrid Client is installed on the operating system of the computer the user will use to access the virtualized application. As we mentioned earlier, two client types are supported: Microsoft SoftGrid for Desktops or Microsoft SoftGrid for Terminal Servers. Each approach has advantages but also certain performance tradeoffs, in terms of network latency, server farm consolidation, and ease of management.
In a desktop implementation, applications are available locally and there is little dependency on network availability and throughput. This approach is recommended, for instance, for organizations that have branch offices with limited IT infrastructure. Terminal Services is a good option for an organization that has already rolled out terminal servers. This scenario makes efficient use of hardware and software, drastically reducing the number of necessary servers. And, of course, it enables a true free seating environment. Large organizations will typically have a combination of desktop and terminal server infrastructure. Installing and configuring the various components is similar for both approaches when you set up a SoftGrid deployment.
The client can be deployed using any standard method, such as manual installation or automated deployment using a tool such as Systems Management Server 2003. Figure 6 lists the minimum hardware and software requirements needed to install these clients.
Figure 6 System requirements for the SoftGrid clients

Client | Processor | Memory | Disk Space | Operating System
Microsoft SoftGrid for Terminal Servers | PIII 850MHz | 1GB RAM (minimum 256MB, actual dependant on number of users and applications | 12MB for installation and 4096MB for cache | • Windows 2000 Server or Advanced Server with Terminal Services enabled • Windows Server 2003 with Terminal Services enabled
Microsoft SoftGrid for Desktop | PIII 600MHz | 128MB | 12MB for installation and 2048MB for cache | • Windows 2000 Professional or Windows XP • Windows 2000 Server or Windows Server 2003
Although the installation of the client is straightforward, there are some properties you must provide at the time of installation—such things as the location of the installation, the cache size, the drive letter to be used for the virtual drive, the location of application data files, and so on. Once the client has been installed, some additional settings can be specified or changed using the client management console.
To launch the client management console, go to the control panel and launch SoftGrid Client Management from Administrative tools. You can choose to connect to the local machine or to a remote machine.
Figure 7 shows how the client management console consists of a root container and three child containers. The SoftGrid on localhost root tab is where you can specify most of the functional parameters, including logging directory, application data directory, client run and display settings, error and informational message pop-up frequency, maximum cache size, virtualized drive, network and connectivity options when disconnected from SoftGrid server, and permissions.
Figure 7 Client management console
Figure 7 Client management console
You can view and change applications in the Applications container. The Applications container provides status information about the local application, such as whether the application is running, if the application is locked in cache, and what percentage of the application (.sft file) has been streamed into the local cache.
The File Type Association container allows you to view, change, and remove a file type association. For more details, see our discussion of the File Type Association in the previous section.
The Desktop Configuration container allows you to specify, change, and manually refresh the application server settings you specified during installation. Here, you can also select whether the client refresh should happen at the time of user logon (this is the default selection) and the length of the auto refresh interval.

Wrapping Up
Application virtualization with Microsoft SoftGrid offers a compelling way to improve system reliability and simplify management. While it involves a number of parts working together, the architecture actually fits seamlessly into the IT infrastructure.
Microsoft SoftGrid for Desktops is available to Software Assurance customers as part of the Microsoft Desktop Optimization Pack. For more information, see windowsvista.com/optimizeddesktop. Microsoft SoftGrid for Terminal Services is available as a standalone client access license to enterprise customers under Microsoft Volume Licensing agreements. To download a trial version, log in to your Volume Licensing account at https://licensing.microsoft.com and select Desktop Optimization Pack for SA under Product Downloads.

Ahmer Sabri is a Technical Specialist in the Financial Services Group at Microsoft. Ahmer can be reached at ahmers@microsoft.com.
Kedar Shah is a Technical Specialist in the Financial Services Group at Microsoft. Kedar can be reached at kedars@microsoft.com.


From The Editor Dynamic and Optimized
Joshua Trupin

In the months to come , you'll likely be hearing about two IT strategies from Microsoft: Dynamic Systems and Infrastructure Optimization. These two initiatives will help you do your IT-related job more successfully now as well as set you up to face the challenges of the future.
The Dynamic Systems Initiative defines a framework for tools and applications that combines four key areas of technical innovation to help guide tomorrow's IT approaches. To achieve a dynamic environment, your infrastructure and software should be unified and virtualized, process-led and model-driven, service-enabled, and user-focused.
Creating a dynamic IT environment is not, however, limited to products from Microsoft. Your company can put more of its investments into creating business advantages with IT, rather than simply trying to manage its burgeoning complexity. By using Infrastructure Optimization models to look at where your business is headed over the next two years, you can both make the most of your current systems and plan for a more dynamic future.
Broadly speaking, a company's IT lifecycle exists in one of four stages. Basic: "We fight fires." Standardized: "We're gaining control." Rationalized: "We enable business." Dynamic: "We're a strategic asset." These stages are each discussed in detail at microsoft.com/io. You can use the guidance there to analyze your infrastructure and plan for its future. By applying the Dynamic Systems concepts, you can turn your IT organization into a key business asset.
Once your organization reaches the Dynamic stage, your IT systems will be self-managing, strategic business assets. Aaaaah, IT Nirvana. The best way to progress from stage to stage in your quest for Dynamic IT is through the System Center family of IT management solutions. System Center provides configuration tools, deployment apps, an operations manager, and much more—it encompasses the full IT lifecycle of planning, deployment, and maintenance.
And, of course, TechNet Magazine can help you get a leg up. This issue focuses on the System Center suite of solutions. Starting with broad overviews of two key components: System Center Configuration Manager 2007 and System Center Operations Manager 2007, we also look at deployment and operations, and even how to manage branch offices successfully.
How does your infrastructure measure up? Come visit our blog at blogs.technet.com/tnmag and tell us where you think Dynamic IT will lead you. —Joshua Trupin

Joshua Trupin


Toolbox New Products for IT Pros
Greg Steen

Manage Boot Configuration Data
VistaBootPRO
www.vistabootpro.org
Every IT pro I know has at least one or two multi-boot machines. Today, those systems usually include an instance of Windows Vista® or Windows Server® 2008, formerly code-named "Longhorn." If you are running a multi-boot system with one of these operating systems, you might want to take a look at VistaBootPRO from PROnetworks.
As you probably know, starting with Windows Vista and moving forward, Microsoft has changed the way boot configuration is managed. Instead of using a readable text file like Boot.ini, you now get the Boot Configuration Data (BCD) store. This provides a more secure and firmware-independent approach to managing boot environment details. There are three basic ways you can look at and modify your BCD. The first is to use MSConfig, which gives you basic access to read, modify, and re-order entries in the BCD. System administrators are likely most familiar with the second option, which is to use the command-line tool BCDEdit. With this tool, you can create a new BCD store, modify existing stores, and import or export stores for archiving and reuse. The third option is to manage the BCD programmatically using its Windows® Management Instrumentation (WMI) API.
All three of these methods get the job done, but none of them are particularly user-friendly. This is where VistaBootPRO comes in, with a friendlier GUI for modifying the boot configuration on your machine running Windows Vista. The tool lets you easily rename OS entries, add new entries, change the boot drive, and configure timeout options with just a click or two. In addition, VistaBootPRO lets you select an OS entry and set startup parameters, such as limiting the CPUs available to the OS, enabling or disabling Data Execution Prevention for Windows Vista or Windows Server 2008 entries, reducing the physical memory available to the OS and running the boot process in debug mode.
Before you make any changes to your BCD using this tool, you should back up your current store in case something goes awry. The application will warn you if you haven't made a backup, and it provides an easy way to export the current configuration. And, of course, VistaBootPRO lets you restore backed up configurations.
All in all, VistaBootPRO is a simple-to-use, well-featured application for managing your BCD. Best of all, it's free.

Price: Free.
Figure vistabootpro

Monitor Services and Devices
NetGong
netgong.tsarfin.com
Ahhh, monitoring tools—I can't seem to get enough of them. If you're in the market for a new network service and device monitor, or you just like to dabble with monitoring utilities, check out NetGong.
The application runs in your system tray, launching when you start Windows. A simple right-click on the icon provides an option to quickly start or stop monitoring. Double-clicking the icon brings up the main configuration UI where you can set up, review, and see events for your monitored hosts.
Setting up a host monitor is easy. Just enter the host, the TCP port you want to monitor, the interval at which the tests should be conducted, and the alert type you want to receive. You can also add a meaningful description and modify the default Internet Control Message Protocol (ICMP) settings, such as the timeout, packet size, and number of retries. By default, NetGong requires the monitored host to respond to ICMP requests, but you can also override that option with a checkbox for silent hosts that don't accept ICMP requests on your network.
The application gives you four alert categories: sounds, e-mail, messages, and file. For sounds, you can specify the WAV file you want to use. For messages, you can define a text message, force it to be the top-most window, and choose whether to close the window automatically or manually. E-mail alerts let you specify an SMTP server and the details of the message to be sent. And the file alert option allows you to run an executable (or batch file) with configurable parameters, window mode, and start up directory. For each of the alert types, you can configure a schedule that defines when to send the first alert, the maximum number of alerts to send, and the failure interval (number of failures) between alerts. You can also choose to be notified upon recovery of the service.
NetGong also keeps log files of the results. You can choose to log events to an event log, text file, or dynamically created HTML page. The app lets you view monitoring results on pages served through its built-in Web server listening on a user-specified port. And you can send a query string parameter with a refresh interval to have the Web page refresh with the latest monitoring event details.

Price: $79.95 direct per machine (corporate license), $59.95 direct per machine (academic license), $39.95 direct per machine (home license).
Figure steen.toolbox.netgong

Book Review
Windows PowerShell: TFM
www.sapienpress.com
Sure, you've already heard of Windows PowerShell™. Everybody seems to be talking about it. TechNet Magazine even has a column dedicated to it (which happens to be written by one of the authors of this book). But have you really delved into it?
Windows PowerShell can be an extremely effective automation and productivity tool once you get a handle on how to use it. Whether you are just getting into scripting or you are a VBScript ninja looking to expand into this new admin-focused scripting language and command-line toolset, Windows PowerShell: TFM, by Don Jones and Jeffery Hicks, is a great place to start. This very approachable book is geared toward the system administrator and does a good job of focusing on what will be useful for most administrators.
The first section of the book introduces the Windows PowerShell environment, covering the parameters that all of the cmdlets have in common and the basics of the syntax and semantics of the scripting language. The concepts of redirection, execution pipelining, functions, variables, and running multiple shells are also presented. Since Windows PowerShell is based on the Microsoft® .NET Framework, it inherits the benefits of managed code. (Note that Windows PowerShell requires the .NET Framework 2.0 or later.) So the book also provides some insight into the essentials of the Framework, from the security context within which scripts run to the concepts of reflection, assemblies, and classes.
After explaining how to tie Windows PowerShell into Windows Management Instrumentation (WMI), the authors discuss the Windows PowerShell scripting language structure in detail, providing examples that help you understand the function of objects and their associated properties and methods. You'll also see how to use the different types of operators, from basic arithmetic operators to bitwise comparison operators, as well as powerful regular expressions to parse strings for items like IP addresses and domain controller names. This is a particularly useful foundation for anyone serious about mastering Windows PowerShell.
The chapters on managing Windows and database scripting demonstrate some of the hardcore capabilities Windows PowerShell has to offer. You'll see how to work with event logs, processes, the registry, the file system, and directory services as well how to connect to and execute queries on databases.
Other sections cover outputting and formatting data, making your scripts modular, error handling, and debugging. The authors even offer a suggested set of best practices for Windows PowerShell scripting that includes naming conventions, commenting your code, and using indentation to make your code more readable.
You'll certainly want to keep the book handy for easy access to the material in the appendices, one of which is a reference for all of the 133 Windows PowerShell cmdlets, while the other is a reference for the most commonly used types (and the methods and properties associated with these types). Besides providing a quick look-up of how to use a specific cmdlet, these references give you an instant preview of the breadth of the capabilities Windows PowerShell offers.

Price: $49.99 list.

Test Your Cables
SMARTest Compact Network Cable Tester
www.hobbes-usa.com
Cables, cables, everywhere! As IT pros, most of us are surrounded by CAT5 cable. Lots of CAT5 cable: hundreds of strands, spanning thousands of feet. And if you are responsible for these cables, a good, easy-to-carry cable tester isn't just handy, it's essential. For that reason, you might want to take a look at the SMARTest Compact Network Cable Tester from Hobbes.
The SMARTest device is a pen-style cable tester. It's compatible with CAT 3, 4, 5, 5e, and 6 network cables and can help you detect common cable wiring issues. Specifically, you can check for open, shorted, reversed, mis-wires, split pairs, and grounding issues within a cable strand.
The device runs on four small watch-style batteries, so your cables don't need to be connected to test; nor should you connect SMARTest to an active network connection. To test a cable, you simply have to plug one end of the strand into the Main unit and the other into the detachable Remote unit. The SMARTest unit has an interface with both RJ45 socket and plug (female and male) connectors, so you can test any kind of cable setup. You can even use the SMARTest device to check the wiring or your patch panels and wall sockets.
Another cool feature is that the device has built-in tone generation so you can send an audio signal through the cable you're testing. You can then pick up the signal with a compatible signal probe, such as the Cable Tracer Probe also available from Hobbes.
The SMARTest with tone-generation costs around $80-$90, depending on the retailer. There is also an optional F connector adapter for testing coax cable.

Price: $99.99 list.
Figure steen.toolbox.smartest

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


SQL Q&A Finding Locks, Large Queries, I/O Statistics, and More
Edited by Nancy Michell

Download the code for this article: SQLQandA2007_08.exe (151KB)

Q I need to view the names of the objects in all databases that have locks on them. How can I do this?

A In SQL Server™ 2000, you can query the syslocks system table in Master or run sp_lock to get current lock information, like so:
SELECT * FROM master..syslocks
EXEC sp_lock
However, let's say you want to translate the actual object NAMES from the ObjID from the OUTPUT of the sp_lock stored procedure (or from the id column in master..syslocks).
In SQL Server 2005 SP1 and earlier, the OBJECT_NAME function only let you pass one parameter: object_id. So, in order to properly get the object name, you had to be working in the CURRENT database before running OBJECT_NAME. This made monitoring the current locks difficult, as you had to go to the effort of writing custom code to loop through each database to get the correct OBJECT_NAME.
USE DBNAME
SELECT OBJECT_NAME(object_id)
SQL Server 2005 SP2 improves on this by adding a second parameter, database_id. This new parameter allows you to query object names regardless of which CURRENT database you're connected to.
OBJECT_NAME ( object_id [, database_id ] )
Now you can query sys.dm_tran_locks and retrieve the object name for each database, like this:
SELECT
DB_NAME(resource_database_id),
OBJECT_NAME(resource_associated_entity_id, resource_database_id)
FROM sys.dm_tran_locks
WHERE resource_type='OBJECT'
Note, however, that this only works on SQL Server 2005 SP2 and later. If you run this in an earlier version of SQL Server 2005, you'll get this error:
Msg 174, Level 15, State 1, Line 1
The object_name function requires 1 argument(s).
Another example, shown in Figure 1, joins sys.dm_exec_sessions to get information about the service process IDs (SPIDS) involved in the locks. For more information, see SQL Server Books Online at technet.microsoft.com/library/ms130214(sql.90).aspx.
Figure 1 Finding server process IDs
SELECT
DB_NAME(resource_database_id) as DBName,
OBJECT_NAME(resource_associated_entity_id, resource_database_id) AS ObjectName,
request_mode,
request_type,
request_session_id,
es.host_name,
es.login_name,
es.login_time
FROM
sys.dm_tran_locks tl
INNER JOIN sys.dm_exec_sessions es
ON tl.request_session_id=es.session_id
WHERE resource_type='OBJECT'

Q I have a large, dynamic SQL query that seems to sometimes exceed the length of NVARCHAR(max). Is there any way around this that still permits me to execute one big string?

A If you're exceeding the length of NVARCHAR(max), you've got a 2GB query! You probably need to convert all of the strings you concatenate to NVARCHAR(max) as well. However, a more convenient workaround, which also has the advantage of being effective in versions of SQL Server before SQL Server 2005, is to concatenate a number of smaller strings together. Here's an example:
DECLARE @q1 NVARCHAR(4000), @q2 NVARCHAR(4000), @q3 NVARCHAR(4000)
SET @q1 = 'SELECT...'
SET @q2 = 'FROM...'
SET @q3 = 'WHERE...'
EXEC (@q1 + @q2 + @q3)
TIP: Using the OUTPUT Clause
You can now audit changes you make using Data Manipulation Language (DML) statements without even using triggers. SQL Server 2005 introduced an OUTPUT clause as a part of DML statements that can help you in tracking changes made during any DML operation. The OUTPUT clause can save the resultset in a table or table variable.
The functionality is similar to what triggers had with INSERTED and DELETED tables, which used to access the rows that have been modified during the DML operation. To see how this works, let's change the address from the address table to the reverse of the original value, as shown in the figure below. You may also use the logic shown in this code to track any changes you make to the data and store it in a table.
The output from the query will look like this:
Original Value:'1234 One Microsoft Way, Redmond, Wa.' has been changed to: '.aW,dnomdeR
,yaW tfosorciM enO 4321'

Changing an address
--Create the address table
Create Table Address (ProductID Int, SupplierID Int, Address Varchar(255))

--Insert data
Insert into Address Values (234,567,'1234 One Microsoft Way, Redmond, Wa.')

--Declare a table variable
Declare @Recordchanges table (change Varchar(255))

--Update the address
Update Supplier.Address
Set Address=reverse(address)

--Record the updates into the table variable
OUTPUT 'Original Value:' + DELETED.Address+' has been changed to: '+ INSERTED.Address+''
into @RecordChanges

--Query the changes from table variable
Select * from @RecordChanges

Q I have a mission-critical SQL Server 2005 cluster installation on Windows Server® 2003. The Microsoft® Distributed Transaction Coordinator (MS DTC) has been "clustered" on the same group with the Cluster Quorum, but is using a dedicated disk resource (MS DTC is sharing the same network name and IP address of the Quorum Cluster Group). I want to align this configuration with Microsoft best practices. Therefore, I need advice on moving the MS DTC to a dedicated cluster group. Is it enough to remove the MS DTC services using the Cluster Admin Tool and recreate it on a dedicated group?

A Since you already have a dedicated disk resource for MS DTC, you should be able to simply remove the resource and create it in a new group. You need to create a new network name and virtual IP address in the new group too.
Alternatively, you could create the new network name and IP address in the cluster group and change the dependencies to the new resources. You can then drag MS DTC to a new group and it will take the dedicated disk and new resources with it.

Q I need to be able to view I/O statistics on the physical database files in a database. What should I use?

A The system function fn_virtualfilestats, available in both SQL Server 2000 and SQL Server 2005, or sys.dm_io_virtual_file_stats (in SQL Server 2005 only) allow you to do exactly what you're looking for. The function returns statistical information gathered since the last time the instance of SQL Server was started. Sample results are shown in Figure 2.
Figure 2 Viewing I/O statistics on a database

DbId | FileId | TimeStamp | NumberReads | NumberWrites | BytesRead | BytesWritten | IoStallMS
20 | 1 | 250765718 | 381 | 0 | 3350528 | 0 | 951
20 | 2 | 250765718 | 12 | 8 | 409600 | 491520 | 0
20 | 3 | 250765718 | 5 | 0 | 40960 | 0 | 16
Understanding the I/O impact on the underlying data files can help you better plan such things as the physical placement of files and file groups on data volumes, detecting possible I/O bottlenecks, performing file-level database maintenance, and other such tasks. This function is particularly useful for examining the I/O impact for large databases, where you may have multiple files and file groups.
The query for displaying file I/O info for SQL Server 2000 looks like this:
SELECT *
FROM ::fn_virtualfilestats(default,default)
GO
To view a specific databaseID, pass the ID for the database, like so:
SELECT *
FROM ::fn_virtualfilestats(7,default)
GO
Here's the SQL Server 2005 code that shows file statistics for all databases on the server:
SELECT *
FROM ::fn_virtualfilestats(NULL,NULL)
GO
The following query returns file statistics for only the current database:
SELECT *
FROM ::fn_virtualfilestats(NULL,NULL)
WHERE DBID=db_id()
GO
For SQL Server 2005, there is also a new system function called sys.dm_io_virtual_file_stats, which is intended to eventually replace the legacy function fn_virtualfilestats:
sys.dm_io_virtual_file_stats(
{ database_id | NULL },
{ file_id | NULL }
)
Here's how to use it:
SELECT * FROM sys.dm_io_virtual_file_stats(NULL,NULL)
If you want to generate a more readable report that shows the actual database names and file names from the output, you can use the code in the accompanying download on either SQL Server 2000 or SQL Server 2005. The code is available from the TechNet Magazine Web site.

Q I need an easy way to see if a delete transaction has fired a trigger. Do you have any ideas for how I can get this information?

A When dealing with triggers that handle delete, insert, and update actions, people commonly use a number of different techniques for determining whether a trigger was fired by a delete transaction. A popular method is to compare the counts of the inserted and deleted virtual tables to see if they match. However, there is a simpler method: you can use the Columns_Updated function instead.
That's because when a trigger is fired by a delete transaction, Columns_Updated always returns the varbinary value 0x. The following check will verify that the trigger was fired by a delete:
IF Columns_Updated() = 0x
TIP: Initializing Data and Log Files
Did you know that data and log files are initialized to overwrite any existing data left on the disk from previously deleted files? Data and log files are first initialized by filling the files with zeros when you create a database; add files, log or data, to an existing database; increase the size of an existing file (including autogrow operations); or restore a database or file group. File initialization causes these operations to take longer. However, when data is written to the files for the first time, the operating system does not have to fill the files with zeros.
In SQL Server 2005, data files can be initialized instantaneously. This capability allows for fast execution of the previously mentioned file operations. Instant file initialization reclaims used disk space without filling that space with zeros. Instead, disk content is overwritten as new data is written to the files. Log files cannot be initialized instantaneously. Instant file initialization is available only on Windows XP Professional and Windows Server 2003 or later versions.
Because the deleted disk content is overwritten only as new data is written to the files, the deleted content might be accessed by an unauthorized principal. While the database file is attached to the instance of SQL Server, this information disclosure threat is reduced by the discretionary access control list (DACL) on the file. This DACL allows file access only to the SQL Server service account and the local administrator. However, when the file is detached, it may be accessed by a user or service that does not have SE_MANAGE_VOLUME_NAME. A similar threat exists when the database is backed up. The deleted content can become available to an unauthorized user or service if the backup file is not protected with an appropriate DACL.
If the potential for disclosing deleted content is a concern, you should always make sure that any detached data files and backup files have restrictive DACLs. Also, disable instant file initialization for the instance of SQL Server by revoking SE_MANAGE_VOLUME_NAME from the SQL Server service account.

Thanks to the following Microsoft IT pros for their technical expertise: Christian Bolton, Dan Carollo, Robert Davis, Jorge Guzman, Saleem Hakani, Ward Pond, Kalyan Yella, and Paolo Zavatarelli.


Utility Spotlight BGInfo
Lance Whitney

Download the code for this article: BgInfo v4.10 (274KB)

You're trying to resolve a problem with a user's PC and need info about the computer—name, IP address, gateway, memory, free disk space, and so on. Gathering all that data usually forces you to scour multiple sources or ask the user a barrage of questions. Wouldn't it be handy if everything you needed to know about a PC was in one single place? It can be, thanks to a free tool from Sysinternals called BGInfo.
Written by Bryce Cogswell, BGInfo (short for Background Information) queries a Windows® workstation or server for key data— everything from network-related stats (IP address, router, domain name, MAC address) to hardware and software info (computer name, memory, OS version, and Service Pack level). The program then displays all that data on the desktop as part of the wallpaper, thus making the information clearly visible without being obtrusive (see Figure 1).
Figure 1 BGInfo displays system information on the desktop
Figure 1 BGInfo displays system information on the desktop
To run BGInfo, just double-click the bginfo.exe file—no installation is required. The configuration screen appears for you to review and select the data fields to display. By default, BGInfo reveals 24 separate pieces of information. You can remove any field you don't want visible, and then add it back later if you change your mind. You can also easily pop in additional fields. BGInfo will display any environment variable, most registry values, and the output from VBScript and Windows Management Instrumentation (WMI) queries. The WMI interface provides a simple way to build queries by selecting values from a dropdown menu. BGInfo can also tap into certain files to display their version information, time stamp, and contents.
The display is highly customizable. You can change various attributes of the text—alignment, font, point size, and color. Furthermore, you can juggle the position of the data around different parts of the desktop and specify the maximum width of its display area in inches. Finally, BGInfo lets you add graphics alongside the text data, so you can pop in an image, such as your corporate logo. Conversely, if you'd rather not display all this information on the desktop, just set up BGInfo as an icon in the system tray instead. Click on it, and the full display appears.
After you've made your formatting choices, you can click the Preview button to check the display before you commit, then apply it if it looks good. You can run BGInfo manually on any PC whenever you need it or keep it updated automatically. To refresh the data on a regular basis, add the BGInfo.exe file to the startup folder or set it up as a Scheduled Task. After you've customized BGInfo on one computer, you'll probably want to use the same settings on other PCs. Just save your settings as a BGI file, and then load them onto other computers running the program.
Though you can run BGInfo on one PC at a time, you might want to trigger it on multiple network clients. You can insert the bginfo.exe file into a login script; the program provides several command-line options to control its behavior. The data collected by BGInfo can also be exported to an external file—a text file, Excel® spreadsheet, Access™ database, or a SQL database, so that you have a handy resource of all your network PC stats.
The Help information included with BGInfo is thorough and easy to follow. It even offers tips on how to write simple VBScript and WMI queries whose output can be captured by BGInfo. The program runs on all versions of Windows from Windows 95 to Windows Vista®. Learn more about BGInfo and download the tool from microsoft.com/technet/sysinternals/Miscellaneous/BgInfo.mspx.

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 IPv6 Autoconfiguration in Windows Vista
Joseph Davies

IPv6 is about more than extending the address space from 32 bits in IPv4 to 128 bits. IPv6 hosts can also automatically configure themselves, even without the use of an address configuration protocol such as DHCP for IPv6 (DHCPv6).
Based on RFC 2462, all IPv6 nodes automatically configure a link-local address for each interface. An IPv6 host also uses router discovery—an exchange of Router Solicitation and Router Advertisement messages—to determine additional addresses and configuration settings. Included in the Router Advertisement message sent by the router are the Managed Address Configuration (M) and Other Stateful Configuration (O) flags, which indicate whether the host should use DHCPv6 for additional addresses or configuration settings.

Types of IPv6 Autoconfiguration
Beyond the link-local address, hosts can also use stateless autoconfiguration to configure addresses and other settings based on the receipt of Router Advertisement messages. These messages can include one or more Prefix Information options, which the receiving host can use to derive stateless addresses.
Likewise, stateful autoconfiguration is the configuration of addresses and other settings based on the use of DHCPv6 to obtain addresses. A host uses stateful autoconfiguration when it receives a Router Advertisement message with the M flag set to 1.
Finally, a host can also use both stateless and stateful autoconfiguration, which is a combination of addresses included in the router advertisement and obtained from a DHCPv6 server.

Autoconfigured Address States
When an autoconfigured address is in the tentative state, it is in the process of being verified as unique through duplicate address detection (DAD). See the "RFC 2462 IPv6 Autoconfiguration Process" sidebar for information about how DAD is performed. An address in the valid state has been verified as unique and can be used for sending and receiving unicast traffic. The valid state includes both preferred and deprecated states. In the preferred state, the address can be used for unlimited communication. In the deprecated state, the address should not be used for new communication; however, existing communications using the address can continue.
RFC 2462 IPv6 Autoconfiguration Process
The following steps describe the autoconfiguration process for an IPv6 host as defined in RFC 2462:
  • Derive a tentative link-local address with an Extended Unique Identifier (EUI)-64 interface identifier (ID).
  • Perform DAD on the tentative link-local address by sending a Neighbor Solicitation message with the Target Address in the message set to the tentative link-local address.
  • If a Neighbor Advertisement message sent in response to the Neighbor Solicitation message is received, the tentative link-local address is a duplicate address. Stop address autoconfiguration. At this point, manual configuration must be performed on the host.
  • If no Neighbor Advertisement message (sent in response to the Neighbor Solicitation message) is received, the tentative link-local address is unique. Change the state of the address on the interface to preferred.
  • Send a Router Solicitation message.
  • If no Router Advertisement messages are received, use DHCPv6 to obtain addresses and other configuration parameters.
  • If a Router Advertisement message is received, configure tentative addresses for the included prefixes and perform duplicate address detection for each tentative address. If the addresses are unique, change the state of the addresses on the interface to preferred.
  • If the M flag in the Router Advertisement message is set to 1, use DHCPv6 to obtain additional stateful addresses.
  • If the M flag in the Router Advertisement message is set to 0 and the O flag is set to 1, use DHCPv6 to obtain additional configuration parameters.

An advertising router or DHCPv6 server specifies the valid and preferred lifetimes for an address prefix. An address enters the deprecated state after the preferred lifetime of the address has been exceeded. The preferred lifetime of an autoconfigured address is refreshed by receiving router advertisements or by renewing the DHCPv6 address configuration. Figure 1 shows the states of an autoconfigured address and their relationship to the preferred and valid lifetimes.
Figure 1 The states of an autoconfigured address
Figure 1 The states of an autoconfigured address
With the exception of autoconfiguration for link-local addresses, address autoconfiguration is specified only for IPv6 hosts. IPv6 routers must obtain address and configuration parameters through another means, such as manual configuration.
The "RFC 2462 IPv6 Autoconfiguration Process" sidebar describes the detailed IPv6 address autoconfiguration process for hosts that is defined in RFC 2462.

IPv6 Autoconfiguration Behavior for Windows Vista
Computers running Windows Vista® or Windows Server® 2008 by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses, rather than EUI-64-based interface IDs. A public IPv6 address is a global address that is registered in DNS and is typically used by server applications for incoming connections, such as a Web server. You can disable this default behavior with the command:
netsh interface ipv6 set global randomizeidentifiers=disabled
When disabled, IPv6 uses EUI-64-based interface IDs.
With a randomly derived interface ID, the chance of duplicating the link-local address is very small. Therefore, computers running Windows Vista or Windows Server 2008 do not wait for DAD to complete before sending Router Solicitation messages using their derived link-local addresses. This is known as optimistic DAD; router discovery and DAD are performed in parallel to save time during the interface initialization process.
Computers running Windows Vista or Windows Server 2008 do not attempt stateful address autoconfiguration with DHCPv6 if no router advertisements are received.
Windows Vista IPv6 Autoconfiguration Process
The following steps describe the autoconfiguration process for an IPv6 host running Windows Vista:
  • Derive a tentative link-local address for the LAN interface with a randomly derived interface ID (the default setting).
  • Perform DAD for the derived link-local address of the LAN interface (send a Neighbor Solicitation message with the Target Address field that is set to the tentative link-local address).
  • Perform router discovery on the LAN interface (send a Router Solicitation message from the tentative link-local address).
  • If a Neighbor Advertisement message sent in response to the Neighbor Solicitation message sent in Step 2 is received, mark the link-local address as a duplicate.
  • If no Neighbor Advertisement messages in response to the Neighbor Solicitation message are received, change the state of the link-local address on the LAN interface to preferred.
  • If no router advertisements are received, stop IPv6 address autoconfiguration on the LAN interface. Go to Step 13.
  • If a router advertisement is received, create tentative public addresses corresponding to the global or unique local address prefixes in the message based on the random interface ID derived in Step 1, and perform DAD.
  • Create tentative temporary addresses corresponding to the global or unique local address prefixes in the message using new randomly derived random interface IDs, and perform DAD.
  • For each new address, if no Neighbor Advertisement messages in response to the Neighbor Solicitation message are received, change the state of the address on the LAN interface to preferred.
  • If the router advertisement has both the M and O flags set to 0, stop IPv6 autoconfiguration on the LAN interface. Go to Step 13.
  • If the router advertisement has the M flag set to 1, use DHCPv6 to obtain both stateful IPv6 addresses and additional configuration settings.
  • If the router advertisement has the M flag set to 0 and the O flag set to 1, use DHCPv6 to obtain additional configuration settings.
  • Derive link-local ISATAP addresses based on the IPv4 addresses of the LAN interface and assign them to the ISATAP tunneling interface.
  • Attempt to resolve the host name "ISATAP" to an IPv4 address.
  • If the host name "ISATAP" cannot be resolved, stop IPv6 configuration.
  • If the host name "ISATAP" is resolved to an IPv4 address, send an IPv4-encapsulated router solicitation to the ISATAP router.
  • If a router advertisement from the ISATAP router is received, create additional ISATAP addresses corresponding to the advertised global or unique local address prefixes and assign them to the ISATAP tunneling interface.

Autoconfigured Addresses for Windows Vista
As previously described, the IPv6 protocol for Windows Vista and Windows Server 2008 automatically configures link-local addresses using randomly derived interface identifiers for all LAN interfaces.
If a received router advertisement includes a global or unique local prefix, IPv6 configures global or unique local addresses using the same randomly derived interface ID and assigns them to the LAN interface that received the router advertisement. Such addresses are known as public addresses.
IPv6 in Windows Vista by default also configures temporary global or unique local addresses using different randomly derived interface IDs and assigns them to the LAN interface that received the router advertisement. Temporary addresses are defined in RFC 3041 and are used to provide a level of anonymity for client-initiated communications. In contrast, IPv6 in Windows Server 2008 does not create temporary addresses by default. You can enable temporary addresses by using the command:
netsh interface ipv6 set privacy=enabled
If the M flag is set to 1 in received Router Advertisement messages, IPv6 uses DHCPv6 to configure additional global or unique local addresses for the LAN interface.
IPv6 also creates an Intra-site Automatic Tunnel Addressing Protocol (ISATAP) tunneling interface for each LAN interface on the host. RFC 4214 describes the ISATAP IPv6 transition technology. With ISATAP, IPv6 hosts can communicate over an IPv4-only intranet by encapsulating an IPv6 packet with an IPv4 header. For more information about ISATAP, see the "IPv6 Transition Technologies".
For each ISATAP tunneling interface, IPv6 configures link-local ISATAP addresses for the IPv4 addresses that are assigned to its corresponding LAN interface. For example, for the ISATAP tunneling interface that corresponds to a LAN interface that is assigned the IPv4 address 192.168.91.211, IPv6 assigns the link-local ISATAP address of FE80::0:5EFE:192.168.91.211.
ISATAP hosts also perform ISATAP router discovery. To receive a router advertisement from an ISATAP router, IPv6 by default must be able to resolve the host name "ISATAP" to an IPv4 address. This is done through Windows-based host name resolution methods such as DNS. After the name is resolved, the host sends an IPv4-encapsulated router solicitation to the ISATAP router. The ISATAP router then sends an IPv4-encapsulated router advertisement to the host. Based on the contents of the received router advertisement, IPv6 also configures global or unique local ISATAP addresses on the ISATAP tunneling interfaces.
Windows Vista also supports the 6to4 and Teredo IPv6 transition technologies. To simplify matters, however, I will not discuss the autoconfiguration of the 6to4 and Teredo tunneling interfaces of a Windows Vista-based IPv6 host here.
The "Windows Vista IPv6 Autoconfiguration Process" sidebar describes the address autoconfiguration process for a Windows Vista-based IPv6 host with a single LAN interface that is configured with global or unique local address prefixes on either its LAN or ISATAP tunneling interfaces.
For example, a host running Windows Vista has a single LAN interface. The host receives a router advertisement on its LAN interface with both the M and O flags set to 0 and contains the prefixes 2001:DB8:D005:F282::/64 and FD4A:3A9:27A1:F282::/64. It does not receive a Router Advertisement message from an ISATAP router. Figure 2 is an example of the output resulting from the command
Figure 2 Output from netsh interface ipv6 show address
Interface 1: Loopback Pseudo-Interface 1

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other   Preferred  infinite infinite ::1

Interface 8: Local Area Connection

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Preferred 6d19h37m21s 6d19h37m21s 2001:db8:d005:f282:ed46:5dd4:5439:2e1c
Public  Preferred  infinite infinite 2001:db8:d005:f282:3521:12fa:2c44:87d1
Temporary Preferred 6d19h37m21s 6d19h37m21s fd4a:3a9:27a1:f282:ed46:5dd4:5439:2e1c
Public   Preferred  infinite infinite fd4a:3a9:27a1:f282:3521:12fa:2c44:87d1
Other   Preferred  infinite infinite fe80::3521:12fa:2c44:87d1%8

Interface 17: Local Area Connection* 9

Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other   Preferred  infinite infinite fe80::5efe:10.47.181.92%17

netsh interface ipv6 show address
for this example host. In the figure, the ISATAP tunneling interface corresponding to the LAN interface named Local Area Connection is named Local Area Connection* 9.
In addition to autoconfigured addresses, the IPv6 protocol for Windows Server 2008 and Windows Vista also supports manual configuration of static IPv6 addresses through the use of the following command
netsh interface ipv6 add address
or through the Internet Protocol Version 6 (TCP/IPv6) component from the properties of a connection in the Network Connections folder.
Throughout this month's column, I have assumed you already had a general foundation in IPv6 addressing and protocol operation. If you need more information on this topic, I suggest you begin with the whitepaper "Introduction to IPv6," which can be found at microsoft.com/technet/ network/ipv6/introipv6.mspx.

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


Windows PowerShell The Power of Filtering
Don Jones

In last month's column, I discussed the power and flexibility of the Windows PowerShell pipeline, which lets you pass a set of data—or, more accurately, a stream of objects—from one cmdlet to another, further refining that set until it is exactly what you need it to be. In my discussion, I alluded to the fact that your own scripts,
not just cmdlets, can also take advantage of the pipeline. This month I want to discuss that topic in detail.
One of the most frequent things I do in Windows PowerShell™ is write scripts that act against multiple remote computers, usually through Windows® Management Instrumentation (WMI). As with any task that deals with remote computers, there's always the possibility that one or more of those computers won't be available when the script runs. Therefore, I need my scripts to be able to deal with that fact.
Of course, there are a number of ways in which I can give a script the ability to handle a WMI connection timeout, but I don't particularly like that approach because the timeout period itself is so long—about 30 seconds by default. This would cause my script to run much more slowly if it had to wait for numerous timeouts to occur. Instead, I want my script to perform a quick check to see if a given computer is actually online before trying to connect to it.

The Windows PowerShell Paradigm
In other scripting languages, such as VBScript, I would typically deal with one computer at a time. That is, I would retrieve a computer name—perhaps from a list of names stored in a text file—and ping the system to see if it's available. If it is available, I make the WMI connection and perform whatever other work I need to complete. This is a common scripting-style approach. In fact, I'd probably write all my code in a loop and then repeat that loop once for each computer that I need to connect to.
Windows PowerShell, however, is better suited to batch operations thanks to its basis in objects and its ability to work directly with groups or collections of objects. The paradigm in Windows PowerShell is not to work with single objects or pieces of data, but rather to work with entire groups, refining the group bit by bit until you've accomplished whatever you set out to do. For example, instead of retrieving one computer name at a time from my list, I'd read in the entire collection of names at once. And rather than pinging each computer in a loop, I'd write a single routine that accepted a collection of names, pinged them, and then output the ones that could be contacted. The next step in my process would be to make my WMI connection to the remaining names—the ones that could be reached via ping.
Windows PowerShell uses this exact approach for a number of tasks. For example, to get a list of running services, I can use something like this:
Get-Service | Where-Object { $_.Status –eq "Running" }
Figure 1 shows what the output looks like on my computer. Rather than checking each service one at a time, I retrieved all services using Get-Service, I piped those to Where-Object, and then I filtered out all those that were not running. That's more or less what I want to do with my script: get a list of computer names, filter out all the ones that are not pingable, and pass the list of pingable computers on to the next step.
Figure 1 Getting a list of pingable computers
Figure 1 Getting a list of pingable computers

Filtering Functions
Although I could write my own cmdlet to do this, I don't want to. Cmdlet authoring requires Visual Basic® or C# and a good amount of Microsoft® .NET Framework development expertise. More importantly, it requires more involvement than I want to invest in this task. Fortunately, Windows PowerShell lets me write a special kind of function, called a filter, that is perfectly capable of acting within the pipeline. The basic outline of a filtering function looks like this:
function <name> {
  BEGIN {
    #<code>
  }
  PROCESS {
    #<code>
  }
  END {
    #<code>
  }
}
As you can see, this function contains three independent script blocks, named BEGIN, PROCESS, and END. A filtering function—that is, a function designed to work within the pipeline to filter objects—can have any combination of these three script blocks, depending on what you want to do. They work as follows:
  • The BEGIN block executes once when your function is first called. You can use this to do setup work, if needed.
  • The PROCESS block executes once for each pipeline object passed into the function. The $_ variable represents the current pipeline input object. The PROCESS block is required in a filtering function.
  • The END block executes once after all pipeline objects have been processed. This can be used for any finalization work, if needed.
In my example, I want to produce a filtering function that will accept a collection of names as input objects, and then try to ping each one. Each one that can be pinged successfully will be output to the pipeline; systems that cannot be pinged will simply be dropped. Since the ping functionality doesn't require any special setup or finalization, I will just use the PROCESS script block. The code in Figure 2 provides the complete script.
Figure 2 Ping-Address and Restart-Computer
1  function Ping-Address {
2    PROCESS {
3      $ping = $false
4      $results = Get-WmiObject -query `
5      "SELECT * FROM Win32_PingStatus WHERE Address = '$_'"
6      foreach ($result in $results) {
7        if ($results.StatusCode -eq 0) {
8          $ping = $true
9        }
10      }
11      if ($ping -eq $true) {
12        Write-Output $_
13      }
14    }
15  }
16
17  function Restart-Computer {
18    PROCESS {
19      $computer = Get-WmiObject Win32_OperatingSystem -computer $_
20      $computer.Reboot()
21    }
22  }
23
24  Get-Content c:\computers.txt | Ping-Address | Restart-Computer
Note that I've defined two functions: Ping-Address and Restart-Computer. In Windows PowerShell, functions must be defined before they can be called. As a result, the first executable line of my script is line 24, which uses the Get-Content cmdlet to get a list of computer names from a file (one computer name per line). That list—a collection of String objects, technically—is piped to the Ping-Address function, which filters out any computers that can't be pinged. The results are piped to Restart-Computer, which uses WMI to remotely restart each computer that could be pinged.
The Ping-Address function implements a PROCESS script block, which means the function is expecting an input collection of objects. The PROCESS script block deals with that input automatically—I didn't have to define any input arguments to contain the input. I start the process on line 3 by setting the variable $ping to $false, which is a built-in Windows PowerShell variable that represents the Boolean value False.
I then use the local Win32_PingStatus WMI class to ping the specified computer. Notice on line 5 that the $_ variable, which represents the current pipeline object, is embedded inside the WMI query string. When a string is contained within double quotation marks, Windows PowerShell will always try to replace variables like $_ with their contents, so that you don't have to mess around with string concatenation. I'm using that capability on line 5.
Line 6 is a loop that checks my ping results. If any of those results come back successful (that is, with a StatusCode of zero), I set $ping equal to $true indicating success. On line 11, I check to see if $ping has been set to $true. If it has, I output the original input object to the default output stream. Windows PowerShell manages the default output stream automatically. If this function is at the end of the pipeline, then the output stream is turned into a text representation. If there are more commands in the pipeline, then the output stream's objects—in this case, string objects containing computer names—are passed into the next pipeline command.
The Restart-Computer function is somewhat simpler, but it also uses a PROCESS block so that it can easily participate in the pipeline. On line 19, the function connects to the named computer and retrieves its Win32_OperatingSystem WMI class. Line 20 executes the class's Reboot method to restart the remote computer.
Again, line 24 is where everything is actually executed. Of course, you should be very careful when running this script—it's designed to reboot every computer named in c:\computers.txt, which could definitely have disastrous results if you're not paying attention to the names in that text file!

Next Steps
This script isn't entirely bulletproof. I should also recognize the possibility of a WMI error not related to basic connectivity, such as a firewall blocking the necessary ports on the remote computer or a WMI security error. I can handle those problems by implementing a trap handler—which sounds like the perfect topic for a future column.
Also, this script is performing a fairly serious action—restarting a remote computer. Any script that attempts such a potentially hazardous action should implement two common Windows PowerShell parameters, –Confirm and –WhatIf. Explaining how to do this requires more space than I have here, but would be another great topic for a future column. In the meantime, check out the Windows PowerShell team blog; architect Jeffrey Snover covers this topic.
Even without getting into these features, you can get a good idea of what filtering functions can do. I'll refine this technique in subsequent columns, showing you how functions can provide a great way to modularize reusable code as well as enhance the functionality of your scripts in general.

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


Hey, Scripting Guy! Who Are You?
The Microsoft Scripting Guys

Download the code for this article: HeyScriptingGuy2007-082007_08.exe (152KB)

Not too long ago, the Scripting Guy who writes this column was watching a baseball game on TV. When the game was over, he decided to read a magazine but he left the TV on. As he finished the magazine he glanced up at the TV to discover he was watching an old World War II movie. In fact, he glanced up right about the time the actors were running through one of those tried-and-true scenarios: a young American GI is on sentry duty late at night when he hears a noise.
"Who are you?" barked the sentry.
"It's just me, Sgt. Smith," replied a voice.
"Sgt. Smith? There's no Sgt. Smith in this outfit."
"I'm new here; I just transferred in from A Company."
"Oh, really? From A Company? OK, Smith: who won the 1934 World Series?"
"The New York Yankees."
Wrong answer, "Smith"! (Who, as you might expect, was immediately arrested and thrown into the brig.) Any good American, any real American, knows that the St. Louis Cardinals—you know, Dizzy Dean and the Gas House Gang—won the 1934 World Series. Anyone who doesn't know that can only be one thing: a spy.
If anyone reading this month's column did not know that the St. Louis Cardinals won the 1934 World Series, well, all we can say is this: the jig is up; we know you're a spy. We hope you'll have the decency to turn yourself into the nearest office of the FBI. Or at least give them a call; when it comes to spies, the FBI will pick up and deliver.
As the Scripting Guy who writes this column watched, he realized that he'd have a pretty good chance at answering the sentry's second question: who won the 1966 World Series? The Baltimore Orioles. 1960 World Series? Pittsburgh Pirates. 1994 World Series? Ha! A trick question: there was no World Series in 1994.
However, in this day and age, he'd have extreme difficulty answering the first question: who are you? That's not as easy a question today as it might have been back in the 1940s. After all, with Active Directory® alone users can have any number of different identities, including:
  • Their first name (givenName).
  • Their last name (sn).
  • Their display name (displayName).
  • Their user principal name (userPrincipalName).
  • Their logon name (samAccountName).
  • Their distinguished name (distinguishedName).
All of these names identify the same person, and all are names that—depending on the circumstances—are important to know. And that's a problem. Most users know their first name and last name. But if you ask a user, "What's your distinguished name?" only a few will be able to reply, "Why, that's simple! I'm CN=Ken.Myer, OU=Finance, DC=fabrikam, DC=com. But all my friends call me CN=Ken.Myer."
As a system administrator or help desk person, you need to know these names as well. But how are you supposed to get this information? Well, one approach would be to suspend your users from meat hooks until they finally tell you their distinguished name. That would probably work, but most human resources departments discourage that sort of thing these days. So you might have to fall back on Plan B: a script. What kind of script? Well, for starters, how about the script in Figure 1?
Figure 1 Retrieving user attributes with ADSystemInfo
On Error Resume Next

Set objSysInfo = CreateObject("ADSystemInfo")
strUser = objSysInfo.UserName

Set objUser = GetObject("LDAP://" & strUser)
WScript.Echo "First Name: " & objUser.givenName
WScript.Echo "Last Name: " & objUser.sn
WScript.Echo "Display Name: " & objUser.displayName
WScript.Echo "User Principal Name: " & objUser.userPrincipalName
WScript.Echo "SAM Account Name: " & objUser.sAMAccountName
WScript.Echo "Distinguished Name: " & objUser.distinguishedName
Boy, if only Sgt. Smith had studied VBScript, huh? This script takes advantage of a little-known (but extremely useful) ADSI object named ADSystemInfo. This is a nifty little object that can return all sorts of information about the user currently logged on to the local computer, as well as about the local computer itself and the domain it belongs to. For example, have a look at Figure 2.
Figure 2 Display all sorts of domain information
On Error Resume Next

Set objSysInfo = CreateObject("ADSystemInfo")

Wscript.Echo "User name: " & objSysInfo.UserName
Wscript.Echo "Computer name: " & objSysInfo.ComputerName
Wscript.Echo "Site name: " & objSysInfo.SiteName
Wscript.Echo "Domain short name: " & objSysInfo.DomainShortName
Wscript.Echo "Domain DNS name: " & objSysInfo.DomainDNSName
Wscript.Echo "Forest DNS name: " & objSysInfo.ForestDNSName
Wscript.Echo "PDC role owner: " & objSysInfo.PDCRoleOwner
Wscript.Echo "Schema role owner: " & objSysInfo.SchemaRoleOwner
Wscript.Echo "Domain is in native mode: " & objSysInfo.IsNativeMode
For today, however, the only property we care about is the UserName property. What's so special about UserName? Well, it just happens to correspond to the distinguishedName property. And what's so special about distinguishedName? Well, distinguishedName is similar to a UNC file path: just like a UNC path enables us to uniquely identify a file somewhere on our network, distinguishedName (for example, CN=Ken.Myer, OU=Finance, DC=fabrikam, DC=com) enables us to uniquely identify a user account in Active Directory. In turn, that enables us to bind to that user account. And once we've made that connection, we can retrieve any information we want about a user—including who he is.
And that's exactly what we do in the first script we showed you. To begin with, we create an instance of the ADSystemInfo object and then assign the value of the UserName property to a variable named strUser:
Set objSysInfo = CreateObject("ADSystemInfo")
strUser = objSysInfo.UserName
Notice that we don't have to do much of anything here. For example, we don't have to specify the user name, the user domain, or the OU in which the user account resides; ADSystemInfo does all of that for us. Once we have the user's distinguishedName, we can then bind to his or her user account using this line of code:
Set objUser = GetObject("LDAP://" & strUser)
And, again, once we make the connection we can echo back the values of any of that account's Active Directory attributes. In our sample script, we've simply echoed back some of the user's name properties, but we could just as easily have retrieved the telephone number, office location, e-mail address, and so on.
That's great. All you have to do is hand out this script to all your users and they'll never again have to ask themselves, "Who am I?" (Or, if they do, they'll have a quick and easy way to figure it out.) But what about a related question: who are you? It's one thing to be able to identify the user logged on to the local computer. But how in the world can you determine who's logged on to a remote computer? As you might expect, that's a more difficult nut to crack.
And, sorry, we thought of that, too; unfortunately, you can't simply point our ADSystemInfo script towards a remote computer. The reason you can't is because the ADSystemInfo object can only be created locally. That leaves us with three possibilities:
  • Create a logon script that records the name of the logged-on user in some readily-accessible location.
  • Use the WMI class Win32_ComputerSystem and the UserName property.
  • Do something else.
The first option sounds pretty inviting. As you might have noticed, the ADSystemInfo object can return the distinguished name of the computer (the ComputerName property) as well as the distinguished name of the user. Consider, if you will, the sample script shown in Figure 3.
Figure 3 Logon script
On Error Resume Next

Set objSysInfo = CreateObject("ADSystemInfo")

strUser = objSysInfo.UserName
strComputer = objSysInfo.ComputerName

Set objUser = GetObject("LDAP://" & _
    strUser)
strUserName = objUser.displayName

Set objComputer = GetObject("LDAP://" & _
    strComputer)
objComputer.Description = strUserName
objComputer.SetInfo
What are we doing here? To begin with, we're grabbing the values of the UserName and the ComputerName properties and storing them in a pair of variables (strUser and strComputer). We then bind to the user account in Active Directory (just like we did before), retrieve the value of the displayName attribute (just like we did before), and store that value in a variable named strUserName. Pretty straightforward, right?
We are then able to use this line of code to connect to the Active Directory computer account:
Set objComputer = GetObject("LDAP://" & _
    strComputer)
After we make that connection, we assign the user's displayName to the computer's Description property and then call the SetInfo method to write that change to Active Directory:
objComputer.Description = strUserName
objComputer.SetInfo
Why do we do that? That's easy. Suppose Ken Myer logs on to the computer atl-ws-01. Guess what the value of atl-ws-01's Description property will be? You got it: Ken Myer, the very person currently logged on to the computer. Want to know who's logged on to atl-ws-01? Just check the Description property.
Now, in general, this scenario works pretty well—and works even better if you have a logoff script that clears the Description property each time the user logs off. It's not a foolproof solution, however. Why not? Well, logon scripts don't always run. For example, they typically don't run when people log on using RAS. Likewise, a logon script won't run if a user unplugs his or her network connection, logs on using cached credentials, and then plugs the computer back into the network. And suppose a user just turns off his computer without logging off. That means his logoff script will never run. In that case, Ken Myer will still allegedly be logged on to atl-ws-01 even though the machine isn't even running. In other words, this is a useful technique, but....
So what about option 2, using the Win32_ComputerSystem class? Again, this will often work, but the problem with the Win32_ComputerSystem class is that it doesn't always return the name of the logged-on user, especially for users who don't have administrator rights (and, especially, for computers running Windows® 2000). The script in Figure 4 will probably tell you who's logged on to a computer but, again, no guarantees.
Figure 4 Find out who is logged on with WMI
strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * From Win32_ComputerSystem")

For Each objItem in colItems
  Wscript.Echo objItem.UserName
Next
Incidentally, in this case the UserName property gets reported back in the format domain\username. In other words: FABRIKAM\kenmyer.
Oh, we almost forgot: even if a name does come back, that doesn't mean a user is actually logged on to the computer. When Ken Myer logs off atl-ws-01, his name is retained as the value of the UserName property and doesn't get replaced until someone new logs on.
Yuck.
But wait; that doesn't make us spies. Here's another approach we can take. If someone is logged on to a computer, the process Explorer.exe is bound to be running. In general, if Explorer.exe is not running, no one is logged on to the machine. And because Explorer.exe runs under the credentials of the logged-on user, we can almost always determine who's logged on to a computer by using a script similar to the one in Figure 5.
Figure 5 Determining the owner of Explorer.exe
strComputer = "atl-ws-01"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where Name = 'explorer.exe'")

If colItems.Count = 0 Then
  Wscript.Echo "No one is logged on to the computer."
Else
  For Each objProcess in colItems
    objProcess.GetOwner strUser, strDomain
    Wscript.Echo strDomain & "\" & strUser
  Next
End If
As you can see, in this case we are connecting to the WMI service on a remote machine (atl-ws-01, to be precise). We then use this line of code to retrieve a collection of all the instances of the Win32_Process class that have the name Explorer.exe:
Set colItems = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where " & _
  "Name = 'explorer.exe'")
Now what? Well, as we noted a moment ago, if Explorer.exe isn't running, the odds are pretty good that no one is logged on to the computer. How do we know whether Explorer.exe is running? One very simple way is to check the value of the collection's Count property. If the Count is equal to 0, we have an empty collection, and the only way we can have an empty collection is if there are no instances of Explorer.exe running on atl-ws-01. If that's the case, we echo back a message saying that no one is logged on to the computer:
Wscript.Echo "No one is logged on " & _
"to the computer."
If the Count isn't equal to 0, we set up a For Each loop to walk through the collection of processes that have the name Explorer.exe (and, yes, we're assuming that our collection will invariably have just one item in it). For each instance of Explorer.exe we then call the GetOwner method to determine whose account Explorer.exe is running under:
objProcess.GetOwner strUser, strDomain
Notice that we pass GetOwner a pair of out parameters: strUser and strDomain. Out parameters are simply variables that we name and supply to a method; the method will then assign values to those out parameters. In this case, strUser will be assigned the logon name of the logged-on user (kenmyer) and strDomain will be assigned the domain name for the logged-on user (FABRIKAM). All we have to do then is echo back the values of these two out parameters:
Wscript.Echo strDomain & "\" & strUser
You know what? That's pretty good. But we can go one step further. When we use the GetOwner method, we get back the logon name (the samAccountName) for the user logged on to the computer. That's good, but, as we noted earlier, users have all sorts of names besides their samAccountName. To truly answer the question "Who are you?" it would be nice to know, say, the user's displayName. But we can't determine these other names using GetOwner, can we?
No, we can't. However, we can take the samAccountName, plug it into an Active Directory search script, and then locate and bind to the user account with that logon name (a task made easier by the fact that samAccountNames must be unique within a domain). And once we bind to the user account we can echo back the values of any Active Directory property, including displayName.
We don't have time to explain the script in Figure 6 in detail; for more information about searching Active Directory, take a look at "Dude, Where's My Printer?". Suffice it to say that this script determines the logon name of the logged-on user, searches Active Directory for the user with that logon name (samAccountName), binds to the user account in question, and then echoes back the user's displayName. And all with one hand tied behind its back!
Figure 6 Binding to the logged on user
strComputer = "atl-ws-01"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where Name = 'explorer.exe'")

If colItems.Count = 0 Then
  Wscript.Echo "No one is logged on to the computer."
Else
  For Each objProcess in colItems
    objProcess.GetOwner strUser,strDomain
  Next
End If

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

objCommand.CommandText = "SELECT displayName FROM " & _
  "'LDAP://DC=wingroup,DC=fabrikam,DC=com' WHERE " & _
    "objectCategory='user' " & _
    "AND samAccountName = '" & strUser & "'"
Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF
  Wscript.Echo objRecordSet.Fields("displayName").Value
  objRecordSet.MoveNext
Loop
So what are our key takeaways from today? (That, by the way, is how Microsoft people talk. If you want to drive the Scripting Guy absolutely crazy, just walk up to him and say something like, "We need to triage the key takeaways, action items, and non-goals for all the stakeholders.") Well, for one thing, we now know how to get information about the user logged onto a computer—either the local machine or a remote computer. More important, we know what to do should we ever slip through a time warp and find ourselves back in World War II: make sure you have a copy of this column (so you can answer the question "Who are you?"), and—whatever you do—always carry around a list of World Series winners. After all, you never know when someone is going to ask you, "Who won the 1903 World Series?"
Note: The Boston Red Sox. This, by the way, was the very first World Series. Now, who do you suppose won the 1904 World Series? What do you mean, you don't know? Could you excuse us for a second; we need to go make a phone call....

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


Security Watch PKI Enhancements in Windows
John Morello

This column is based on a prerelease version of Windows Server 2008. All information herein is subject to change.

Windows has included strong, platform-wide support for public key infrastructure (PKI) since the release of Windows 2000. That release included the first native certificate-authority capability, introduced auto-enrollment, and provided support for smart-card authentication. In Windows XP and Windows Server 2003, those
capabilities were expanded to provide more flexible enrollment options with version 2 certificate templates and support for auto-enrollment of user certificates. In Windows Vista® and Windows Server® 2008 (formerly code-named "Longhorn"), the Windows® PKI platform takes the next step with support for advanced algorithms, real-time validity checking, and better manageability. This column discusses the new PKI features in Windows Vista and Windows Server 2008 and how they can be utilized by enterprises to lower costs and increase security.
The PKI improvements in Windows Vista and Windows Server 2008 are focused around four main pillars: cryptography, enrollment, manageability, and revocation. In addition to these feature-specific improvements, the Windows PKI platform also benefits from other operating system advances, such as the Roles Manager, that make it easier to create and deploy new certificate authorities (CAs). Additionally, many other parts of Windows are able to take advantage of improvements in the PKI platform, such as support in Windows Vista for using smart cards for the storage of Encrypting File System (EFS) keys.

Cryptography
The improvements to the cryptography pillar are twofold. First, with the introduction of Cryptography Next Generation (CNG), Windows now provides a pluggable, protocol-agnostic encryption capability that makes individual algorithms easier to develop and access programmatically. Second, CNG brings with it new support for the Suite B algorithms, which were introduced by the National Security Agency (NSA) in 2005.
CNG is a new core cryptography interface for Microsoft and is the recommended API for future Windows-based, crypto-aware applications. CNG provides a host of new developer-focused functionality, including easier discoverability and substitution of algorithms, replaceable random number generators, and a kernel mode cryptographic API. While offering these new capabilities, CNG is also fully backwards compatible with the set of algorithms provided in its predecessor, CryptoAPI 1.0. Currently, CNG is being evaluated for Federal Information Processing Standards (FIPS) 140-2 level 2 certification as well as for Common Criteria on selected platforms.
The CNG Suite B support includes all required algorithms: AES (all key sizes), the SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing algorithms, Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm (ECDSA) over the National Institute of Standards and Technology (NIST) standard prime curves P-256, P-384, and P-521. The NSA has stated that certified Suite B implementations will be used to protect information classified as Top Secret, Secret, and private information that, in the past, was described as Sensitive-But-Unclassified. All Suite B algorithms were developed openly and some other governments are also exploring adopting them as national standards.
These low-level improvements to the Windows PKI platform provide developers with more secure methods for protecting data, while creating a subsystem that is easier to maintain and improve over time. Because CNG is a pluggable architecture, new algorithms can be added as needed and CNG abstracts these providers from the application layer. The net result is that Windows Vista and Windows Server 2008 are designed to provide an advanced, evolvable platform for developing PKI-enabled applications and services.

Enrollment
The certificate enrollment experience in Windows has been greatly improved with a new wizard-based enrollment tool, better certificate expiration handling, a new API, "enroll on behalf of" capability, and credential roaming. These enhanced capabilities drive down the total cost of ownership for a PKI by making it easier to deploy certificates across your enterprise in a centrally managed fashion and with minimal user impact.
The most noticeable change from an enrollment standpoint is the new Certificate Enrollment user interface shown in Figures 1 and 2. This user interface replaces the old, limited one that lacked the ability to accept data from users during the enrollment process. The new interface allows users to input data during enrollment (if the administrator configures the certificate template to require it). The interface also provides clear explanations for why a user may not be able to enroll for a given template.
Figure 1 Selecting available certificates
Figure 1 Selecting available certificates
Figure 2 Status of unavailable certificates
Figure 2 Status of unavailable certificates
Another key enrollment interface improvement is in the handling of expiring certificates. The new interface provides end users with clear information about what certificates are expiring when and allows users to easily renew certificates or dismiss the warnings from the same interface. While administrators can automatically refresh certificates through auto-enrollment, this warning capability is important for mobile or disconnected users who may log on to the corporate network infrequently and have certificates near their expiration dates.
For developers who work with certificate enrollment, a new API is available that offers significant improvements over the old ActiveX®-based controls (xenroll.dll and scrdernl.dll). The new Certificate Enrollment API provides a well-defined class hierarchy that is much simpler to understand and to code against. This new API replaces xenroll in both Windows Vista and Windows Server 2008.
This change in API impacts both developers and IT professionals because Windows Vista clients cannot use the Web-based enrollment capabilities provided in Windows Server 2003. This is because those enrollment pages (stored in the /certsrv virtual directory by default) utilize the xenroll control no longer present in Windows Vista. The Knowledge Base article "How to Use Certificate Services Web Enrollment Pages Together with Windows Vista" (support.microsoft.com/kb/922706) provides information about a workaround. Auto-enrollment from Windows Server 2003 to Windows Vista is not affected.
In previous releases of Windows Server, enrollment agents were not limited in whom they could enroll on behalf of. In other words, once a user was given enrollment agent abilities, he was able to enroll on behalf of any other user in the forest. Of course, this meant that user could easily escalate his privilege by enrolling on behalf of an existing user and impersonating the user with the newly created certificate. In an attempt to thwart this threat, enrollment agent abilities were provided to only highly trusted individuals. While such an approach improved security, it also made deployment models less flexible, since only a small number of individuals possessed the ability to enroll on behalf of other users. As a result, large, geographically dispersed organization faced increased complexity when deploying certificates to end users (such as for smart cards).
In Windows Server 2008, enrollment agents can be restricted on a much more granular level. Restrictions can be based on what users can be enrolled on behalf of, or by what templates can be enrolled against, as shown in Figure 3. For example, an organization may now provide a local IT professional with the ability to enroll on behalf of all the users at his branch, but not users in the Human Resources group. This granular approach to enrollment agents allows enterprises to more effectively and securely delegate enrollment capabilities throughout their organizations.
Figure 3 Enrollment agent restrictions
Figure 3 Enrollment agent restrictions
One of the biggest challenges of managing a PKI is managing all the key pairs dispersed across an organization's devices. In even a moderately complex PKI environment, any given user may have several different key pairs (such as for EFS, authentication to a wireless network, and S/MIME) that need to be available regardless of where he has logged on. With the increasing prevalence of mobile computing and Terminal Services, it's more important than ever to replicate these key pairs around the network so that they're available to users wherever they may log on. While user-carried tokens such as smart cards can help solve certain parts of this problem, organizations may still have users that are not given cards or have certificates that are not stored on the cards. Credential Roaming solves these problems by securely storing the key pairs and certificates within Active Directory®, thereby making them available to users regardless of where they log on.
Credential Roaming was first delivered in Windows Server 2003 SP1 and allows certificates and keys to roam securely between machines without the use of roaming user profiles. In Windows Vista and Windows Server 2008, this capability is included by default and is implemented in the Certificate Services Client (CSC) service. Configuration options, such as what certificates can roam and how to arbitrate conflicts, are managed via Group Policy. On Windows Vista and Windows Server 2008, the CSC service can also roam stored user names and passwords. While this capability is included by default in Windows Vista, it should be noted that Credential Roaming is fully supported on Windows XP and when logging on to a Windows Server 2003 domain controller (with the deployment of an update; see support.microsoft.com/kb/907247). This means that you do not need to wait until completing a Windows Vista deployment before taking advantage of this technology.

Manageability
A number of upgrades have been made in Windows Server 2008 to improve the manageability of the Certificate Authority (CA) service by making it easier to set up, monitor, and run in a highly available manner. CA setup is integrated with the Role Manager tool and provides a streamlined method to install the CA service. Defaults are defined for each step in the process and setup can now be performed in an unattended mode. Finally, setup has better diagnostic capabilities to make it easier to troubleshoot any failures or problem conditions that may arise.
Monitoring of the CA service has been greatly enhanced in Windows Server 2008 (as has overall certificate diagnostics in Windows Vista). In addition to the much more flexible eventing infrastructure that spans the entire product, the CA service itself now has a built-in monitoring console and hooks into Systems Center Operations Manager 2007 (formerly known as MOM) to provide enterprise-level alerting. The Enterprise PKI monitoring console is an improvement over its predecessor that was introduced in the Windows Server 2003 AdminPak. The new console is included in the product itself and can now monitor Online Certificate Status Protocol (OCSP) URIs in addition to all the CAs in a given forest.
The Operations Manager management pack provides a passive monitoring capability for an organization's PKI, including built-in threshold-based alerting. For example, the management pack can be used to monitor the freshness of a Certificate Revocation List (CRL) and alert PKI administrators when a CRL reaches a certain number of days or hours prior to its expiration. Finally, a host of new performance counters are available that aid in troubleshooting and monitoring the overall performance of the CA service itself. These counters can be used to capture data such as how many certificates are being issued per second.
A new capability makes its debut in Windows Server 2008: support for hardware-level clustering of the CA service. This cluster support utilizes standard Microsoft Cluster Service (MSCS) technology and supports two-node active/passive configurations. Cluster support allows you to run an issuance infrastructure in a highly available manner and can be used in geographically diverse clustering deployments. If you choose to utilize clustering support, note that simply clustering a CA does not result in availability for the entire PKI. While clustering can help ensure that the CAs themselves are available, a properly functioning PKI will likely have other components not running directly on the CAs. For example, the CRL Distribution Points (CDPs) and OCSP responders must also be run in a highly available manner to ensure that revocation can be performed. Additionally, when Hardware Security Modules (HSMs), particularly network-based HSMs, are utilized, they also represent a potential point of failure in a PKI. Clustering is a strong, new capability for providing high availability for the Certificate Authority itself, but it's not a panacea for the availability of an entire PKI deployment.

Revocation
CRLs have long been used to provide validity checking for certificates. These CRLs include the serial numbers of all certificates whose validity period has not yet expired but that should no longer be trusted. For example, if an employee has a certificate with an expiration date of 12/31/2008 but the employee leaves the organization in 9/1/2007, the serial numbers of their certificates would be placed on the CRL. Then the CRL would be made available at multiple CRL Distribution Points (CDPs), such as HTTP and Lightweight Directory Access Protocol (LDAP) paths.
While still in widespread use, CRLs have some key disadvantages. First, CRLs are published by CAs periodically (usually once or twice per day). Clients then download these CRLs and cache them until the next publishing interval. During this cached period, certificates may be revoked, leaving the client unaware of the most current status. Secondly, in very large organizations, CRLs can grow to very large sizes (sometimes over 100MB). Distributing these files across a large, widely dispersed network can be difficult or impossible, particularly in branch office scenarios or other environments with constrained bandwidth.
To remedy these problems, OCSP was created and defined in RFC 2560. OCSP provides a real-time method of validating the status of certificates. An OCSP client runs on the machine that needs to check the validity of a leaf certificate. The client software then references an OCSP responder and sends a message asking for the validity status of the leaf certificate. The responder checks the validity of the certificate and responds back to the client in real time. This approach avoids caching and distribution problems.
For the first time, OCSP client functionality is included in Windows Vista (previously, third-party software was required) and is configurable via Group Policy. By default, Windows will attempt to use OCSP but will fall back to standard CRL lookups if the responder is not available.
In Windows Server 2008, an OCSP responder is provided to answer these requests. The responder is installed through Role Manager and can be monitored by the Operations Manager 2007 management pack. Because both the client and responder conform to the OCSP standard, they can be easily integrated into existing OCSP environments that utilize similarly standards-based third-party components. For example, it's fully supported to have a Windows Vista client check certificate status against a third-party responder and for a Windows Server 2008 responder to answer queries from a third-party client application. Additionally, the Windows OCSP responder can answer requests for certificates issued by any standards compliant CA. Windows Server 2008 CAs (and Windows-based CAs in general) are not required.

Wrap-Up
The PKI platform in Windows Vista and Windows Server 2008 includes many enhancements and several new features that make deploying and operating a PKI more secure and less costly. The new CNG API provides developers with an easier programming environment and support for new cryptographic standards. Enrollment improvements allow organizations to more easily mass provision certificates and securely roam keys across the enterprise. Likewise, the new management pack and CA clustering capability make it easier to monitor the status of CAs and ensure high availability. Finally, improvements in revocation checking use a standards-based approach to providing real time validation of certificates without the bandwidth costs of CRL distribution. As a result, Windows Vista and Windows Server 2008 take the Windows PKI platform to a new level.
PKI Enhancement Resources
  • Windows PKI Home Page
  • Troubleshooting PKI Problems on Windows Vista
  • Cryptography API: Next Generation
  • Certificate Enrollment API How to Use Certificate Services Web Enrollment Pages Together with Windows Vista
  • Configuring and Troubleshooting Certificate Services Client–Credential Roaming

John Morello has been with Microsoft since 2000. As a Senior Consultant, he designed security solutions for Fortune 100 enterprises and Federal civilian and defense clients. He's currently a Senior Program Manager in the Windows Server division working on security and anywhere access technologies. You can read his team's blog at blogs.technet.com/WinCAT.


The Desktop Files Getting to Know RDP
Wes Miller

The Remote Desktop Protocol, or RDP, allows you to access machines remotely. It's a very useful piece of technology that has undoubtedly saved more than a few system admins over the years. RDP has a long history of providing better and better remote access support. It was introduced in 1998 for Windows NT 4.0 Terminal Server
Edition (TSE) and has evolved in almost every release of Windows® since.
Beginning with Windows 2000, almost anyone could easily access a server system remotely because Terminal Services was introduced as an optional Windows component and could be configured so you could use the system either as an actual Terminal Server or for what we call Remote Desktop today. Windows Server® 2003 and Windows XP delivered native Remote Desktop functionality, allowing you to control the system as if you were there locally. Today, I use Remote Desktop every day to access my home PC and server remotely, and to use my Media Center Extender.
Windows XP and later versions of Windows added Remote Assistance, which provides an experience that is similar to Remote Desktop but designed for a local user to request assistance from a remote user. Continuing the evolution of remote access support, Windows Vista® now allows remote users to offer Remote Assistance, if permitted by Group Policy.
As you will see, Remote Desktop takes this powerful functionality to a whole new level, and you'll appreciate all it has to offer. Of course there are some limitations to Remote Desktop, but there are many benefits as well. Let's take a look at both.

The Good, the Bad, and the Fantastic
On Windows XP (with the exception of Media Center Edition), the key limitation is that only one interactive user can be logged on at a time. While Fast User Switching in Windows XP allows for more than one user to be logged on, only one user can be interactive using the mouse or keyboard—whether they are local to the PC or remote. With Windows Server versions (not running as Terminal Servers), two Remote Desktop sessions can connect at once. To connect via Remote Desktop to the actual console session in Windows Server 2003, you launch the Terminal Services client application (MSTSC.exe) with the optional parameter /console. The console session is very important because some older applications, which were not designed properly to take Terminal Services sessions into account, will often pop up dialogs only on the console session (Session 0). Figure 1 shows a user logged into the console session on Windows Server 2003. Windows XP and Windows Server 2003 Remote Desktop will enforce licensing to ensure that only the number of permitted users are logged on interactively.
Figure 1 Logged into Session 0
Figure 1 Logged into Session 0
Additionally, both network bandwidth and Group Policy can affect the Remote Desktop experience. Windows XP is capable of delivering up to 24-bit resolution as well as redirection of sound, local printers, disks, and the clipboard for cutting and pasting. Because of the way Remote Desktop works to draw the screen, removing graphic elements from the remote session (themes, backgrounds, and so on) improves the available network bandwidth dramatically and, as a result, the session is much more responsive to the user. Windows Vista builds upon this by adding 32-bit resolution and additional device redirection.
Note that some things, such as graphically intensive operations, can be challenging over even the best Remote Desktop sessions if there is insufficient bandwidth, so plan accordingly.

New Functionality in Windows Vista
Windows Vista delivered very significant changes to Remote Desktop. As I mentioned, 32-bit display resolution as well as font smoothing are some of the most visible changes. A related enhancement is the ability to run Windows Vista sessions across multiple monitors—by launching the Terminal Services client with the /span command. Note that /span only works with Windows Vista remote host systems, requires the same resolution on the client across the monitors, and requires that the monitors are aligned. Spanning works by treating the remote system (the client) as one large display. This means that maximizing an application may result in effects you may not expect, including inconveniently placed dialogs that must be moved by the user.
Additionally, if the client you are connecting from is a Windows Vista client, and the remote system is a Windows Vista system, you can run the remote session's user interface in Windows Aero™ Glass mode (as long as the local system supports Aero Glass, even if the remote system doesn't). This is a result of the re-architecture of Windows Remote Desktop to perform much of the window management operations on the client system if the client is Windows Vista, improving the user experience while reducing bandwidth usage.
Windows Vista also brings with it a key security enhancement, Network Level Authentication (NLA). NLA can help you prevent man-in-the-middle attacks in which a rogue user spoofs the server you believe you are connecting to. NLA also improves the authentication experience by not launching the full Windows user interface for authentication—minimizing impact on the remote system and reducing the susceptibility to denial-of-service attacks. NLA requires Windows Vista on both the client and remote system. Figure 2 shows how to specify via the RDP 6.0 client whether to enforce authentication, whether to warn, or whether to require it at all. Note that if you are connecting to a remote system that is running a version of Windows older than Windows Vista, you will want to ensure that it is set to at least warn for that connection; otherwise it will fail to connect.
Figure 2 Advanced connection preferences
Figure 2 Advanced connection preferences
Improved resource redirection (more than just drives and printers) is another key RDP enhancement in Windows Vista. As long as the drivers are present on the remote system and the device supports redirection, you can redirect numerous new types of devices including smart cards. Additional device types can be supported by their vendors.
Windows Vista also supports gateway servers via the RDP 6.0 client. This allows users to connect to systems at work seamlessly over the Internet without requiring a VPN connection or any third-party software. Figure 3 shows the Terminal Services Gateway server settings. You can think of a gateway server as similar to VPN, without requiring any specific client software other than the RDP 6.0 client software (no VPN settings or proprietary software needed).
Figure 3 Terminal Services Gateway server settings
Figure 3 Terminal Services Gateway server settings
Windows Vista also includes the infrastructure for a new feature called RemoteApp™. Here's what RemoteApp does for you. Remote Desktop generally allows you to connect to an entire Windows session. But suppose you were only interested in running Microsoft® Word or Microsoft PowerPoint®. RemoteApp provides the capability to do just that. Scenarios for enabling robust application sharing will be enabled in Windows Server 2008 as well.
Additionally, new support has been added in Windows Vista for the Windows Desktop Sharing API, which allows for the publishing of shared, collaborative applications. A sample application made available by the Microsoft Terminal Server team at blogs.msdn.com/ts/ archive/2007/03/23/writing-a-desktop-sharing-application.aspx demonstrates how the Windows Desktop Sharing API works.
A key change to bear in mind in Windows Vista and beyond is that Session 0 (classically the console session—where legacy applications will pop up dialog messages) is not generally accessible to the user. This reduces interactivity between system services (which run in Session 0, albeit non-interactively) and interactive users. It also allows for a reduction in the attack surface posed by overly privileged services and interactive users in Windows Vista where the focus has been on the reduction of privilege (via User Account Control and other security enhancements). This isn't generally something you have to be concerned with, unless you are running legacy software on Windows Vista and it is misbehaving either when being installed or when the application is running.
Where to Find Remote Desktop
A key issue to bear in mind with regard to Remote Desktop is where it can be used at all. Windows XP Professional, Media Center Edition, and Tablet PC Edition all include Remote Desktop functionality, as do all versions of Windows Server 2003. Windows Vista includes Remote Desktop functionality in the Business, Enterprise, and Ultimate editions. Home editions of Windows, including Windows XP Home Edition, and all Home Editions of Windows Vista, do not include Remote Desktop functionality.

Terminal Services Client
You can find the new RDP 6.0 client at go.microsoft.com/fwlink/?LinkId=91612. As mentioned above, the client includes all the functionality necessary to connect to an RDP 6.0 (Windows Vista or Windows Server 2008) system.
Figure 4 shows the RDP 6.0 client. One significant improvement in MSTSC is the ability to cache credentials—and if connecting from Windows Vista to Windows Vista or Windows Server 2008, even single sign-on (SSO) is supported via Group Policy.
Figure 4 RDP 6.0 client
Figure 4 RDP 6.0 client
Version 6.0 of MSTSC.exe has numerous command-line parameters, listed below. Let's take a look at each one in turn.
mstsc [<connection file>] [/v:<server[:port]>]
[/console] [/f[ullscreen]] [/w:<width>] [/h:<height>]
[/public] | [/span] [/edit "connection file"] [/migrate] [/?]
/v:<server[:port]> specifies the remote computer you want to connect to as well as an optional port value (port 3389 is the default; it can be changed on all versions of Windows).
/console allows you to connect to the console session of older versions of Windows. This setting does not work with Windows Vista or Windows Server 2008.
/f starts Remote Desktop Connection in full-screen mode.
/w:<width> specifies the width of the Remote Desktop Connection window.
/h:<height> specifies the height of the Remote Desktop window.
/public runs Remote Desktop Connection in public mode. In public mode, the RDP client does not cache any data to the local system. Use public mode, for example, when connecting to a business server from a system in a conference center.
More Terminal Services Magic
You may not be familiar with two other Microsoft technologies that use Terminal Services components to perform their magic. Fast User Switching in Windows XP and Windows Vista works by letting multiple users log on to the same system, but switch quickly between user contexts without forcing any users to log off. Windows Media Center Edition (and Windows Vista) built upon this infrastructure to allow Media Center Extenders, effectively a thin-client terminal with audio/video rendering technology and codecs, to log on and render the Media Center experience remotely on a television over wired or wireless connection. In Windows XP, these are both generally non-business related scenarios—since both require a system that is not joined to a domain and has Fast User Switching enabled. Bear in mind that both are available in Windows Vista product editions for business—though the usage scenarios are not really mainstream for business—so I didn't dive into too much detail on them here.

/span matches the remote desktop width and height with the local virtual desktop, spanning across multiple monitors if necessary. Note that the monitors must all be the same height and aligned side-by-side.
/edit opens the specified .rdp connection file for editing. RDP files are used to store connection information for a specific remote system.
/migrate moves older connection files that were created with Client Connection Manager to new .rdp connection files.
Many of the enhancements in the MSTSC client are also available when using the Terminal Services ActiveX® control, as well as using TSMMC.msc, described below, to connect to multiple systems from the same console.

New Functionality in Windows Server 2008
In addition to all of the functionality and changes already mentioned for Windows Vista, Windows Server 2008 includes Remote Desktop functions of its own: Terminal Services Web Access and Terminal Services Easy Print.
TS Web Access allows someone using a Web browser to view a list of programs that have been enabled on the remote server as RemoteApps, and easily launch them in a single click via the Remote Desktop ActiveX control. In some senses, you can think of this as an experience similar to the SoftGrid Application Virtualization experience I mentioned in last month's column on the Microsoft Desktop Optimization Pack, where a remote user easily launches an application without requiring any locally installed software. It will be interesting to watch over the next few years to see how the scenarios for using SoftGrid versus Terminal Services technologies compare.
TS Easy Print allows all printer tasks that occur on the remote (host) system to be redirected to the local (client) system. You may be thinking that printer redirection already does that, but it doesn't. Easy Print works without requiring any additional printer drivers on the host system or any user interactivity to get the device installed. If there is a local printer, it works the same on the remote system as it does locally. In order for Easy Print to work, the remote system must be running Windows Server 2008 and the client and server systems must all be running the Terminal Services 6.1 client and have the Microsoft .NET Framework 3.0 SP1 installed. Both of those are scheduled to ship near the time when Windows Server 2008 is released.

Tips for Using Remote Desktop
As I mentioned earlier, I use Remote Desktop every day—the Remote Desktop Microsoft Management Console (MMC) to be exact. By adding remote systems as nodes here, you can quickly and easily switch between multiple systems from the same user interface. Figure 5 shows what the MMC experience looks like. The MMC snap-in is part of the Windows Server 2003 Administration Tools Pack, the latest version of which is available at go.microsoft.com/fwlink/?LinkId=91685.
Figure 5 MMC page
Figure 5 MMC page
Another fun tip I stumbled upon involves cut and paste. Cut and paste across client and server was new with Windows XP. In order for it to work, the client and the server must both be running Windows XP and the clipboard must be redirected (see Figure 6). Windows Vista clients also support cut and paste when clipboard redirection is enabled for the connection.
Figure 6 Local Resources settings
Figure 6 Local Resources settings
Also important to note is that keyboard shortcuts you may need, such as Ctrl+Alt+Delete, do not get transmitted over the wire to the remote system—they always act on the local system. To send Ctrl+Alt+Delete to the remote system, press Ctrl+Alt+End on the client.
Finally, I would like to recommend that you regularly visit the Microsoft Terminal Services Team blog at blogs.msdn.com/ts. I do.
Personally, I find that Remote Desktop and Terminal Services make my life so much easier that it's hard to imagine life without them. I hope this article has provided some insight into the new functionality in the RDP 6.0 client and Windows Vista and Windows Server 2008.

I'd like to thank Nelly Porter, Senior Program Manager Lead from the Terminal Services team, for her help in researching this column.

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


Field Notes IM Interviews
Nathan G. Jensen

Recently, my company posted an ad online for a senior software engineer (telecommute position) and we were immediately deluged by applicants from all over the world. As the lead developer, I was tasked with conducting technical interviews for this massive candidate pool. I stared tiredly at the huge list and scanned one inflated resume after another. I knew from experience that most of these applicants would be unqualified, which is why tech interviews are so essential.
As I contemplated conducting telephone interviews with this long lineup, one after another, I thought, "this is going to take a month!" And then it hit me. I had an epiphany—a vision—an idea fell from that great IT Department in the sky: do the interviews over IM! It was brilliant! And it worked.
I began by sending a mass-e-mail message to all candidates via BCC, explaining that a thorough technical interview would be required and Windows Live™ Messenger—not the telephone—would be the means of communication. The e-mail screened out about half the applicants, presumably because they knew they couldn't bluff their way through the tech interview. For the rest, I felt that an IM chat would be workable because I just wanted direct answers to straight technical questions, bam bam bam. At this stage of the interview process, soft skills and oration didn't matter much.
Figure I had multiple IM windows open, firing tech questions at all of them like Whac-a-Mole
Figure I had multiple IM windows open, firing tech questions at all of them like Whac-a-Mole
My first observation was that this high-tech form of interviewing would save time and money. No phone bills. And as the applicants began to ping me for an interview, I realized that I could field several of them simultaneously and efficiently. This was actually quite a hoot. I had multiple IM windows open, firing tech questions at all of them like Whac-a-Mole. And because I had pretyped the questions, this was largely an exercise of copy and paste.
I carefully Web-screened my questions so as to minimize pretty answers lifted from the Internet. If somebody posted an answer that looked like it came from a polished article or official documentation, it would be obvious. Additionally, Windows Live Messenger can track the timestamp of each response so that you can go back later and determine which candidates were taking too long to answer.
Another "A-ha" moment occurred for me when, in the midst of these side-by-side IM chats, my phone rang and I realized that I could continue with the interviews and talk on the phone all at once. This was the pinnacle of multithreaded efficiency!
And just when I thought this gig couldn't get any better, another benefit surfaced. My biggest irritation around phone-based tech interviews is when I ask a short question and expect a short answer but instead receive a five minute dissertation. With IM this is eliminated because people tend to be terse with their IM replies.
At the end of each interview I saved the chat logs so that I had a record for later review and judgment. And I could send these logs to my boss for objective comparison. In the end, the whole process took a few hours instead of a week—which is how long it would have taken to set up times and interview the 25 candidates by phone.
I couldn't have been happier with my discovery. We hired the person who rapid-fired the correct answers back and then had a good "soft" interview with my boss by phone. It was fast, efficient, productive, and landed us the right candidate for the job just a few days after it was posted.

Nathan G. Jensen is a lead Web developer and freelance writer living in Salt Lake City. You can contact him by visiting builderdash.com.


Windows Confidential Windows Explorer Doesn't Do Text
Raymond Chen

Once upon a time there was the Send To X PowerToy. It let you do neat things such as selecting a bunch of files, right-clicking, and then selecting Send To Clipboard as Names. As expected, this copied the names of the selected files to the clipboard.
This was certainly a useful PowerToy, but why did it have to exist in the first place? Why can't I just copy the files in Windows® Explorer and then paste them as text to get their file names? Or better yet, why can't I simply drag files out of Windows Explorer and drop them into Notepad to get the names?
We tried it, but it didn't work.
Data transfer, whether via the clipboard or via drag and drop, is mediated by OLE data objects, represented by the IDataObject interface. A data object offers a variety of formats. Some clipboard formats, including text and bitmaps, have been around since the beginning of Windows. Others have been added over time. When file drag and drop capabilities first came to Windows, it took the form of an HDROP. You could pass this to functions such as DragQueryFile, for example, to extract the file names. When you copy something to the clipboard from Windows Explorer, the resulting data object offers, among other things, the aforementioned HDROP, the file contents, and a file group descriptor. But one of the formats you won't see offered by the data object is text.
When a drop target (a thing you can drop objects onto) is told that a data object is being dragged over it or dropped onto it, the drop target asks the data object "Whaddya got?" The data object responds by listing all the formats it supports, in descending order of preference. In other words, the first format returned by the data object is the format that best describes the object. Then comes the next-best format, and so on, until you get to the last format, which is just a pale shadow of the original object. For example, the data object that represents some objects being dragged out of a Windows Explorer window would probably offer a shell ID list first, since that is a nearly perfect representation of the contents of a Windows Explorer window. Next on the list might be a file group descriptor, followed by the file contents, and then an HDROP.
Back in 1998, the shell team tried adding plain text to the list of formats offered, putting it at the very end of the list. This essentially said, "if you are really desperate, at least you can get some text out of me (namely, the list of files)." Unfortunately, what happened was that a large number of programs were distracted by the shiny text format and said, "Ooooh, I like text." These programs went straight for the text format that contained nothing more than a list of files. As a result, when you dragged a file from Windows Explorer and proceeded to drop it into a document, the program just inserted the file name instead of inserting the file itself into the document.
Oops.
Due to the strongly negative application compatibility feedback, this change was reversed. As a result, when you drag and drop or paste files that are copied from Windows Explorer, the shell data object does not offer the file names as text.
Windows Vista®, however, rights this age-old wrong by giving you a way to copy the path as text: hold the shift key when you right-click in order to get the extended context menu. This will present the new Copy as Path option. No PowerToy necessary.

Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He leaves the job of operationalizing mechanisms to others.