November 2008
System Center: Monitoring Windows Server 2008 with OpsMgr 2007
As you deploy Windows Server 2008 into your environment, you’ll need a way to manage and monitor its health, performance, and availability. Fortunately, you can use the existing System Center tools you are already familiar with. See how you can use OpsMgr 2007 to manage your Windows Server 2008 assets. Pete Zerger
System Center: Using Configuration Manager with Windows Server 2008
The release of System Center Configuration Manager SP1 added full support for managing Windows Server 2008 systems, including such new features as server core. Get a quick overview of deploying the ConfigMgr agent and using ConfigMgr to manage Windows Server 2008 systems throughout your organization. Cameron Fuller
System Center: Granular Targeting in Operations Manager 2007
For every monitoring object you build, you must also decide what target to use. Choosing the correct target is critical, but knowing how to go about choosing the correct target is not always clear. Steve Rachui explores various options for correct targeting in OpsMgr and provides guidance for choosing the appropriate method for each scenario. Steve Rachui
Windows Server 2008: Presentation Virtualization with Enhanced Terminal Services
Virtualization isn’t limited to virtual machines and the virtualization of operating systems. Terminal Services has been abstracting the presentation layer of remotely run applications and desktops for years. Take a close look at key improvements to Terminal Services in Windows Server 2008 and get some tips for using these new features. Joshua Schnoll
SQL Server 2008: Tracking Changes in Your Enterprise Database
SQL Server 2008 introduces two new features that allow you to track changes more easily and efficiently. Paul Randal examines the new Change Tracking and Change Data Capture features and discusses the implications these features will have for database administrators. Paul S. Randal
Columns
From the Editor: Now What?: | Letters: Readers Speak Out: | Toolbox: New Products for IT Pros:
Exchange Queue & A: Outlook Anywhere and IPv6, the Remote Connectivity Analyzer, and More: Have Exchange questions? We've got answers. This month, Henrik Walther looks at configuring Windows Server 2008 to work with Outlook Anywhere, testing remote connectivity, deploying standby continuous replication, and more.Henrik Walther | Utility Spotlight: Internet Explorer Developer Toolbar: Whether you develop Web content or simply support a webmaster, here’s a free Microsoft utility that will make your job easier. See how the Internet Explorer Developer Toolbar can help you explore and troubleshoot Web pages.Lance Whitney | Inside SharePoint: Extending Office Applications with Web Services: Web services are fundamental building blocks of distributed business applications. Here's an overview of how you can use Web services in a SharePoint environment to extend Microsoft Office applications.Pav Cherny
Windows PowerShell: Building Your Own Software Inventory Tool: Don Jones demonstrates a Windows PowerShell-based inventory tool and guides you through the process that goes into building such a solution.Don Jones | Hey, Scripting Guy!: Probing the Depths of WMI: This month, The Scripting Guys take a close look at the WMI infrastructure. Along the way, they provide some helpful scripts that can serve as a starting point for learning more and accomplishing useful administrative tasks.The Microsoft Scripting Guys | The Desktop Files: Data Loss Prevention with Enterprise Rights Management: Enterprise rights management is effectively the only way to protect confidential information from being leaked. Discover how the Microsoft rights management solution can protect your organization's information from unauthorized access and use.Wes Miller
Security Watch: Revisiting the 10 Immutable Laws of Security, Part 2: It's been about 8 years since "The 10 Immutable Laws of Security" were first published, and a lot has changed since then. In this installment, Jesper Johansson continues his analysis of the the immutable laws to see if they still hold true after 8 years.Jesper M. Johansson | Field Notes: Old Wine in New Bottles: Romi Mahajan reflects on how technology has dramatically impacted community, but explains why there will always be a need for in-person meetings and events.Romi Mahajan | Windows Confidential: Windows Can but Won’t: Raymond Chen explains why Windows can but chooses not to replace a file that is currently in use.Raymond Chen


System Center
Monitoring Windows Server 2008 with OpsMgr 2007
Pete Zerger

Some of the features discussed in this article are still in beta and are subject to change.
At a Glance:
  • How OpsMgr works
  • Built-in knowledge
  • Diagnosing problems
  • Reporting and auditing

Contents
How OpsMgr Works
Knowledge to Solve Real-World Problems
Service Availability and Visibility
Seeing the Distributed Enterprise
Service Level Reporting
Pairing Up in Security and Compliance Auditing
A Management Pack for Every Application
Getting Started
The much-anticipated release of Windows Server 2008 introduced significant changes to the OS, adding powerful functionality such as server core, server roles, read-only DCs, Hyper-V, Terminal Services Gateway, and enhancement support for Internet Protocol version 6 (IPv6). While these changes and new features are beneficial, they do somewhat alter how you use System Center to manage and monitor your Windows Server 2008 systems.
As organizations introduce Windows Server 2008 into their production environments, they'll need a way to manage and monitor the health, performance, and availability of these services. Fortunately, you can use existing System Center technologies. System Center Operations Manager 2007 (OpsMgr) recently added support for Windows Server 2008 through the availability of new management packs, and System Center Configuration Manager 2007 (ConfigMgr) added support for Windows Server 2008 with the release of ConfigMgr SP1.

How OpsMgr Works
OpsMgr 2007 monitors and measures the health of Windows Server 2008 and apps on your server using an agent that is installed on the server being monitored. The agent reports data, such as events, alerts, and performance data, to a central server called a management server. The management server then inserts this data into a central SQL Server database. This data can then be rendered in the Operations Console on any workstation (running Windows XP SP2 or a newer version of Windows) or through a Web Console. This architecture is illustrated in Figure 1.
Figure 1 Example Operations Manager 2007 management group topology
Once an OpsMgr agent is installed and configured on your servers, discovery of applications and services installed on the servers is automatic. Special monitoring rules, called Object Discoveries, are sent down to the agent by the management server. These rules perform checks on the registry and file system as well as run scripts designed to discover exactly which components are installed. They also identify all the roles the Windows Server 2008 server may be configured for, such as domain controller, print server, Web server, or cluster server.
Object discoveries are configured by default to repeat at regular intervals on the local machine. By repeating these checks on a regular basis, OpsMgr can identify changes in applications and services configured on the server over time. Now I can delve into how OpsMgr 2007 provides visibility into the Windows Server 2008 infrastructure.

Knowledge to Solve Real-World Problems
As mentioned, management packs enable the core monitoring functionality by providing a collection of monitoring rules, tasks, and reports. But while the primary purpose of OpsMgr is to identify little issues before they become big problems, it goes further than just raising an alert when there's a sign of trouble. The management packs actually contain information on probable causes and recommended solutions for many issues the monitoring rules identify. This information is shown in context when you view alerts (see Figure 2), both in the Monitoring space and when viewing the health state of a system using the Health Explorer.
Figure 2 Product knowledge delivered in the Alert view of the operations console
In addition to displaying the current health state of systems and apps, the Health Explorer tool also displays a history of changes in system and application health, along with a time stamp for each change. You can actually select the occurrence of any change in the health state and view details related to the change that triggered the condition.
Through special responses called Diagnostics and Recoveries, you can configure OpsMgr to automatically retrieve configuration or environmental data when an issue occurs. You can see in Figure 3 that when a state change event related to a slow response from a Windows 2008 DNS Server is highlighted, the bottom pane displays a list of running processes collected when the change occurred on the server. This data may be the key to figuring out which services were consuming excess resources at that time.
Figure 3 State change events in the OpsMgr Health Explorer

Service Availability and Visibility
Windows Server 2008, of course, includes features such as Internet Information Services 7.0 (which can be used to deliver Microsoft .NET Framework-based applications and Web services), as well as features such as failover clustering and network load balancing, to make these services highly available. While clustering and network load balancing have gotten easier to implement and manage in Windows Server 2008, these technologies still add complexity to management tasks. Visibility into the health and performance of these components is vital to ensuring your infrastructure and applications are performing as expected.
OpsMgr addresses this complexity with management packs for the high-availability solutions built into Windows Server 2008. These management packs alone provide hundreds of monitoring rules to ensure the health of each of these components.
When it comes to service monitoring, what counts in the end is that business-critical apps are available from the customer's perspective. A critical Web app designed for your customers may be available on the server but inaccessible externally. OpsMgr offers such features as synthetic transaction and distributed app monitoring to provide service-level visibility into the transactional health and availability of distributed line-of-business apps from an end user perspective.
Using a simple wizard, you can create a synthetic URL monitor to test the availability, response time, and content returned by a Web application. OpsMgr can validate the transactional health of your applications using monitoring features available out of the box. But for true transactional monitoring of more complex Web applications, you can record a browse sequence of browser-based actions to include in the URL monitor, providing a more thorough and realistic test.
To ensure availability from an end user perspective, you can choose one or more computers in different locations on your network (called watcher nodes) to perform the URL test. This is done in the same wizard, as shown Figure 4. To act as a watcher node, the system needs an OpsMgr agent installed.
Figure 4 Choosing watcher nodes for synthetic URL monitoring

Seeing the Distributed Enterprise
Using the Distributed Application Designer in OpsMgr 2007, administrators can create a model of their distributed application infrastructure (see Figure 5). The designer lets you drag and drop the components of an application into a single view and define dependencies to illustrate how the components relate to one another. It doesn't matter whether you have an IIS 7.0 site or a Windows Server 2008 system running Hyper-V and hosting virtual machines. All the monitored objects can be included in a diagram representing a true picture of your app.
Figure 5 Distributed application modeling in OpsMgr 2007
You can even create custom health algorithms, allowing granular control over what constitutes healthy and unhealthy states in your apps. This feature is useful in configuring how OpsMgr calculates the health of load-balanced components that can sustain multiple failures (such as a Web farm).

Service Level Reporting
The Windows Server 2008 Operating System management pack includes a number of performance reports that can be used to gauge server performance. But that's just the tip of the reporting iceberg. OpsMgr 2007 includes global performance and availability reports (located in the Microsoft Generic Report Library). These allow users with report access to report on the availability of any monitored object in OpsMgr 2007.
This capability can be used to measure application and system performance against IT service delivery objectives. For example, you can use the generic Availability report, shown in Figure 6, to determine the availability of all your Windows Server 2008 instances, server roles, and OS components in your environment with just a couple of clicks. Or you can use the Business Hours feature in report headers to generate Availability reports that only cover the specific time periods during which your apps must be available.
Figure 6 Windows OS availability reporting in OpsMgr 2007
The Service Level Dashboard is a feature that extends reporting functionality and, as a result, allows administrators to configure benchmarks for performance and availability service level agreements (SLAs). You then have the ability to compare this to actual distributed application availability to see how performance stands up to performance and availability goals. The information is displayed in a consolidated dashboard, which is shown in Figure 7.
Figure 7 Service Level Dashboard in OpsMgr 2007

Pairing Up in Security and Compliance Auditing
As you surely know, problems with data privacy have led to a number of government-imposed regulations, such as Sarbanes-Oxley (SOX) and Health Insurance Portability and Accountability Act (HIPAA). Aligning corporate security policies with industry best practices is no longer just a good idea—it's the law! The ability to recount and explain what changes occurred on a system are a matter of critical importance, and the failure to do so can cost an organization millions of dollars in fines.
Security auditing in the last few versions of Windows Server was covered by 9 very broad security audit categories, frequently resulting in information overload. Windows Server 2008, however, provides more than 50 audit categories delivered through a new feature called Granular Audit Policy (GAP). This lets you perform security auditing with much greater control, filtering out non-critical information from the event log without losing visibility at the category level. For example, if on a particular system you want to monitor changes only to the Active Directory and not to local items, such as the registry, you can configure the Directory Service audit subcategory to report only these events. You can enable success and/or failure auditing of these changes at the command line like so:
Auditpol /set /subcategory:"Directory Service Changes"
/failure:enable
Even more filtering and reporting on this in a single interface is available in OpsMgr with Audit Collection Services (ACS). This automates collection and centralized archival of distributed Windows Security Event Logs in a single database repository.
The Audit Forwarding Service, which is loaded as part of the OpsMgr agent installation (but disabled by default), will send Security Event Log events to a central server. This central server, which is called an ACS Collector, then inserts the security events into a central audit database hosted on a server running SQL Server 2005. This architecture is illustrated in Figure 8. By forwarding events in nearly real time, the likelihood that local administrators can interfere with Security Log Events is minimized.
Figure 8 Audit Collection Services architecture
Once these events haven been collected, auditors and administrators can then analyze them through nearly 20 reports included with Audit Collection Services (see Figure 9). ACS reports cover a variety of common audit categories, such as account management events, forensic reports targeting user activity, and reports revealing potential threats to your Windows 2008 Security Event Logs (such as attempts by administrators to clear the Security Event Log on a monitored Windows system).
Figure 9 Audit Collection reports in Operations Manager 2007

A Management Pack for Every Application
As part of its commitment to the Dynamic Systems Initiative, Microsoft has vowed to deliver a management pack for every new server application. With so many services available in Windows Server, Microsoft has committed to deliver more than 20 management packs for the Windows Server 2008 platform alone. The list of Windows Server 2008 management packs for OpsMgr 2007 includes those shown in Figure 10.
Figure 10 OpsMgr Management Packs
2008 Windows Server Operating System (Base OS)
2008 Microsoft Cluster Server (MSCS)
2008 Domain Name Service (DNS)
2008 Dynamic Host Configuration Protocol (DHCP)
2008 Internet Information Services (IIS)
2008 Windows Key Management Services (KMS)
2008 Group Policy
2008 Application Server
2008 Print Server
2008 Terminal Services (TS)
2008 DFS-R (Replication)
2008 DFS-N (Namespace)
2008 Active Directory
2008 Network Access Protection (NAP)*
2008 Services for Unix
2008 Network Load Balancing (NLB)
2008 Windows Rights Management Services (RMS)
2008 Windows Deployment Services
2008 Streaming Media Services
2008 Certificate Services
2008 Active Directory Federation Services (ADFS)
2008 AD Lightweight Directory Services (ADLDS)
2008 Hyper-V
2008 Fax Server

Getting Started
As you can see, Windows Server 2008 and System Center Operations Manager 2007 deliver a solid, enterprise-ready infrastructure to support your most critical business services. With a host of features designed to deliver service-oriented monitoring with integration in all the right places, OpsMgr 2007 allows organizations to take advantage of existing investments in Active Directory, streamline administration, and reduce the total cost of ownership of Windows Server 2008 deployments.
I recommend that you download the 60-day trial version of Windows Server 2008, which is available at microsoft.com/windowsserver2008/en/us/trial-software.aspx. And you can also download a 180-day trial version of Operations Manager 2007 at microsoft.com/technet/opsmgr/2007/downloads/trials/privacy.mspx.

Pete Zerger is a consulting partner with AKOS Technology Services. With nine years of experience in the IT industry, Pete focuses on design and deployment of enterprise operations management, directory services, and messaging solutions.


System Center
Using Configuration Manager with Windows Server 2008
Cameron Fuller
At a Glance:
  • Deploying the ConfigMgr agent
  • Queries and collections
  • Hardware and software inventories
  • Viewing reports

Contents
Deploying the ConfigMgr Agent
Working with Server Core and Hyper-V
Queries and Collections
Hardware and Software Inventory
ConfigMgr Reports
Wrapping Up
System Center Configuration Manager 2007 SP1 includes Asset Intelligence updates and support for Intel vPro technology and Windows Vista SP1. But most important, at least in regard to this article, is that SP1 gives Configuration Manager full support for Windows Server 2008.
A critical point in providing an effective solution for managing and monitoring Windows Server 2008 was to provide the same functionality that is currently available for Windows 2000 Server and Windows Server 2003. Configuration Manager (ConfigMgr) 2007 has achieved this goal.
With SP1 installed, ConfigMgr works with Windows Server 2008 just as it does with other versions of Windows. (System Center Operations Manager 2007 has also made strides in this area with the release of new management packs. For more information, read Pete Zerger's article in this issue, "Monitoring Windows Server 2008 with OpsMgr 2007," technet.microsoft.com/magazine/cc974507.) In this article, I'll provide a quick briefing on how ConfigMgr 2007 SP1 lets you monitor your Windows Server 2008 assets.

Deploying the ConfigMgr Agent
ConfigMgr relies on an agent, referred to as a client, that is deployed to the servers or workstations being managed. ConfigMgr clients can be deployed using existing methods such as client push installation, logon installation, software distribution (for agent updates), and manual installation. But ConfigMgr also offers new methods of client deployment, including deployment from a Software Update Point using Windows Server Update Services (WSUS) mandatory updates and installation through Group Policy.
In Windows Server 2008, the firewall is enabled by default, but it should not interfere with deployment of ConfigMgr clients if roles are installed. Roles provide exceptions for File and Printer Sharing and Windows Management Instrumentation (WMI).
If the firewall is interfering with the ability to push out a ConfigMgr client, you can use a group policy to disable the firewall for a specific organizational unit (OU) by deploying the ConfigMgr clients while the systems are in the OU and returning them to their original OU after deployment. Another approach is to disable the firewall from the command line using Netsh firewall set opmode disable. After the ConfigMgr client has been deployed, you can re-enable the firewall using Netsh firewall set opmode enable.
Figure 1 shows an agent being deployed to Windows Server 2008 servers using the Client Push Installation Wizard. Note that in this image, Windows Server 2008 Enterprise Server appears in the inventory as Microsoft Windows NT Advanced Server 6.0, and Windows Server 2008 Standard Server (server core, in this case) appears in the inventory as Microsoft Windows NT Server 6.0.
Figure 1 ConfigMgr client being deployed to Windows Server 2008

Working with Server Core and Hyper-V
The ConfigMgr client can be deployed to Windows Server 2008 server core systems. You can then use the net start command, which shows the services installed on a server, to confirm that the agent is running. Figure 2 shows the results of the net start command on a system running server core. It lists the Systems Management Server (SMS) Agent Host Service, indicating that the ConfigMgr client has been deployed to the system.
Figure 2 Confirming the ConfigMgr client is installed on a server core machine
The ConfigMgr client is not currently supported when running in Hyper-V (at the time of writing this article). However, support should be added soon now that Hyper-V has been officially released. Initial tests of the ConfigMgr client when running in Hyper-V functioned without an issue, but it is not yet an officially supported configuration.

Queries and Collections
ConfigMgr offers no pre-built queries or collections specific to Windows Server 2008. To create a new query, start with an All Windows Server 2003 Systems query. In the new query, change the name of the OS to %Server 6.0%. The results are shown in Figure 3.
Figure 3 All Windows Server 2008 systems
The query language to create a collection for only Windows Server 2008 is shown in Figure 4. A collection can be based upon this query to target the software distribution to only Windows Server 2008 servers.
Figure 4 Query language for Windows Server 2008
select SMS_R_System.Name, SMS_R_System.SMSAssignedSites, SMS_R_System.IPAddresses, SMS_R_System.IPSubnets,
SMS_R_System.OperatingSystemNameandVersion, SMS_R_System.ResourceDomainOrWorkgroup, SMS_R_System.LastLogonUserDomain,
SMS_R_System.LastLogonUserName, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceId, SMS_R_System.NetbiosName
from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like "%Server 6.0%"

Hardware and Software Inventory
One of the key functions of ConfigMgr is inventorying. The hardware and software inventories let you identify resources throughout your organization. This information can be used in the reporting functions as well as in collections. For instance, you can distribute software to a collection that contains only systems running Windows Server 2008. In Figure 5, Resource Explorer shows a Windows Server 2008 server core system that has been inventoried.
Figure 5 Windows Server 2008 server core system shown in the Resource Explorer

ConfigMgr Reports
ConfigMgr 2007 offers robust reporting capabilities, including pre-built reports and the ability to generate dashboard views of ConfigMgr data. Canned reports offer detailed information about the hardware and software inventories, software metering, software distribution, updates, and the status of ConfigMgr itself.
Within the reporting interface, reports directly related to Windows Server 2008 systems appear under the top-level Operating System folder. Multiple reports are available, including the Count operating systems and service packs report (shown in Figure 6). Windows Server 2008 and Windows Vista share the same code base, and they will now share the same service pack cycles. As a result, inventory reports show the CSD Version for Windows Server 2008 systems as SP1.
Figure 6 ConfigMgr operating system reports

Wrapping Up
ConfigMgr 2007 integrates with Windows Server 2008, offering the same features you're accustomed to on other versions of Windows Server, and it supports new, key features such as server core. All of this will simplify the move to Windows Server 2008, as you can continue to use existing and familiar tools to manage your updated systems.

Cameron Fuller is an Operations Manager MVP and a Managing consultant for Catapult Systems, an IT consulting company and Microsoft Gold Certified Partner. Cameron is the coauthor of Microsoft Operations Manager 2005 Unleashed and System Center Operations Manager 2007 Unleashed.


System Center
Granular Targeting In Operations Manager 2007
Steve Rachui
At a Glance:
  • Using an existing target
  • The problem with attribute discovery
  • Creating targets with the authoring console
  • Script-based discovery

Contents
Using an Existing Target
Creating Targets with the Authoring Console
Using a Registry Key
Registry Value
Discovery via Script
Additional Considerations
Creating custom monitoring objects (rules, monitors, groups, and so on) is a normal part of many System Center Operations Manager (OpsMgr) 2007 administrators' routines. For every object that is authored, there is a common question that must be answered—what target to use.
Choosing the correct target for an object is critical, but the correct approach may not always be clear. OpsMgr provides a number of options for targeting. This article will take a look at several, with the goal of helping administrators choose the appropriate method for each scenario; and the terms "class" and "target" will be used interchangeably.
Let's assume you have an internal application called widget that needs to be monitored. All of the monitoring specifications have been defined and the work to build the monitoring objects for widget has begun. You quickly discover, however, that there is no precise target for widget! According to OpsMgr best practices, all rules, monitors, and so forth should be targeted to the most specific object possible in order to limit the scope of distribution to just the systems of interest. What are the options in OpsMgr that can help you meet this best practice goal?

Using an Existing Target
By default, OpsMgr includes a long list of targets, and that list grows as more management packs are imported. When you're creating a new management pack object (MPO) and considering the target, first review the available items to see if one of the preexisting targets is sufficient. If you're building MPOs to extend System Management Server (SMS) server monitoring, for example, it is likely that the existing targets that are imported along with the default SMS server management pack can be reused for your MPO.
Using default targets, however, doesn't always work. If the available targets are not sufficiently specific for the MPO being created, you can either work around the lack of an optimal target or create a new target.
One common approach (though it does have some drawbacks) is to associate the new MPO to the Windows client or Windows server class or to any other appropriate base class (again, be as specific as possible) that includes the required targets. When doing this, be sure to create the MPO in a disabled state. Then you can build a group containing all of the systems where these MPOs need to execute and override the disabled MPOs so the MPO is enabled for only the agents in the group. This allows the MPO to be delivered and run on just the agents that are allowed by the override.
What are the drawbacks of this approach? First of all, using this method targets the broader class of objects (Windows Computer, for example), so all monitored MPOs targeted in this way show up under the targeted object in Health Explorer (see Figure 1).
Figure 1 Health Explorer for computer targeted by override
This is really just cosmetic, so it may not be a problem in a given environment. But targeting in this way does cause the health state of the parent object (such as Windows Computer) to be affected when the custom monitor is impacted. So, if the widget application has a problem, the health of the entire targeted object may be affected. Depending on what is being monitored, this may or may not be noteworthy.
Targeting MPOs to groups is not generally an appropriate approach in OpsMgr—so why does this work? Remember, groups in these examples are used as overrides and are not the actual target of the MPO.
This may seem like semantics, but think about groups in OpsMgr. Groups are objects, just like any other object. When an object is chosen as the target, this means that the MPO in question is being deployed to the agents that own the targeted object.
So, which agent owns the group object? Correct—the Root Management Server (RMS). Targeting a group will cause MPOs to be delivered to the agent that owns the group, meaning that MPOs will be deployed only to the RMS! If an MPO is targeted appropriately, the stage is already set for the MPOs to be deployed to the correct agents, but by disabling the MPO, you've stopped that process before it can start.
When an override is introduced, the existing target is still the target—the override just changes the disabled status to enabled for a few agents per group membership. But the agents where the MPO is enabled are already part of the original target for the MPO. I know it's a little confusing at first.
Now consider a scenario where nothing discussed thus far is workable. What do you do? There is only one remaining option: create a new target specifically for the MPOs, which you can do either by using the service monitoring template in the Operations Console or by creating a new target in the Authoring Console.
Before you consider those, however, what about creating an attribute discovery? You might be thinking that this is a viable option that has been overlooked. Let's take a look. It is possible to build an attribute discovery that gets information from the registry or from WMI. To work, the attribute discovery must be targeted at a class that contains the registry or WMI entries of interest. Common targets are Windows client or Windows Server classes, or even the more generic Windows Computer class.
Note that the term itself—attribute discovery—implies what is actually happening: a new attribute is being discovered and used to extend an existing class. True, a new class is created as a result, but it is actually the same old class with all the same members, just with a new attribute being reported. Based on this, you can see that building a new attribute discovery is not the same as creating a truly unique target.
How about an example? Suppose a new attribute discovery is created to find the registry key for the widget product. This discovery is targeted to be deployed to Windows Computer so that it will include all agents that might have the widget registry key.
After making this choice in the wizard, you get a warning that the Windows Computer class cannot be extended (it is in a sealed management pack after all—if this were not a sealed management pack, there would be no such warning) and a renamed target class is presented as a choice you can use in order to proceed (see Figure 2). This happens because the goal of attribute discovery is to extend an existing class.
Figure 2 Attribute discovery doesn’t create a unique class
Now let's look at service templates, which can be used to create unique targets for systems that can be found based on an installed service. Service templates are exceedingly easy to use; Figure 3 shows an example.
Figure 3 A service template
Be aware, however, that using the template may result in the creation of additional MPOs beyond what you may intend or want. After using the service template, it's a good idea to check and see what additional objects have been created and determine if they should be retained (see Figure 4).
Figure 4 Objects created when a template was used
Moreover, service templates will create a discovery and a new class for each and every service. This may be exactly what you want, or it might be too granular. For example, suppose your custom app has multiple services. In that case, a new class and a new service monitor will be created for each! It's more likely that the desired monitoring approach would be to have a single class with each service monitor targeted to only that class.
If you can't or don't want to use a service template, your only remaining option is to use the Authoring Console. One glance at the Authoring Console documentation shows that proper use of this feature requires a very deep discussion—one that is far beyond the scope of this article.
Nevertheless, a few simple examples that use the Authoring Console to create and populate a new target in OpsMgr are in order. I will give two examples that revisit the idea of using a registry entry to uniquely identify the widget application and a third example that will demonstrate discovery by script.

Creating Targets with the Authoring Console
In many cases, it is possible to scan the registry for a particular value or key that will uniquely identify the servers of interest that host the desired target. If a class (target) could be built and populated with systems where the widget registry key exists, that would be an easy way to create a unique target.
My first example walks through doing this by simply looking for the existence of a registry key. The second example will look for a specific value associated with the registry key. Note that while you can create a registry attribute discovery rule (as discussed earlier) and a discovery in the Authoring Console, as demonstrated in the following examples, the two do not achieve the same results—the former simply extends an existing class while the latter actually creates a new target.

Using a Registry Key
When the Authoring Console is first launched, you must choose whether to load an existing management pack or create a new one. When you choose to create a new management pack, a wizard appears and lets you select a template either for an empty management pack or for a Windows Application (Registry) management pack (see Figure 5).
Figure 5 Choosing a template for a new management pack
Either one can be used to achieve the same results, but it is easy to create a new class using the Windows Application (Registry) template. You must simply supply a name and then select the registry template. Next, you have to supply the name and description for the management pack on the Name and Description screen. The value to enter here is the value displayed under the management packs node of the Operations Manager UI.
Then provide a description of the application on the Windows Application screen. The value entered here will be the value displayed in the Attributes node of the Operations Manager UI. Next, configure how often the discovery should run. The default here is every 15 seconds, which is probably far too often. Balance the need for rapid discovery against the performance impact that may occur with too frequent discovery. There generally is no compelling reason to have a discovery run more than once per day.
Now fill in the detail needed to find the registry key/value you're interested in. There are multiple attribute types available; if you simply want to check for the existence of a key, use the Bool type.
Finally, build the query expression. This may appear to be duplicate work—didn't you just build the query expression? Actually, no. The Registry Probe Configuration screen defines the registry key to look at and how to look at it. The Expression Filter screen is used to define what value is expected.
OK, with all of this done, what have you actually created? Did you meet the goal of building a new class? In the Authoring Console, select the service model node and click on classes. Note that a new class has been created. Examine the properties to understand more about this new class.
What about the discovery definition? Look under health model and note the discovery rule—review the properties here as well to see how the rule is actually built.

Registry Value
Building a discovery that looks for a registry value instead of a registry key is equally easy. Work through the wizard again, but, this time, modify the input to pull a registry value instead of a key.
To initiate the wizard after the initial template has been completed, navigate to Health Model | Discoveries. In the middle pane, right-click and select New | Registry (filtered). The entries will be the same as before except this time a registry value is specified.
It's that easy! With the new targets created, the example will stop here. But note that additional work still needs to be done in order to populate the management pack with MPOs. MPOs can either be created through the Operations Manager UI or directly in the Authoring Console—either way works fine.
You must remember, though, that if you open an MPO in the Authoring Console that you created in the Operations Console, it will not have the original name you gave it. Instead, the given name will be replaced with a string starting with UIGenerated. While this does not affect the function of the MPO whatsoever, it can be very frustrating if you are trying to find a specific MPO in the Authoring Console.
No matter which method you choose, a new class has been created that can be used for delivering rules. How do you know this new class and discovery works? You can take a look at the discovered inventory information for the new class, and the new class also shows up as a valid target for a new monitor (shown in Figure 6).
Figure 6 The new class is a valid target for a monitor

Discovery via Script
To create a script-based discovery in an existing management pack, load that management pack into the Authoring Console. If you are starting from scratch, open the Authoring Console and choose to create a new management pack.
Because this is a script-based discovery, the only applicable choice is to create a blank management pack. The first step in this process is to define the class that will be populated with the script, along with the class properties (attributes) of interest. FileName, FileDirectory, and FileDescription are available properties defined by this class that can be manipulated in the script, which I will show to you shortly.
In addition, the DisplayName property is inherited from the System.Entity class and can also be manipulated by script. Note that only attributes that appear in this list can be manipulated with the discovery script, so make sure any items of interest are displayed here. Also note that as each property (attribute) is selected, details about the property will appear on the right. Be sure to fill out the Display Name entry for each property (attribute). If they are left blank, the discovery information will be returned but the column headers in the OpsMgr environment, such as in the Discovered Inventory view, will be blank.
With the class defined, you can create the script-based discovery. Navigate to Health Model | Discoveries. Right-click and select New | Script and create the Discovery. There is a great deal of information here. First, the general tab allows for naming the discovery and supplying a target on which the discovery should be run. Remember, be as specific as possible when defining the target.
For the purposes of this article, Windows Computer makes sense. On the Discovered Types tab, configure the type of object to be discovered. Notice that the name of the discovered type here matches the class name defined earlier.
Next is the Configuration tab, which displays information that is automatically generated when the script is defined. (Select Configure to see the script and the time scheduled for executing the script.) Also notice the Parameters box (which can be accessed by selecting Configure | Script | Parameters). Take a look at the parameters listed—I will refer to them later in this article.
The script to drive the discovery collection process and submit the results to OpsMgr is shown in Figure 7. This is a very basic script, but it supplies the framework for the key elements that are needed in order for script-based discovery to work.
Figure 7 Discovery script
Option Explicit
Dim oArgs
Set oArgs = WScript.Arguments

Dim oAPI

  'All of the work to submit discovery data is done in the context of
  'API's defined in the OpsMgr 2007 SDK.  Creating the oAPI object allows
  'access to the OpsMgr 2007 scripting environment
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim SourceId, ManagedEntityId, targetComputer

  ' SourceId is the GUID of the discovery object that runs the script.
SourceId = oArgs(0)

  ' ManagedEntityId is the GUID of the computer class that is targeted by the script.
ManagedEntityId = oArgs(1)

  ' targetComputer is the Fully Qualified Domain Name
  ' of the computer targeted by the script. The FQDN
  ' is in Arg(2) of the command prompt.
targetComputer = oArgs(2)

Dim oFSO, oDiscoveryData, oInst

  'This operation sets the stage for creating new discovery data.  Note that the
  'values passed to the CreateDiscoveryData function are variables that are defined
  'by the command line when executed.  The parameters box was displayed earler.  This
  'is where the command-line parameters required by the CreateDiscoveryData object are
  'defined and passed to the script.
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

  'This section defines objects needed to access the file system environment
Set oFSO = CreateObject("Scripting.FileSystemObject")
If (oFSO.FolderExists("C:\WServer")) Then

    'Assuming a folder called WServer was found on the root of the C drive, the script proceeds to create a new
    'class instance.  Once it's created, a number of property (attribute) values are filled in; note that all
    'three of the properties (attributes) defined on the class are used in the script along with one property
    '(attribute) from the windows computer class.  Note the difference in how the script refers to properties
    '(attributes) defined in the local class vs. a class that is accessed by reference.  Also note the Name field
    'as defined in the script.  Here the name is a friendly name that easily maps back to a known class name.
    ' When the management pack is saved and imported into the Operations Console and the script delivered to the
    ' agents, these name values will no longer be friendly, they will be converted to the appropriate class GUID.
    'Normally these converted values wouldn't be seen, but if the script directly on the agent is examined,
    'the difference will be seen. Note that if the script attempts to define/use a property (attribute)
    'that has not been defined in the referenced class, validation errors will be displayed.
  Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']$")
  Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", targetComputer)
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileName$", "TestFileName.exe")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDirectory$", "TestFileDirectory")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDescription$", "TestFileDescription.exe")

    'Class Instance has now been created so the AddInstance method of the CreateDiscoveryData class is used to add
    'the completed instance.  From there the script returns the discovery data to OpsMgr for further processing.
  Call oDiscoveryData.AddInstance(oInst)
  Call oAPI.Return(oDiscoveryData)
End If
Importing this management pack into OpsMgr results in the correct system being discovered, as shown in Figure 8. Note that each of the properties (attributes) defined in the script are displayed in the UI with the associated values.
Figure 8 Discovery via a script
When you look at the script, you will see that the value for a discovered item can be passed explicitly or through a variable. And keep in mind that, as indicated earlier, if the Display Name field for the particular property (attribute) in the class had been left blank, the column headers FileName, FileDirectory, and FileDescription (see Figure 8) would have been blank as well.

Additional Considerations
Keep Track of Versions When you are working in the Authoring Console, it is common to generate multiple revisions before you're finished. You must make sure that each revision for use in OpsMgr is saved with the version number incremented.
The version number is accessed in the authoring Console by selecting File | Management Pack Properties. Failing to increment the version number may result in the importation of a new management pack over an existing one with the same version numbers. This can lead to confusion during import.
Sealed or Unsealed? When the management pack is completed, you'll need to decide whether it should be sealed for production purposes or left unsealed. There are advantages to leaving the management pack unsealed, such as the ability to store overrides in the management pack directly. But there are more compelling reasons to seal a custom management pack before introducing it into the production environment:
  • Sealing a custom management pack for use in production is a best practice.
  • Sealing allows for tighter version control and tighter change control.
  • Sealing allows for the use of the same operational procedures for custom as well as commercial management packs. Requiring different procedures, such as where to place overrides for custom versus commercial management packs, introduces a lot of confusion.
  • Classes created in an unsealed management pack will be visible and usable only by other MPOs stored in the same management pack. Sealing allows objects to be usable regardless of where the MPO is stored.
  • A library of unsealed "source" management packs can be maintained under control of the OpsMgr administrators to prevent accidental or unintended changes.
Fully understanding targets is instrumental to success with OpsMgr. A poster called Rule and Monitor Targeting Best Practices is available in .pdf format at go.microsoft.com/fwlink/?LinkId=125048. You'll find it to be a very helpful reference for understanding different targets and when they might be appropriate to use.

Steve Rachui is a Dedicated Support Engineer with the Premier Field Engineering group at Microsoft. He has supported SMS since version 1.2 and MOM from version 2000. Steve can be reached at steverac@microsoft.com.


Windows Server 2008
Presentation Virtualization with Enhanced Terminal Services
Joshua Schnoll
At a Glance:
  • New features in Windows Server 2008 Terminal Services
  • Using TS Gateway for remote access
  • Load-balancing with TS Session Broker

Contents
What's New in Terminal Services
Security Features
User Experience Features
Easier Remote Access
Terminal Services Gateway
TS Session Broker
Virtualization is a hot term these days, though most of the time people think it relates only to virtual machines and the virtualization of operating systems. However, Terminal Services has been abstracting the presentation layer of remotely run applications and desktops since the release of Windows NT 4.0. Terminal Services has come a long way since that time, and Windows Server 2008 delivers a mature, robust presentation virtualization platform. I will focus the key areas of improvement in Terminal Services.

What's New in Terminal Services
Terminal Services in Windows Server 2008 has many new features and capabilities:
Terminal Services RemoteApp One of the great changes in Windows Server 2008 is the ability to remote a single application. In previous versions of Terminal Services, the entire remote desktop was transmitted, even if you only wanted to access a single application. This was often confusing to users because some applications appeared on the remote desktop (via Terminal Services) and some on the local desktop—and remembering which desktop had which application could be challenging. Now, applications accessed through Terminal Services look and behave as if they were running on the end user's local computer.
Terminal Services Web Access High on everyone's wish list was a simple way for end users to launch applications. TS Web Access meets that need by allowing administrators to publish individual applications to a Web page. TS Web Access includes a default Web page that can be deployed right out of the box, but it also can be customized and integrated into a SharePoint site. In order to launch a TS RemoteApp with TS Web Access, the user visits a Web page (accessed either from the Internet or intranet), sees a list of all the available applications, and clicks on the one he wants to launch.
In Windows Server 2003, a separate ActiveX control called the Remote Desktop Web Connection (RDWC) was required to enable a connection from a browser. Now the control has been built right into the main Remote Desktop Connection (RDC) client, so nothing needs to be downloaded or installed to the client. Moreover, the full Remote Desktop Protocol (RDP) feature set is supported, which wasn't the case with the old RDWC client.
Terminal Services Gateway TS Gateway is one of the most significant new features in Windows Server 2008. RDP traffic runs over port 3389, and one of the major issues administrators had when deploying a terminal server to users outside the firewall was having to either open that port in the firewall (not recommended) or use a separate VPN solution (costly). With TS Gateway, the RDP traffic is tunneled over HTTPS (port 443) to establish an encrypted connection between remote users on the Internet and the terminal server (or remote PC). Even better, the scenario works great even if the user or terminal server is located behind a network address translation (NAT) traversal-based router.
TS Gateway can be coupled with another feature of Windows Server 2008, Network Access Protection (NAP), to help ensure the health of client machines before granting access to Terminal Services resources.
Terminal Services Session Broker Windows Server 2000 introduced Network Load Balancing (NLB) and, though it works really well for Web servers, it wasn't ideal for load balancing Terminal Services. The new TS Session Broker provides a great alternative by expanding the Session Directory capabilities of Windows Server 2003 to enable session-based load balancing.
With TS Session Broker, new sessions are distributed to the least-loaded server within the farm and users don't have to know where a session was established in order to reconnect to an existing session. IT managers can use the feature to map the IP address of each Terminal Server to a single DNS entry. This configuration can also provide fault tolerance; if one of the farm servers is unavailable, users will connect to the next least-loaded server in the farm.
Terminal Services Easy Print Printing has historically been the bane of many an administrator's existence in a Terminal Services environment. With matching print drivers required on both server and client machines, end users had less flexibility to install printers while administrators had to worry about managing print drivers on the server. With TS Easy Print, in contrast, users can now reliably print from TS RemoteApp or a full desktop session to a local print device, whether it is attached directly or via a network. The best part is that printers can now be supported without it being necessary to install drivers on the terminal server.
When a user wants to print from a TS RemoteApp program or desktop session, he will see the full printer properties dialog box from the local client and have access to all the printer functionality (such as watermarks, collating, and stapling). When the user prints, the print job is rendered with the Microsoft XPS file format on the server and sent to the client. Furthermore, with TS Easy Print, administrators can use Group Policy to limit the number of printers redirected to just the default printer, thereby reducing overhead and improving scalability.
Those are the "big ticket" features in Windows Server 2008. We will revisit TS RemoteApp, TS Web Access, TS Gateway, and TS Session Broker later in this article. First, let's take a look at some other great but less prominent features in this release.

Security Features
Security has been beefed up in the new release of Terminal Services.
Network Level Authentication (NLA) and Server Authentication (SA) With previous versions of TS, a denial-of-service or man-in-the-middle attack could have been launched against the logon screen of the terminal server, as users were presented with the logon screen after clicking Connect on the RDC client. Now NLA authenticates the user, client machine, and server credentials against each other before a TS session is spun up on the server and the logon screen is presented to the user. Server Authentication uses Transport Layer Security (TLS) to help ensure that clients are connecting to a legitimate terminal server and not some rogue machine.
Single Sign-On Users want to be able to use one set of credentials (a user-password combination or a smart card and PIN combination) to authenticate just once, and not to be asked over and over for those credentials each time they want to use a new resource. With this release, domain-joined machines running Windows Vista or Windows Server 2008, connecting to a Windows Server 2008-based terminal server or TS Gateway, can now utilize single sign-on.
System-Level Hardening Both Windows Vista and Windows Server 2008 have new system-level hardening, which basically modularizes components of the operating system and runs them at lower privilege levels. In Terminal Services, this feature was implemented by splitting the core TS engine (termsrv.dll) into two separate components (lsm.exe, the core session manager, and termsrv.dll for remote connectivity).
Previously, termsrv.dll ran at the higher system privilege level. Now, only one-third of the original termsrv.dll code runs at that level in the new lsm.exe; the remaining two-thirds run at the much lower network service privilege level. This change significantly reduces the attack surface compared to Windows Server 2003.

User Experience Features
A number of improvements help users:
Custom Display Resolutions With the expansive growth of large monitors and a wider variety of display resolution ratios, Windows Server 2008 Terminal Services steps up to meet your needs.
The end user has the ability to set custom display resolutions (up to 4096 x 2048) or change the ratios to 16:9 or 16:10 to get a widescreen experience. All types of new monitor configurations can be supported, such as monitors with resolutions of 1680 x 1050 or 1920 x 1200. This is a great improvement over Windows Server 2003, which supported a maximum resolution of 1600 x 1200 and only 4:3 display resolutions ratios. You can set a custom display resolution from the RDC client dialog box, in an .rdp file, or from a command prompt.
In order to set a custom display resolution in an .rdp file, open the .rdp file in a text editor and add or change the following settings (note that <value> is the resolution, such as 1680 or 1050):
desktopwidth:i:<value>
desktopheight:i:<value>
To set a custom display resolution from a command prompt, use the mstsc.exe command with the following syntax (note that <width> and <height> are the resolution, such as 1680 or 1050):
mstsc.exe /w:<width> /h:<height>
Monitor Spanning Remote desktop sessions are now able to span multiple monitors. There are a few prerequisites for this feature to work properly:
  • All monitors must use the same resolution. For example, two monitors using 1024 x 768 can be spanned. But one monitor at 1024 x 768 and one monitor at 800 x 600 cannot be spanned.
  • All monitors must be aligned horizontally (that is, side-by-side). There is currently no support for spanning multiple monitors vertically on the client system.
  • The total resolution across all monitors cannot exceed the maximum resolution of 4096 x 2048.
To enable monitor spanning in an .rdp file, open the .rdp file in a text editor and add or change the following settings (note: if <value>=0, monitor spanning is disabled, if <value>=1, it is enabled):
Span:i:<value>
To set monitor spanning from a command prompt, use the mstsc.exe command with the following syntax:
mstsc.exe /span
Desktop Experience Desktop Experience makes a Terminal Services desktop much more like the Windows Vista desktop experience. This feature adds a number of components to the remote desktop, including Windows Media Player 11, desktop themes, and photo management. Here's how to enable Desktop Experience:
  1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.
  2. Under the Features Summary, click Add Features.
  3. On the Select Features page, select the Desktop Experience checkbox and then click Next.
  4. On the Confirm Installation Selections page, verify that the Desktop Experience feature will be installed and click Install.
  5. On the Installation Results page, you are prompted to restart the server to finish the installation process. Click Close, and then click Yes to restart the server.
Once the server has restarted, you must then confirm that the Desktop Experience feature is installed.
Font Smoothing Font smoothing is the name for Terminal Services support for ClearType, which helps display computer fonts more crisply, especially on an LCD monitor. Font smoothing is enabled by default in Windows Server 2008, and it can be enabled when a client computer connects through a checkbox in the Remote Desktop Connection, as shown in Figure 1.
Figure 1 Enabling font smoothing
You should note that font smoothing increases the bandwidth (from 4 to 10 times, depending on the scenario) used between the client computer and the terminal server. This increase in bandwidth occurs because ClearType fonts are remoted as bitmaps instead of glyphs, which RDP handles much more efficiently.
Display Data Prioritization With Windows Server 2003, printing a large job could often make your on-screen experience suffer. Display data prioritization automatically controls virtual channel traffic so that display, keyboard, and mouse data is given a higher priority over other traffic, such as printing or file transfers. This prioritization is designed in order to ensure that your screen, keyboard, and mouse performance is not impacted by bandwidth-intensive actions, such as large print jobs.
Out of the box, the setting is 70:30. Display and input data are allocated 70% of the bandwidth while all other traffic, such as file transfers or print jobs, will be allocated 30%.
You can adjust the settings by making changes to the registry of the terminal server. To do so, change the value of the following entries under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD subkey:
FlowControlDisable
FlowControlDisplayBandwidth
FlowControlChannelBandwidth
FlowControlChargePostCompression
If these entries do not appear, you can add them by right-clicking TermDD, point to New, and then click DWORD (32-bit) Value.
You can disable display data prioritization by setting the value of FlowControlDisable=1. If display data prioritization is disabled, all requests are handled on a first-in-first-out basis. The default value for FlowControlDisable=0.
You can set the relative bandwidth priority for display (and input data) by setting the FlowControlDisplayBandwidth value. The default value is 70; the maximum value allowed is 255. Likewise, you can set the relative bandwidth priority for other virtual channels (such as clipboard, file transfers, or print jobs) by setting the FlowControlChannelBandwidth value. The default value is 30; the maximum value allowed is 255.
The bandwidth ratio for display data prioritization is based on the values of FlowControlDisplayBandwidth and FlowControlChannelBandwidth. For example, if FlowControlDisplayBandwidth is set to 150 and FlowControlChannelBandwidth is set to 50, the ratio is 150:50. As a result of this, display and input data will be allocated 75% of the bandwidth.
The FlowControlChargePostCompression value determines if flow control will calculate the bandwidth allocation based on pre-or post-compression bytes. The default value is 0, which means that the calculation will be made on pre-compression bytes.
If you make any changes to the registry values, you need to restart the terminal server for the changes to take effect.
Plug and Play Device Redirection In Windows Server 2008 Terminal Services, device redirection has been enhanced and expanded. Now you can redirect Windows Portable Devices, specifically media players based on the Media Transfer Protocol (MTP) and digital cameras based on the Picture Transfer Protocol (PTP).
This functionality can be enabled with the Options button in the Remote Desktop Connection. When it's enabled, a list of supported Plug and Play devices that are currently plugged in will show up. Unsupported devices will not appear. You can also select the option to redirect devices that have not been plugged in yet. Figure 2 shows how to enable these from the RDC client.
Figure 2 Enabling devices that are not yet plugged in
When the session to the remote computer is launched, you should see the Plug and Play device that is redirected get automatically installed on the remote computer—Plug and Play notifications will appear in the taskbar. After the redirected Plug and Play device is installed, it is available for use in your session with the remote computer. For example, if you are redirecting a Windows Portable Device such as a digital camera, it can be accessed directly from an application such as the Scanner and Camera Wizard on the remote computer.
You can control Plug and Play device redirection by using either of the following Group Policy settings:
  • Do not allow supported Plug and Play device redirection located in Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Device and Resource Redirection.
  • The policy settings located in Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions.
You can also control Plug and Play device redirection on the Client Settings tab in the Terminal Services Configuration tool (tsconfig.msc) by using the Supported Plug and Play Devices checkbox.

Easier Remote Access
I mentioned earlier that TS RemoteApp lets users remote a single application and TS Web Access lets them access applications easily from a Web page; now let's take look a little closer at these features and at some of the configuration details.
TS RemoteApp RemoteApp programs can be deployed to user desktops through a variety of methods. In addition to TS Web Access, you can also:
  • Create a Remote Desktop Protocol file.
  • Create a program icon on the desktop or Start menu via a previously distributed Windows Installer (.msi) package.
  • Execute a file where the file name extension is associated with a RemoteApp program. This can be configured by the administrator with a Windows Installer package.
For more information on how users can access RemoteApp programs, see "How Should I Deploy RemoteApp Programs?" in the Windows Server 2008 TS RemoteApp Step-by-Step Guide at go.microsoft.com/fwlink/?LinkID=84895.
TS Web Access TS Web Access enables the deployment of RemoteApp programs from a single server or a farm of terminal servers. The TS RemoteApp Manager provides a very quick and efficient process for publishing applications into TS Web Access—first you install Terminal Services, then you install the applications you want to host.
Use TS RemoteApp Manager to add RemoteApp programs that are enabled for TS Web Access. Next, install TS Web Access on the server to which you want users to connect over the Web. Add the computer account of the TS Web Access server to the TS Web Access Computers group on the terminal server. Finally, configure the TS Web Access server to populate its list of RemoteApp programs from a single terminal server or single farm.
Once the applications have been installed through the traditional method or delivered to the terminal server with Application Virtualization (formerly known as SoftGrid), it is very straightforward to publish those applications to TS Web Access. The RemoteApp Wizard walks the administrator through a few quick and easy steps and the applications then appear on the list of published RemoteApp Programs.
By default, the applications will be published to TS Web Access. RemoteApp Manager will then show you a list of applications that have been published and all the applications that are available to users through TS Web Access.
Now let's take a quick peek at the out-of-the-box end user experience. The first tab in TS Web Access shows the icons of all the applications that are published (see Figure 3); the second tab lets users connect to a specific desktop computer using the Web front end. As noted earlier, this Web interface is completely customizable and the "TS Web Access Step-by-Step Guide: Customizing TS Web Access by Using Windows SharePoint Services," available at go.microsoft.com/fwlink/?LinkID=111241, is a great resource that walks you through a customization with SharePoint Services.
Figure 3 Entering settings for the .rdp files
Other Deployment Methods Besides using TS Web Access, you can deploy RemoteApp programs with .rdp files or Windows Installer packages. Those packages can be distributed through file sharing, or through Microsoft Systems Center Operations Manager or Active Directory software distribution. The next section will walk you through the key steps to create the right packages for application distribution.
To prepare RemoteApp programs for distribution through a file share or some other distribution mechanism, you must install Terminal Services and the apps you want to publish, and verify remote connection settings. The TS RemoteApp Wizard will help you to add RemoteApp programs and configure global deployment settings. Then you can create .rdp files or Windows Installer packages.
Let's walk quickly through the RemoteApp Wizard. In Step 1, you configure the Terminal Server, TS Gateway, and Certificate settings for the .rdp files (see Figure 4).
Figure 4 Setting options for the program package
In Step 2, you specify where the shortcut icons will appear on the desktop or Start menu and/or associate client file extensions so that local files will launch with the RemoteApp (see Figure 5).
Figure 5 Viewing RemoteApp programs in TS Web Access
In the final step, the RemoteApp Wizard opens the Packaged Programs folder so you can easily deploy these packaged applications to client machines with the distribution software of your choice (see Figure 6).
Figure 6 Programs packaged for deployment

Terminal Services Gateway
Now I am going to examine how TS Gateway can help your remote users get access to applications, data, or desktops from outside the firewall. Figure 7 shows at a very high level the typical scenario for deploying TS Gateway in order to provide access to users through the Internet.
Figure 7 Worker connecting from laptop at home to a corporate network
In essence, the TS Gateway sits in the network perimeter and tunnels the RDP traffic over HTTPS. Alternatively, you could place an SSL terminator (such as Microsoft Internet Security and Acceleration Server—ISA) in the network perimeter and forward the incoming RDP traffic to your TS Gateway on the other side.
Here are the steps illustrated in Figure 7:
  1. A user on a home laptop can connect via the Internet by clicking on either an RDP file or a RemoteApp program icon located on the desktop, on the icon of a TS RemoteApp published via TS Web Access, or by opening the Remote Desktop Connection client.
  2. An SSL tunnel is established between the home laptop and the terminal servers using the TS Gateway server's SSL certificate. Before a connection is established, the user must be authenticated and authorized according to Terminal Services connection authorization policies (TS CAPs) and Terminal Services resource authorization policies (TS RAP). Once the TS RAP and TS CAP polices (discussed below) have been enforced, the user can open a session.
  3. The home laptop exchanges encrypted RDP packets encapsulated within SSL with the TS Gateway over port 443. The TS Gateway forwards the RDP packets to terminal server over port 3389.
You can create a farm of TS Gateway servers for larger installations, but you will need a separate solution (such as NLB or a third-party load balancer) in order to balance the load among the server farm systems. TS Session Broker does not handle load balancing for TS Gateway server.
Now let's take a quick look at how to deploy this functionality. In a nutshell, you need to obtain and configure a certificate for the TS Gateway server and create the two types of authorization policies I mentioned earlier: TS CAP and TS RAP.
Obtaining a Certificate You can either use an existing certificate or request a new one. A valid certificate is required for the TS Gateway to function and you have a choice during installation to import a certificate or create a self-signed certificate.
The self-signed option is good if you are doing internal testing, but proper deployment requires a certificate issued by an enterprise certificate authority (such as VeriSign). Once you have the certificate installed, you can then consider your deployment authorization policies.
Authorization Policies TS CAPs determine who can connect to the TS Gateway and specify under what conditions users can connect. For example, you can specify that a user group that exists on the local TS Gateway server or in Active Directory can connect to a TS Gateway and that group members must use smart cards.
TS RAPs, on the other hand, determine which internal resources users can access via the TS Gateway. For example, you can create a computer group (such as a farm of terminal servers) and associate it with your TS RAP.
You need to create both TS CAPs and TS RAPs to give remote users access to internal resources, as a user must meet the conditions of at least one TS CAP and one TS RAP in order to have access. Administrators can create both types via the TS Gateway Manager, as shown in Figure 8 and Figure 9.
Figure 8 Creating a connection authorization policy
Figure 9 Creating a resource authorization policy
Together, TS CAPs and TS RAPs provide two different types of authorization that allow you to configure a more finely tuned level of access control to computers on an internal network. For more information, see the "Terminal Services Gateway Step-by-Step Guide" at go.microsoft.com/fwlink/?LinkID=85872.

TS Session Broker
The last topic I'd like to cover is Session Broker, which provides a simple-to-deploy, session-based, load-balancing solution. The functionality builds on the Session Directory capabilities of Windows Server 2003 that reconnected a user to an existing session, and adds it the ability to create a new session on the least-loaded server in the farm.
Let's look at a typical scenario in which all terminal servers in a farm have host resource records in DNS that map to a particular terminal server farm name, say Farm1. Any terminal server in the farm can therefore act as a redirector and process the initial connection requests.
Suppose a user starts an RDC client, specifying a terminal server farm named Farm1. The client contacts the DNS server to resolve the Farm1 name to an IP address, and the DNS server, which is configured to use round robin to load balance the initial connection requests, returns a list of IP addresses that are registered for Farm1.
The client sends the connection request to the first IP address on the list that is returned by the DNS server. The terminal server with that address acts as the redirector, querying the TS Session Broker server to determine which terminal server the client should log on to. The TS Session Broker server checks its database, and if the user has an existing session, Session Broker returns the IP address of that terminal server. If the user does not have an existing session, Session Broker determines which terminal server in the farm has the lowest load (based on the number of sessions and the relative server weight value) and then it returns the IP address of that particular server.
The redirector sends the client that IP address and the client then sends the connection request to that server, which processes the logon request and notifies TS Session Broker of the successful logon.
Note that while any load-balancing mechanism can be used to distribute the initial connections, DNS round robin is the easiest mechanism to deploy. However, be aware that DNS round robin does have some limitations, including the caching of DNS requests on the client, which can result in clients using the same IP address for each initial connection request, and the potential for a 30-second timeout delay if a user is redirected to a terminal server that is offline but still listed in DNS.
Deploying TS Session Broker Load Balancing with a network level load-balancing solution such as NLB or a hardware load balancer avoids the limitations of DNS while still taking advantage of TS Session Broker features. The TS Session Broker load-balancing feature lets you to assign a relative weight value to each server, which helps to distribute the load between more powerful and less powerful servers in the farm. For example, if you had a server that could handle twice as many sessions as another server in the farm, you would give that server a 200 weight relative to the other at 100.
TS Session Broker Load Balancing sets a limit of 16 for the maximum number of pending logon requests to a particular terminal server. This feature helps to prevent overwhelming a single server with new logon requests when, for example, you add a new server to the farm or when you enable user logons on a server where they had been previously denied.
Additionally, a new "server draining" mechanism is provided that lets you prevent new users from logging on to a terminal server that is scheduled to be taken down for maintenance. If new logons are denied on a particular terminal server, TS Session Broker will allow users with existing sessions to reconnect, but will redirect new users to terminal servers that have been configured to allow new logons.
For more information, see the "TS Session Broker Load Balancing Step-by-Step Guide" at go.microsoft.com/fwlink/?LinkID=92670. There's not enough space here for me to talk more about the new features of Windows Server 2008 TS. However, there is much more content, including in-depth webcasts, on the Terminal Services Web site. In order to learn more, you should head over to technet.microsoft.com/ts.

Joshua Schnoll has more than 15 years of marketing and technology experience, focusing the last 6 years on server-based computing. He is the worldwide Senior Product Manager for Windows Server Terminal Services. Before coming to Microsoft, he held several positions with Sun Microsystems, including driving product marketing for Sun Ray ultra-thin clients.


SQL Server 2008
Tracking Changes in Your Enterprise Database
Paul S. Randal
At a Glance:
  • The need for tracking changes
  • Tracking changes in SQL Server 2005
  • Change tracking in SQL Server 2008
  • Change data capture in SQL Server 2008

Contents
How You Track Changes in SQL Server 2005
Easier Ways to Track Changes in SQL Server 2008
How Change Data Capture Works
How Change Tracking Works
Wrapping Up
For developers, one difficult problem in SQL Server is tracking what data has changed in a database. An even greater challenge is architecting a simple solution that doesn’t heavily impact workload performance and isn't difficult to create, implement, and manage. So why go to all the trouble to track changes? Is tracking changes really worth all this effort? Two commonly cited examples are to support updates to a data warehouse and to support the synchronization of heterogeneous, occasionally connected systems.
A data warehouse usually has some representation of the tables in the Online Transaction Processing (OLTP) database, but the table schemas may actually be quite different. This means that there needs to be an ETL (extract, transform, load) process that moves data from the OLTP database to the data warehouse.
Video
Watch Paul Randal demonstrate how you can track changes in your database using the new Change Data Capture feature in SQL Server 2008.

I can think of three possibilities for doing this. The first is to refresh the entire data warehouse periodically. This is clearly impractical for large data volumes and also means that updates to the data warehouse are not continuous. The second method is to use a partitioning scheme in the OLTP database to allow the ETL process to work only on data that is new since the previous ETL process. This method only works for data inserts, not updates or deletes, and requires a complex mechanism to manage partition boundary definition and switching partitions. The third method is to track changes to the OLTP data and only perform the ETL process using the changed data. This is the most efficient method in terms of data volume.
Mobile devices are ubiquitous in today's business environment, which means that dealing with occasionally connected systems is a requirement. In terms of database systems, the problem is how to efficiently update a data store on a device that does not connect frequently, especially when the data store itself may be small and radically different in schema from the main database.
Consider a mobile sales rep who is responsible for a portion of a very large product catalog. Every night she connects her handheld device to the main database to download the latest data—all the changes to that portion of the product catalog, simplified for storage on a handheld device. The data transfer should be as efficient as possible.
Now, you could have the database system prepare the entire relevant portion of the product catalog for download to the device and have the device download it. In other words, all the data is downloaded every time the device connects, even if the data hasn't changed. This is obviously a rather inefficient approach.
Another approach is to have the database system track changes to the relevant portion of the product catalog. Then, when the handheld device connects, it asks for the data that has changed since the last time it connected. In this solution, the database system only has to prepare a subset of the data and the download is as efficient as possible.
Another reason for tracking changes is to support auditing, which is essential these days. Auditing tracks the changes being made as well as when the change occurred and who made the change. This really takes things to another level, with rigid constraints around durability, security, and correctness of a complete audit trail.
The technologies that were designed for tracking data changes in SQL Server 2008 were not intended to support auditing; however, SQL Server 2008 offers a new feature, which is called SQL Server Audit, that was designed specifically for auditing. Rick Byham discussed the SQL Server Audit feature in his "SQL Server 2008: Security" article from the April 2008 issue of TechNet Magazine (available at technet.microsoft.com/magazine/cc434691).
As you can see, there are a number of compelling reasons to track changes to your data. So the important question is, how best can tracking be done?

How You Track Changes in SQL Server 2005
With SQL Server 2005 (and earlier versions of SQL Server) there is not a simple, canned solution. So for these platforms, developers have had to create custom solutions for their applications, usually involving timestamp columns, DML (Data Manipulation Language) triggers, and extra tables. These solutions, however, present a variety of potential problems. For instance:
  • The addition of timestamp columns causes the table schema to change (with possible knock-on effects in stored procedures and other code).
  • A DML trigger is implicitly part of the transaction containing the DML by which it is triggered, so its execution time will increase the length of the transaction. The more complex a trigger, the longer it will take to execute and so the higher the detrimental effect on workload performance. DML triggers used for tracking changes need to process the inserted and deleted tables to harvest all the changes and then insert them into another tracking table.
  • The tracking table needs to be managed in some way to avoid its growing out of control, which may require you to create something like an Agent job to periodically trim old data.

Easier Ways to Track Changes in SQL Server 2008
SQL Server 2008 introduces two new technologies that make it much easier to track changes to data: change tracking and change data capture. Both features track data that has changed (as well as use the insert, update, or delete operations to track exactly how the data was changed), and they eliminate the need for custom solutions. Those similarities aside, their mechanisms and what exactly they track are actually quite different.
Change data capture uses an asynchronous mechanism that tracks all the changes that occur to a table (or a defined set of columns of the table), including the column values themselves. This is designed for scenarios like the data warehouse ETL process I described previously.
Figure 1 illustrates change data being consumed in time slices. The change data capture mechanism extracts the changed data into a set of tables, with the most recent changes being at the top of the table. The ETL process can then query the tables holding the change data for all changes that occurred within a set time period. This mechanism allows the ETL process to limit the amount of data that must be consumed in each batch.
Figure 1 Historical change data being consumed in time slices
Change tracking, on the other hand, uses a synchronous mechanism that tracks only that a particular row changed in a table (and optionally the list of columns that changed). This is designed to address such problems as the occasionally connected system scenario I described previously. This approach is illustrated in Figure 2.
Figure 2 An occasionally connected system using change tracking data
Both features introduce an increase in I/O and logging, but this is true with custom solutions as well—the change data has to be stored somewhere. What makes these two features potentially different from a custom solution is that the tables used to store the change data must be in the same database as the tables being tracked. This means all the change data will be included in backups and potentially transmitted over the network by log shipping or database mirroring.
In terms of development, these two features should remove a lot of the complexity from tracking changes. There are no table schema changes or triggers required for either technology. Both technologies have configurable, automatic cleanup processes, order changes by transaction commit times, and provide built-in functions to retrieve change information.
From the management perspective, there are pros and cons to each approach. As with any technology, there is a lot of information you must understand before you develop and deploy solutions that use these features. In the rest of this article I'll give an overview of each of these features, touching on how they work and the practical points to consider before using them in production.

How Change Data Capture Works
Change data capture doesn't do anything as part of the transactions that change the table being tracked. Instead, the insert, update, and delete operations are written to the transaction log, as normal, and periodically harvested from the log. Harvesting is performed by a SQL Agent log reader job, and the harvested operations are stored in a separate table called a change table. At some later point, the change table can be queried to obtain the change data using one of two functions. The combination of the change table and the two functions is called a capture instance. Figure 3 shows the flow of data using change data capture to drive a data warehouse ETL process.
Enabling change data capture is a two-stage process. First a member of the sysadmin fixed server role must enable change data capture for the database using sys.sp_cdc_enable_db. Then a member of the db_owner fixed server role must enable change data capture on a specific table using sys.sp_cdc_enable_table. These security requirements are due to the potential for high disk usage if change data capture is misconfigured. It makes perfect sense that a table owner cannot enable the feature and surprise a database administrator with extra disk usage.
When change data capture is enabled for a database, a few things are added to the database, including a new schema (called cdc), some metadata tables, and a trigger to capture Data Definition Language (DDL) events. (One capability that I think is cool is that you can get a list of the DDL changes to a table.)
Enabling change data capture also creates the capture instance for the table—the change table and up to two functions to return change data. The change table name is the same as the capture instance, with _CT appended. The first function is always created and is the one used to return change data from the change table. The second function is created if the option to allow net changes is specified. This means that only the final result of all the captured changes is returned, rather than all the intermediate changes that the first function returns. The two function names are, respectively, fn_cdc_get_all_changes_ and fn_cdc_get_net_changes_, with the capture instance name appended. Note that (like the change tracking feature) this functionality requires the table to have a primary key or other unique index.
When you're dealing with the first table in the database to have change data capture enabled, two SQL Agent jobs may be created: the capture job and the cleanup job. I say "may be created" because the capture job is the same as the one used for harvesting transactions in transactional replication. If transactional replication is already configured, then only the cleanup job will be created and the existing log reader job will also be used as the capture job. This is good because having two log reader jobs would very quickly lead to contention problems with the log and hence performance problems. Either way, SQL Agent must be running if you want to use change data capture.
The logic inside the log reader automatically copes with tables being enabled and disabled for change data capture and alters what is harvested from the transaction log accordingly. One major point to note here is that once change data capture is enabled, the transaction log behaves just as it does with transactional replication—the log cannot be truncated until the log reader has processed it. This means a checkpoint operation, even in SIMPLE recovery mode, will not truncate the log unless it has already been processed by the log reader.
Also, if the BULK_LOGGED recovery model is used to reduce logging, change data capture will force everything to become fully logged, except for index create/drop/rebuild operations. If you have never experienced such behavior, beware that this may cause transaction log size problems, especially if the capture job defaults are changed so the log isn't processed as frequently.
By default, the capture job runs continuously, scanning the log every five seconds and processing a maximum of 500 transactions from the log. Also by default, the cleanup job runs every day at 2 A.M. and removes all change data entries older than three days from the change tables. You can change these settings using the sys.sp_cdc_change_job procedure, and then changes will not take effect until you restart the jobs using sys.sp_cdc_stop_job and sys.sp_cdc_start_job.
Although the log reader process will usually have a low impact on system performance, it is possible on heavily loaded OLTP systems with a lot of changing data that the addition of just one log reader process can cause contention on the transaction log. The actual contention would be caused by the disk heads having to move back and forth between the point at which the log is being written to by transactions and the point at which it is being read by the log reader process. In this case, it may be necessary to change the frequency at which the capture job runs to ensure OLTP performance will not suffer. This, however, creates a classic disk space versus performance trade-off—the log will continue to grow until the capture job processes it.
The same problem occurs if the cleanup job frequency or change data retention periods are changed—the change tables will continue to grow until the change data is cleaned. This leads to a wholesale design consideration of what gets tracked and how long it is retained. Important things to consider here include:
  • The required column list for the capture instance. When more columns are captured, more change data is inserted into the change tables.
  • The amount of disk space used by the change tables.
  • The frequency at which the process runs that consumes the change data. Keep in mind that the data can't be deleted if it hasn't been used yet.
  • The frequency that the cleanup process runs—there may be so much change data generated that the cleanup process that deletes it can only run on the weekend, for example, because otherwise it generates too much transaction log.
Change data capture can be set up to simply track all changes to a table or to track a subset of the columns in a table. Using a subset can be useful if some of the unimportant columns are very wide varchar columns or Binary Large Object (BLOB) columns (such as text, image, or XML); otherwise, the space used by the change table could grow unwieldy very quickly.
Given the increased potential for disk space usage, the filegroup location of the change table can be set when change data capture is enabled. This allows easier management of the underlying disk space and means that all the change data can potentially be stored on a volume with a less expensive RAID level than the main database. Also, while the cleanup job settings apply to all capture instances, an individual capture instance can be separately cleaned at any time if disk space becomes an issue. You can easily monitor disk space usage using sp_spaceused on the capture tables.
The actual row written to the change table contains metadata about the transaction (the commit log sequence number, or LSN), as well as the order within the transaction that the change occurred, what the operation was, a bitmask of which columns were changed, and the actual column values.
DDL changes are unrestricted while change data capture is enabled. However, they may have some effect on the change data collected if columns are added or dropped. If a tracked column is dropped, all further entries in the capture instance will have NULL for that column. If a column is added, it will be ignored by the capture instance. In other words, the shape of the capture instance is set when it is created.
If column changes are required, it is possible to create another capture instance for a table (to a maximum of two capture instances per table) and allow consumers of the change data to migrate to the new table schema. But care should be taken when doing this because two capture instances for a tracked table mean twice the amount of disk space, I/Os, and logging.
Without going into too much depth, changes are retrieved from the change tables using the functions I've described. The functions take a start LSN and end LSN, and there are other functions supplied that allow you to convert a regular time into an LSN. When retrieving updates, you can even specify whether to see the before and after values, or just the before. There is a screencast of me using change data capture available at www.technetmagazine.com/video.

How Change Tracking Works
As I've mentioned, change tracking is a synchronous process and is a lot less complex than change data capture. It is part of the transaction that makes a change to a row in a table being tracked, and the fact that the row has changed is tracked in a separate table. The table is what's called an internal table, and there is no control over its name or where it is stored. I don't consider this an issue, as there should be a lot less data in this table than in a change table used for change data capture. But there can still be disk space problems, as I'll explain in a moment.
The fact that change tracking is done synchronously means that there is extra processing done inside each transaction that changes the table being tracked. The effect on performance is similar to that when a non-clustered index exists on the table and must be updated with each change to the table. Transactions themselves are also tracked when they commit by a row in the internal sys.syscommittab table.
Change tracking is enabled and disabled using regular ALTER DATABASE and ALTER TABLE syntax, and it follows the same model as change data capture, where it must be enabled at the database level before the table level. The sequence of operations would look something like this:
ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON
  (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
GO
USE AdventureWorks2000;
GO
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING
  WITH (TRACK_COLUMNS_UPDATED = ON);
GO
The required permissions for enabling change tracking at the database and table levels are also different from those for enabling change data capture: db_owner and the table owner, respectively. When change tracking is enabled at the database level, the retention period can be set as well as whether change data is automatically cleaned up. The default retention period is 2 days, with a maximum of 90 days and a minimum of one minute.
Automatic cleanup is also turned on by default. When making changes to these settings, you need to evaluate the same trade-offs as I discussed with change data capture—basically disk space and performance against application needs.
By default, what is captured for each row is just that it changed. This is done by making a note of the primary key of the row that changed (which means that change tracking on a table requires that it has a primary key), along with a version number (once a database is enabled for change tracking, a version number is instituted, which allows ordering of operations), and the type of operation that made the change. You can also optionally track which columns changed; this requires 4 bytes per changed column.
Disk space monitoring is slightly different with change tracking, since the change data is stored in internal tables. To find the names of the internal tables being used, simply use the sys.internal_tables system catalog view:
SELECT [name] FROM sys.internal_tables
  WHERE [internal_type_desc] = 'CHANGE_TRACKING';
GO
Then pass the name into sp_spaceused to see how much disk space is being used.
Unlike with change data capture, when change tracking is enabled, there are restrictions on the DDL that can be performed on a table being tracked. The most notable restriction is that the primary key cannot be altered in any way. The other restriction worth calling out here is that an ALTER TABLE SWITCH will fail if either table involved has change tracking enabled. This is most likely due to the fact that it doesn't make sense to automatically start or remove change tracking for a partition being switched out of a change tracked, partitioned table, or a change tracked table being switched into a partitioned table, respectively.
Changes are retrieved from the internal change tables using a new CHANGETABLES (CHANGES …) function. This takes the name of the change tracked table plus the version number from the previous time it was used and returns information about all rows that have changed since that previous time. There are various functions to find the current and oldest valid version. The application can then use the information that is returned to query the table being change tracked to get the actual column values. This, of course, is a multi-step process—you get the current version, use that version to query change tracking, and then query the actual tables for the column data corresponding to that version.
On a constantly changing system, it is possible to get inconsistent or incorrect results unless some kind of unchanging view of the version, change data, and actual column data is maintained. To do this, you can use snapshot isolation and wrap the multi-step process in an explicit transaction. This works well but has potential drawbacks. Snapshot isolation can affect the workload performance, and it affects the performance and space usage of tempdb. You can find more details about this at technet.microsoft.com/library/cc280358.

Wrapping Up
Figure 4 provides a side-by-side comparison of change tracking and change data so you can get a better idea of the major differences that DBAs will care about. You can see from the table that change data capture is much heavier weight than change tracking. It requires more care when deciding what to track because of the potential for fast growth in the size of the tracking table if, say, the table that is tracked contains BLOB columns or very wide rows. There is also the potential for transaction log management issues, as the log will not be truncated until the log reader has harvested records from the log.
Figure 4 Comparison between change tracking and change data capture
Feature | Change Tracking | Change Data Capture
Synchronous | Yes | No
Requires SQL Agent | No | Yes
Forces full logging of some bulk operations | No | Yes
Prevents log truncation | No | Yes, until log records harvested
Requires snapshot isolation | Recommended | No
Requires separate tables to store tracking data | Yes | Yes
Requires primary key | Yes | Not by default
Allows placement of tracking tables | No | Yes
Potential for space consumption issues | Some | Lots
Automatic cleanup process | Yes | Yes
Restrictions on DDL | Yes | No
Permission required to enable | Sysadmin | Database owner
Change tracking is not without its own requirements, however. For instance, a primary key is required, and it is strongly recommended that you use snapshot isolation when change tracking is enabled. Snapshot isolation itself can add significant workload overhead and requires much more careful management of tempdb.
There is one further issue that developers and DBAs need to cope with: disaster recovery. Although discussing this in depth is beyond the scope of this article, the topic of disaster recovery is too important to not at least mention here.
Both features play well with BACKUP and RESTORE. The problem comes when a database gets restored and is essentially taken back in time. How should the overall application/system behave? Custom solutions designed for tracking changes also face this problem, and it still needs to be considered when using SQL Server 2008.
As always, make sure you read through all the available documentation (technet.microsoft.com/library/bb418491) and any existing white papers before embarking on a design and deployment project that involves the new features to track changes. You need to first find out if any potential issues I haven't covered here may apply to you. You should also get details on the new monitoring SPs and Dynamic Management Views (DMVs).
Overall these new features are a huge advance over previous methods for tracking data changes. Now that they exist, you can be sure developers will want to use them in solutions that you manage.
There are important configuration and management issues to consider, and I hope this article has given you a solid overview of the technologies so you can anticipate and prepare for some of the issues I have discussed. If you have any feedback on this article or questions, go ahead and drop me a line at Paul@SQLskills.com.

Paul S. Randal is the Managing Director of SQLskills.com and a SQL Server MVP. He worked on the SQL Server Storage Engine team at Microsoft from 1999 to 2007. Paul wrote DBCC CHECKDB/repair for SQL Server 2005 and was responsible for the Core Storage Engine during SQL Server 2008 development. Paul is an expert on disaster recovery, high availability, and database maintenance and is a regular presenter at conferences around the world. He blogs at SQLskills.com/blogs/paul.


From the Editor Now What?
Joshua Hoffman

We've spent a lot of time over the past year talking about Windows Server 2008—what's new, what's interesting, how to get started. We've covered Active Directory, kernel changes, virtualization, and more, and we'll continue to do so. But you might ask, Now what?
Once you're finished deploying Windows Server 2008, is that it? Job well done? Can you just pack up your things and go home? If so, can you please drop me a note with the contact info for your HR department? I'd like to know where to send my resume.
No, chances are you don't get to just go home. Chances are you move right into answering the next questions: How do we monitor everything? How do we manage it? How do we roll out changes? How do we get alerted to problems (or more important, issues that have the potential to become problems)? And you need to be able to answer these questions. After all, one of the biggest mistakes we can make when implementing new technology is to give all the attention to deployment and forget the follow-through.
This month we aim to address that problem with some great content from Pete Zerger and Cameron Fuller who discuss how to use System Center to manage and monitor Windows Server 2008. Have a look, and make sure you're prepared to answer that all-important question—Now what?
Also in this issue, we have a follow-up to our special issue on virtualization last month. Joshua Schnoll writes about presentation virtualization—virtualizing the presentation layer with technologies such as Terminal Services and RemoteApp. And, just in case you missed our virtualization coverage last month, you can find it all at technet.microsoft.com/magazine/cc135968.
And, finally, I'd like to extend a special note of gratitude to David Gordon on behalf of the entire TechNet Magazine staff. For the past year, David has been the director of the Subscription and Software Services team at Microsoft, which is responsible not only for TechNet Magazine and MSDN Magazine but also for the Flash newsletters and the MSDN and TechNet software subscription programs. David has been a great leader for the magazine staff these past several months, and as he is now moving on to new, exciting challenges, we'd like to express our thanks to him.
Enjoy the issue, and don't forget to drop us a line with your feedback at tnmag@microsoft.com.
—Joshua Hoffman

Thanks to the following Microsoft technical experts: Gopal Ashok, Alex Balcanquall, Nino Bilic, Eric Charran, Baelson Duque, Brad Huges, Jeff Lilleskare, Corbin Meek, Michael Murgolo, Sanjeev Nair, Jim Truher, Dean Tsaltsas, Jason Tyler, and Manlio Vecchiet.


Letters Readers Speak Out

Processor Cores
I Just read the October 2008 article "Manage Your Virtual Environments with VMM 2008" (see technet.microsoft.com/magazine/cc836456). Is Virtual Machine Manager (VMM) required for managing Hyper-V? Is it possible to manage Hyper-V hosts without VMM and, if so, does that mean I won't get all the features of Hyper-V? Do I need to buy VMM to get all its features?
—Barry C.
VMM 2008 is not required to manage Hyper-V. You can manage all of your Hyper-V hosts using the Hyper-V Manager Microsoft Management Console (MMC) that comes with Hyper-V hosts (and is a download available for systems running Windows Vista). Hyper-V Manager can enable all functions of Hyper-V. VMM is a separate add-on that brings centralized, multiserver management along with additional features such as P2V, V2V, Templates, and integration with Operations Manager.
—Edwin Yuen, Technical Product Manager, Windows Enterprise Management, Division for System Center VMM

Microsoft Assessment and Planning Toolkit
After reading about the Microsoft Assessment and Planning (MAP) Toolkit in the October issue ("Essential Tools for Planning Your Virtual Infrastructure" at technet.microsoft.com/magazine/cc895647), I'm wondering if there are security issues I should know about?
—Louise E.
The MAP Toolkit is designed to operate securely to collect system resources and other hardware and device information about each desktop and server remotely without the use of any software agents on the individual machines. In addition, all passwords are encrypted and never persisted. All communications are encrypted and the tool supports both domain and local credentials.
—Jay Sauls, Senior Program Manager, Microsoft Solution Accelerators
—Baldwin Ng, Senior Product Manager, Microsoft Solution Accelerators Core Engineering Team

Firewalls
I just read your article "Essential Tools for Planning Your Virtual Infrastructure." With regard to firewall configuration, what do I have to know in order to use the MAP Toolkit?
—Richard K.
This tool will only work if Windows Management Instrumentation (WMI) traffic is allowed from the MAP computer to the inventoried machines. Many host- and software-based firewall products will block DCOM traffic across the network adapters on the computer. To enable remote WMI access, you need to make sure that the TCP/UDP ports are opened up on the computer running the software firewall. You will need to ensure the following configuration is implemented prior to running the tool:
  • Enable Remote Administration exception: The "Remote Administration exception" needs to be enabled for computers when the Windows Firewall is enabled. This exception opens TCP port 135. If you have another host firewall installed then you will need to allow network traffic through this port. You should delete this exception after the MAP operation is completed.
  • Enable File and Printer Sharing exception: The "File and Printer Sharing" exception must be enabled for computers when the Windows Firewall is enabled. This exception opens TCP ports 139 and 445, and UDP ports 137 and 138. If you have another host firewall installed then you will need to allow network traffic through these ports. You should delete this exception after the MAP operation is completed.

—Jay Sauls and Baldwin Ng

MAP vs. VMM
How is the MAP Toolkit different from System Center VMM?
—Michael A.
The MAP Toolkit is designed to help you assess and plan for desktop, server, and virtualization projects during your planning phase. MAP is an agentless tool that does not require any preexisting management infrastructure, making it a great zero-footprint discovery tool to assist with migration scenarios. Specifically, MAP offers virtualization assessments to help you determine which physical servers are more suitable for virtualization, prior to deployment. Once migration and deployment occur, you will want to take advantage of System Center Virtual Machine Manager to manage your virtual workloads.
—Jay Sauls and Baldwin Ng

Got something to say? E-mail us at tnmag@microsoft.com, or visit our blog forum at blogs.technet.com/tnmag.


Toolbox New Products for IT Pros
Greg Steen

The opinions expressed in this column are solely those of the author and do not necessarily reflect the opinions of Microsoft. All prices were confirmed September 11, 2008, and are subject to change.

Map Data Graphically
MapForce
www.altova.com/products/mapforce/data_mapping.html
One of the perhaps not-so-joyous realities of the increasing number of inter- and intra-connections in today's application stacks is that you need to somehow move data between those applications. Straight one-to-one mappings between those applications are very rare, and so you'll often find yourself spending time designing some kind of ETL (extract, transform and load) process in order to get that information from one place to another in compatible formats. MapForce from Altova can help streamline that process and make it much easier.
This tool lets you graphically map out your data-transformation process with your mouse. Source and target data sources can be text or CSV files, XML, databases, Electronic Data Interchange (EDI) data, Microsoft Office Excel 2007 data, and even Web services. In terms of database source options, MapForce supports SQL Server, DB2, Oracle, Sybase, MySQL, and Microsoft Office Access, so you can connect to almost any database.
To get started, you create your data sources and targets and then map input fields to output fields. Of course, you may not want direct one-to-one or every-row-type mapping, so MapForce also provides a number of data-processing functions for filtering data. The tool allows you to build and use conditional statements based on Boolean logic, string operations, mathematical computations, and more to sort out the data.
The function library that comes with MapForce includes loads of ready-to-go functions to help you transform your data. For example, you can use math functions to pull minimum and maximum values, averages, and computed values. You can turn database NULL values into an empty string, convert Greenwich Mean Time to Eastern Standard Time, or match patterns within a string. In addition, MapForce allows you to add new function libraries as they are developed.
Once you have your mapping configured, you can immediately see the results by clicking on the Output tab. (This is handy for quickly making sure you have your data in the right place.)
The UI can take some getting used to. But MapForce has features in place to help with the adjustment, such as the Overview pane for complex transformation tasks, which gives you a zoomed-out view of where on the map you are looking. This is convenient for jumping between regions in the process.
Another nice feature of the latest edition is support for the Excel 2007 Office Open XML (OOXML) format as a direct data source; there's no need for an ODBC driver or similar component. In addition, Altova has added a great deal of support for Web services, letting you use Web methods as data sources, as targets, and even to transform your data. To take advantage of this feature, all you have to do is provide the Web Services Description Language (WSDL) definition for the service, its location, and its credentials. And the application is also capable of fully supporting both the SOAP 1.1 and SOAP 1.2 specifications.
With a database mapping, you can use the built-in query tool to build up a SQL statement to select the data in which you are interested; MapForce even has type-ahead completion for doing so. With this tool you also have the ability to define primary and foreign key constraints, as well as have the product do all the ID generation if you don't want the database to handle this.
As a developer, one of my favorite features of MapForce is the ability to generate a Visual Studio 2008 project with program code to execute your data transformation. And if you prefer to go from code to MapForce rather than from MapForce to code, you can download a plug-in for Visual Studio. In addition to generating code in C# for Visual Studio, you can generate code in Java and C++.
When it comes to purchasing the software, if you don't need the Web service mapping support, the FlexText dynamic text file parser, or support for OOXML, you may want to opt for the less-expensive Professional Edition. A further limited Standard Edition is also available.

Price: $1,190 for the Enterprise Edition; $599 for the Professional Edition; $299 for the Standard Edition.
Altova MapForce lets you map your data graphically

Create and Manage Regular Expressions
Expresso
www.ultrapico.com/expresso.htm
Whether you're a developer, systems administrator, network specialist, or QA analyst, you have probably found yourself parsing some kind of log file looking for patterned information. Regular expressions can be a very powerful method for getting to the exact information you are looking for in those logs. And applications such as Windows PowerShell are very handy tools to rely on. But, with their sometimes seemingly esoteric and perhaps lengthy structures, these tools can make it extremely difficult to construct the expressions as you need them. If this sounds familiar, consider giving Expresso from Ultrapico a try. This tool makes it much easier to develop, test, and reuse regular expression.
Expresso's main UI provides three basic views for development: Test mode, Design mode, and the Expression Library view. In Test mode, there are four panes of functionality. The Regular Expression pane is where you actually edit the expression to find and/or replace the data you are looking for. The Sample Text pane shows the text that the regular expression will run on and to which you can paste in an appropriate sample. The Regex Analyzer pane gives you a very cool hierarchical tree view of your regular expression components, helping you see how each component of the expression will operate. And the Results pane, as you might expect, shows the results of the operations you perform.
Within Test mode, there are six operations you can perform with your expression to get those results: full match, partial match, match exclusion, replacement, validation, and split. Full match takes your regular expression and runs it against the sample text, while partial and exclusion matches take the part of the expression you highlight and match it with or exclude it from to ensure the inner parts of your expressions are working properly. And you can use the tree view to navigate and highlight a particular section automatically. Replacement and split do just as the names imply. And validation uses icons to indicate which lines in your sample text will match.
Design mode provides the Regex Analyzer and Regular Expression panes as well as a place for your replacement text (you will likely be flipping back and forth between the Test and Design modes as you work). Also, you get a great designer toolbox, which helps you build up complex expressions with simple GUI actions. You can insert blocks that work with characters, groups, position, repetitions, and substitutions; and find helpers for ASCII and Unicode character and control codes.
The Expression Library gives you a history of your project's expressions. The application is project based, so you can save your works in progress or frequently used workspaces and come back to them when you need to. A number of sample projects also come with the application to help you get started with regular expressions, such as a built-in overall Regular Expression Library function. The default library comes loaded with expressions you can tailor to your own needs. You can add (and delete) expressions or create your own libraries.
If you find yourself using the same few expressions repeatedly, just move them to the top of the order. Double-clicking an expression in the library dumps it back into the main application window so you can immediately apply it in your workspace.
Expresso also has built-in code generation functionality. This will create a C#, C++, or Visual Basic code wrapper for your designed expression set. And, if you want, it will even compile this into a ready-to-go DLL for use in your applications or Windows PowerShell scripts.
Whether you are just starting out with regular expressions, have been learning over time, or are a certified guru looking for a way to test and save your creations, check out Expresso. This free utility could become one of your most valuable tools.

Price: Free.
Expresso makes it easier to develop, test, and reuse regular expressions

Query and Navigate Active Directory
Active Directory Query
www.tumbleson.net/products/products.htm
Querying and navigating through Active Directory are ongoing tasks for the systems administrator. Fortunately, there are tools available to help make those tasks a bit easier and more manageable. One tool I like is the easy-to-use Active Directory Query from Tumbleson.NET.
On startup, this application scans for domains within the forest to which the machine is connected and adds them to its internal list for reuse. You can also add domains manually, as well as provide alternate credentials so the application has access to query the domains in which you are interested.
Active Directory Query has a number of built-in queries and also supports custom queries. Built in, the application can query users, contacts, computers, groups, printers, shares, deleted objects, and recently created objects for the target organizational unit (OU).
After you've executed a basic query, you can then filter the results by enabled or disabled directory objects or by a string of text. In addition, there are computer filters that will show you stale computer accounts; and there are user filters that show locked accounts, expired accounts, stale accounts, expired passwords, and user accounts that have never actually logged into the domain.
For user accounts, you can easily enable and disable accounts, lock and unlock accounts, reset account passwords, display which Groups accounts are members of, and delete accounts. You can click to quickly contact a user (via e-mail, instant message, or phone). You can even upload a JPEG image to associate with an account.
When querying machines, Active Directory Query pulls back useful information, such as the OS, service pack, Fully Qualified Domain Name (FQDN), and LDAP path into an easy-to-scan table, letting you quickly get a view of the machines in question. There are a number of useful quick-click functions available here also—you can enable and disable a system, remote desktop to the system, provide remote assistance, perform management, power up and down a system, and get a list of the current shares on the computer. You can also trigger a ping, trace route, nslookup, and HTTP or FTP connection to the machine. And if you need more information, you can retrieve hardware, software, network, running process, and logged-in user information.
Another nice feature: you can save and create hotkeys for up to 10 custom queries so you won't have to craft them each time you need the information. Active Directory Query can also use wake-on-LAN (WOL) to remotely start machines that are powered down.
To do this, simply query for the machine or list of machines you want to wake up, and then right-click to retrieve the computer's MAC address via Windows Management Instrumentation (WMI). The application uses the MAC, which is stored in the application's internal database, to send a WOL packet to the machine.
If you need to, Active Directory Query can export to Excel, Notepad, or your clipboard with a couple of clicks, allowing you to save, share, or repurpose the information returned by your query. All in all, this is a useful and very easy-to-use tool.

Price: $89.99.
Query and manage systems with Active Directory Query

Book Review
Crimeware: Understanding New Attacks and Defenses
www.symantec.com/business/solutions/symantecpress.jsp
Users are becoming more aware of both cybercrime and the need to protect information (both personal and corporate). Still, attacks are becoming more sophisticated and more widely distributed; they continue to be successful, be it by stealing credit cards, personal information, or corporate data, or even "misinforming" targets.
Whether you think you are directly involved in your organization's security policies or not, you can have a direct impact on them by becoming more aware of the latest tools and techniques used by attackers. One book to help you get up to speed is Crimeware: Understanding New Attacks and Defenses (Symantec Press, 2008), by authors and security professionals Markus Jakobsson and Zulfikar Ramzan.
So what is crimeware? Well, as the book succinctly states, the "goal is profit or political power," whereas the more familiar-termed malware strove primarily for "notoriety." As you'll see in the introduction, the techniques and toolsets at the disposal of the purveyors of crimeware are extensive: keyloggers, screen scrapers, Web Trojans, transaction generators, system reconfiguration, proxy attacks, rootkits, piggybacking, and the list goes on.
After discussing all those tools and techniques, the book shows how applications are ripe with opportunity for attack through what it calls the Trinity of Trouble: connectivity, complexity, and extensibility. It goes on to show numerous platforms that can be exploited and/or targeted, such as peer-to-peer networks, handheld and RFID devices, firmware, browsers, and bot networks. Within these sections, you'll learn things such as how cross-site scripting attacks function, how bot networks are propagated and utilized, and how WiFi routers can be infected with crimeware.
In the next section, you get a look at the rootkit and learn about the kernel-mode hooks that can be placed on an unsuspecting system and how a rootkit can redirect memory access or filter through file system changes while hiding itself from detection. There are also chapters on fraud within online virtual worlds and online advertising fraud, which discusses the wide array of technologies, techniques, and social-engineering strategies used by criminals to get your money and information. The chapter on business models shows just how profitable these attacks can be.
But, ultimately, the book provides some hope with a couple of sections covering the laws in place to protect against cybercrime and how trusted computing and other defense techniques can limit exposure to attack. If you are looking to get up to speed on the techniques of attack and defense in practice today, consider giving this book a good cover-to-cover read to understand current attacks from all angles.

Price: $49.50.

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


Utility Spotlight Internet Explorer Developer Toolbar
Lance Whitney

Whether you develop Web content yourself or just support your local webmaster, here's a free Microsoft utility to make your job easier. The Internet Explorer Developer Toolbar helps you fix misbehaving Web pages by letting you peek behind the scenes. The Toolbar displays all tags and styles for your text, tables, images, and other HTML content. You can view style rules, highlight specific elements on your page, and even validate your HTML and CSS.
You install the Internet Explorer Developer Toolbar from the downloaded IEDevToolBarSetup.msi file. After installation, reopen Internet Explorer, and a new button called IE Developer Toolbar appears on the command bar. Click on the button and the Toolbar opens in the lower portion of your browser window, separated into three panes (see the screenshot). The first pane displays a tree view of all your Web page elements. Clicking on any element reveals its attributes and styles in the other two panes.
Using pulldown menus, you can highlight specific elements on the screen, either by clicking on them or by searching for them. Search for all h3 tags, for example, and they appear one after another in the tree view. Selecting a tag then outlines its corresponding element on the page. You can also find elements by choosing specific categories, such as div tags, tables, images, and objects placed using absolute or relative positioning.
Behind the scenes of a Web page

The Toolbar can be especially helpful for working with style rules. It can highlight all items on a page formatted with ID or class styles. You can generate a report of all the rules in your style sheet to determine where and how they are applied. You can even disable all CSS to see how your page elements are affected.
To manage graphic objects with the Toolbar, you can enable and disable images and reveal the resolution, size, path, and alt tag for each picture. The Toolbar also will generate an easy-to-read image report displaying the key details for all graphics.
Using the Toolbar, you can easily resize your browser page to any resolution from 800x600 to 1280x1024 or your own custom size. An onscreen ruler will measure any element by pixels. A color-picker tool displays an eyedropper that allows you to select an object in order to see its color value in RGB and hex.
To help you troubleshoot Web page problems, the Toolbar can disable certain elements, such as JavaScript and cookies. You can view the HTML source of your content, either the entire page or just a selected object. Moreover, the source display is formatted and color-coded so that you can separate content from tags easily. From the tree view, you can even add and remove styles and other attributes on the rendered display of your page to see their effect. Finally, the Toolbar will ensure that your content is checked for XHTML validity, broken links, and accessibility by piping your page to the World Wide Web Consortium (W3C) validation service.
The Internet Explorer Developer Toolbar is compatible with Internet Explorer 6 and 7 under Windows XP, Windows Vista, and Windows Server 2003. Visit go.microsoft.com/fwlink/?LinkId=125120 for more details and a link to download the Toolbar.

Lance Whitney is an IT consultant, Web developer, 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.


Inside SharePoint Extending Office Applications with Web Services
Pav Cherny

Contents
SharePoint Web Services and the Object Model
Outlook 2007 and the StsSync Protocol
Excel 2007 and Excel Web Access
Access 2007 and the Access Web Datasheet Control
Word 2007 and the MetaWeblog API
PowerPoint 2007 and MOSS 2007
InfoPath 2007 and InfoPath Forms Services
Conclusion
The 21 standard Web services in Microsoft Windows SharePoint Services (WSS) 3.0 and 19 standard Web services in Microsoft Office SharePoint Server (MOSS) 2007 enable you to create remarkably flexible solutions for retrieving data from local and remote resources, extending standard Microsoft Office suite features and integrating business applications. Of course, you may have even more than 40 Web services. If you install additional server solutions that integrate with SharePoint, such as Microsoft Office Project Server 2007, you might find that the count on your SharePoint server easily exceeds 60 or more Web services. And that doesn't even count any of the custom SharePoint Web services you might want to implement. Web services are fundamental building blocks of distributed business applications, and in the era of Software-plus-Services, Web services are even more significant because they provide the means for organizations to integrate on-premise solutions with hosted environments.
In this column, I discuss the advantages of Web services in a SharePoint environment, specifically their use in and around standard Office applications. Although Office applications typically rely on Microsoft Office FrontPage and WSS Remote Procedure Calls (RPCs), and Web Distributed Authoring and Versioning (WebDAV) for file-based access to SharePoint lists and libraries, they also use Web services. The basic Web services included in WSS 3.0 are sufficient for most Office applications, such as Microsoft Word 2007, Outlook 2007, and Access 2007, while others, such as PowerPoint 2007 and InfoPath 2007, can use additional Web services that are available only with MOSS 2007 or with separate products. I mention product dependencies where necessary. If you want to follow my explanations in a test environment, you can find worksheets with step-by-step instructions in the companion material for this column, available in the Code Download section at technet.microsoft.com/magazine/bb978519.
Exhaustive developer discussions and business data integration topics are beyond the scope of this article. I assume you are familiar with Web services and their use in business applications. For a general overview regarding the built-in Web services of WSS 3.0 and MOSS 2007, I recommend the article "Web Services Access" in the SharePoint Server 2007 SDK as a starting point (see msdn.microsoft.com/library/bb862916.aspx) .

SharePoint Web Services and the Object Model
A classic question in SharePoint solutions development is whether to use Web services or the object model. The object model is easier to use, exposes more interfaces, and has less overhead than Web services, yet the object model is only available on the SharePoint server due to COM dependencies. Web services are more accessible and are therefore the right choice for client applications and server-side components, such as Business Data Web parts, that need to aggregate data from remote sources. As data moves from local, on-premise systems into remote, hosted environments, SharePoint solutions must increasingly embrace a service-oriented architecture (SOA) to be able to deal with distributed SharePoint environments, as illustrated the diagram in Figure 1.
Figure 1 Web Services in a distributed SharePoint environment
By eliminating the tight coupling between front-end and back-end subsystems, Web services provide extensive flexibility. As Figure 1 suggests, front-ends can interface with any underlying platform as long as the intermediary Web service exposes the expected interface. I demonstrated this in my September 2008 column (technet.microsoft.com/magazine/cc742803) by replacing the built-in WSS 3.0 E-mail Integration Web Service (SharepointEmailWS.asmx) with a custom version that exposes the same interface.
Of course, the same principle also applies to client apps, such as Office applications that consume SharePoint Web services. Stephen Toub demonstrated this very intuitively in his MSDN article "Custom Calendar Providers for Outlook 2003" by building a custom Web service that mirrors the interface of the SharePoint Lists service (Lists.asmx) to return custom data instead of SharePoint list items to Outlook (see msdn.microsoft.com/aa168130). He showed how an Outlook calendar can display such diverse data as entries from the event log, items in an RSS feed, postings from a newsgroup, conversations in Windows Live Messenger, and system restore points on a computer, and later expanded the solution to support Contacts lists as well.
In 2006, Patrick Creehan updated the implementation so that it now works with Outlook 2007. (See Patrick's blog entry "Custom Calendar Providers for Outlook 2007" available at blogs.msdn.com/pcreehan/archive/2006/11/21/custom-calendar-providers-for-outlook-2007.aspx.)

Outlook 2007 and the StsSync Protocol
Now that you know that custom list providers can take advantage of the Outlook integration with SharePoint, let's take a closer look at the Outlook/SharePoint interaction. To access the contents of a SharePoint list or document library, Outlook communicates with SharePoint through the Lists Web service and displays the lists and their items side-by-side with standard Outlook folders. You can also create new or update existing items directly in Outlook, in which case Outlook uses the Lists service to update the SharePoint repositories. The interaction and the solution architecture are relatively straightforward, as illustrated in Figure 2.
Figure 2 Outlook StsSync architecture
In order to link to the desired lists, Outlook supports a special URL format based on the StsSync protocol identifier that is registered with Outlook as the protocol handler. You can find the corresponding registration on your workstation in the following Registry key: HKEY_CLASSES_ROOT\StsSync\Shell\Open\Command. Outlook receives the StsSync URL as a command-line parameter, breaks it up into its individual parts, and then uses the parameters to link to the specified SharePoint list.
StsSync URLs are long and cryptic because they contain several query string parameters in typical URL character-encoded format, such as:
stssync://sts/?ver=1.0&type=calendar&cmd=add-folder&base-url=http%3A%2F%2Fsharepoint%2FHR%2FAdministration&list-url=%2FLists%2FCalendar%2FAllItems%2Easpx&guid=%7B4DF13090%2DDE1C%2D43EA%2D8B44%2D904869FEABC4%7D&site-name=HR%20Site&list-name=Admin%20Events
Fortunately you do not need to specify these URLs directly if you link Outlook to the desired list from within the SharePoint user interface. Just open the SharePoint list in Internet Explorer and then on the list's Actions menu, click Connect to Outlook. This command calls a JavaScript function named ExportHailStorm (located on the server in \%PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\1033\Init.js), which constructs the StsSync URL based on list parameters and then passes the resulting URL to Internet Explorer, which in turn passes this URL to the registered protocol handler, which is Outlook. For an example of how to work with SharePoint lists in Outlook, see the companion worksheet "Working with Outlook in WSS."
One of the most important StsSync parameters is base-url, which points to the SharePoint site, such as sharepoint/HR/Administration. Outlook automatically appends a reference to the Lists Web service to this URL (for example, sharepoint/HR/Administration/_vti_bin/Lists.asmx). Then the road is clear to communicate with SharePoint. The individual parts of the StsSync URL are explained in the StsSync Structure Specification at msdn.microsoft.com/cc313101.

Excel 2007 and Excel Web Access
In Figure 2, you might have noticed the Export to Spreadsheet option underneath Connect to Outlook on the SharePoint Actions menu, which exports the contents of a list into an Excel spreadsheet. Excel 2007 does not use the StsSync protocol. Instead, Export to Spreadsheet calls a function named ExportList (located on the SharePoint server in \%PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\1033\Core.js), which initiates an interesting sequence of steps to export the list items. This feature does not use Web services.
The ExportList call results in an HTTP request directed at an ISAPI extension (Owssvr.dll) to generate and return a Web query (.iqy) file. This .iqy file contains a Web query statement that references Owssvr.dll to retrieve the actual data from the SharePoint list in the form of an XML document. You might consider Owssvr.dll a prehistoric version of a Web service, but its interface does not adhere to industry standards for Web services, so it is valid to say that Excel doesn't use Web services out of the box.
An Excel solution that does use Web services is Excel Web Access, which is included in MOSS 2007 and is illustrated in Figure 3. In fact, Excel Web Access uses Excel Services (ExcelService.asmx), which in turn relies on Excel Calculation Services (ECS), a calculation engine that provides the same calculation functions as the Excel 2007 desktop application. Excel Web Access is designed to work as a data view and parameterized analysis tool. By assigning specific cells as parameters, enabling only specific parts of the worksheet to be viewable online, and setting SharePoint access permissions on the workbook itself, administrators can gain a very granular degree of control over what users can access in an Excel workbook. For security reasons, Excel Web Access and Excel Services do not support some of the features of Excel 2007, such as inline Visual Basic code, form controls, and external references. However, solution developers can create managed code that can be accessed from within a workbook on SharePoint. For more information about Excel Services, including step-by-step how-to guides, see the white paper "Excel Services Step-by-Step Guides" at technet.microsoft.com/cc263430.
Figure 3 Excel and Excel Web Access architecture

Access 2007 and the Access Web Datasheet Control
Similar to exporting a SharePoint list to a spreadsheet, you can export a list to a database by using the Open with Access option on the Actions menu. Open with Access also relies on the Owssvr.dll ISAPI extension to obtain data from SharePoint. If you click on Open with Access, you call the JavaScript function ExportToDatabase (located on the SharePoint server in %\PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\1033\Core.js), which instantiates a SharePoint.ExportDatabase ActiveX control. This control communicates with Owssvr.dll and creates the Access database with tables, views, reports, and other objects linked to the SharePoint list objects or copied into the database from SharePoint according to your export choices. See the companion worksheet "Working with Access in WSS" to get started with SharePoint lists in Access 2007.
Whereas the SharePoint.ExportDatabase ActiveX control communicates with Owssvr.dll and does not use Web services, Access 2007 actually uses SharePoint Web services via a DLL called Stslist.dll, as illustrated in Figure 4. For example, you can display the External Data ribbon in Access 2007, click on SharePoint List, and then link to the desired list as the data source of a linked table. In this scenario, Access calls the Lists Web service (Lists.asmx) on the server. You can then use SQL statements to search or update the data in Access. Access also calls Lists.asmx every time you modify a record in a linked table to ensure that the SharePoint data remains current.
Figure 4 Access and Access Web Datasheet architecture
You can also export individual Access tables as lists to SharePoint and even move an entire Access database to a SharePoint site, which creates a SharePoint list for each table and moves all the data to SharePoint in one bulk operation. Although SharePoint cannot enforce referential integrity in its lists (users moving databases with referential entries to SharePoint will receive a warning message to that effect), it does allow references between lists as though they were tables. When exporting tables from Access, Access communicates with the Webs (Webs.asmx) and Views (Views.asmx) Web services in addition to Lists.asmx to create a list for each table as well as a site column for each table column, and list views based on these site columns.
Following a successful export, you might want to view a SharePoint list in a Datasheet view. Just click on the Edit in Datasheet option on the list's Actions menu. Edit in Datasheet redirects the browser to a Web page that references the Access Web Datasheet control through the following CLSID: 65BCBEE4-7728-41A0-97BE-14E1CAE36AAE. Internet Explorer then loads this ActiveX control on the local workstation into the Web page. If you search through the registry on a workstation running the 2007 Office system, you can find the corresponding registration entry for the ActiveX control (ProgID ListNet.ListNet) in the HKEY_CLASSES_ROOT hive. Check out the InprocServer32 registry key and you can see that the Access Web Datasheet control is implemented in Stslist.dll. The Access Web Datasheet control uses the same Web services as does Access 2007.
Additional Resources

SharePoint Products and Technologies Web Site
microsoft.com/sharepoint

Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/sharepoint

Windows SharePoint Services Developer Center
msdn.microsoft.com/sharepoint

Microsoft SharePoint Products and Technologies Team Blog
blogs.msdn.com/sharepoint

Word 2007 and the MetaWeblog API
Word 2007 uses a unique Web service implemented in a file called Metaweblog.aspx to take advantage of the MetaWeblog API on SharePoint servers. This API exposes just three methods (newPost, editPost, and getPost), but it still communicates over HTTP using XML structures. WSS 3.0 supports blogging out of the box with a Blog site template and Web management interface. Based on the MetaWeblog API, you can use Word 2007 as a blog program, which provides a viable alternative to the browser interface.
Note that the MetaWeblog service does not use an .asmx file name extension like other SharePoint Web services. The MetaWeblog API was developed more than five years ago by Dave Winer and popular blogging tools expect to access this API through an .aspx page (you can read the specification at xmlrpc.com/metaWeblogApi). By using .aspx instead of the usual .asmx naming convention, SharePoint remains compatible with these blogging tools.

PowerPoint 2007 and MOSS 2007
In a WSS 3.0 environment, PowerPoint 2007 does not use Web services, but communicates with SharePoint primarily through FrontPage/WSS RPCs and WebDAV when accessing presentation files in a document library. Yet if you have MOSS 2007, PowerPoint can take advantage of SharePoint slide libraries and the Slide Library Web service (SlideLibrary.asmx).
Slide libraries are a special type of document library. You can use them in conjunction with the Publish Slides feature of PowerPoint, which can break up a presentation deck into its individual slides and save these as separate files in a folder or library. When publishing slides in a slide library, PowerPoint communicates with Webs.asmx and Slidelibrary.asmx to verify URLs and check for slide collisions. If a slide with the same name already exists in the slide library, PowerPoint prompts you to replace the existing slide or skip the current one.
Once slides are uploaded to a slide library, they can be reused in other presentation decks while the original slides remain in the slide library on the SharePoint server. SharePoint adds a timestamp to each slide and PowerPoint can check this timestamp as well as other metadata, such as the name of the PowerPoint presentation from which the slide originated, to detect updates through the Slide Library Web service. If updates exist, you can choose to replace the local slide in the current presentation or append the changed slide to your presentation. For an introduction, read the article "Use Slide Libraries to Share and Reuse PowerPoint 2007 Slide Content" at office.microsoft.com/en-us/powerpoint/HA012261671033.aspx. See also the companion worksheet named "Working with Slide Libraries."
Occasionally, you might notice an error message in PowerPoint 2007 when publishing slides, stating that "n of n slides that were being published to <library> failed. Try publishing again." This can be the result of missing access permissions or WebDAV communication problems. As a workaround, you can publish the slides to a folder on the local file system and then copy the files manually into the slide library using Windows Explorer and the UNC path to the slide library, such as \\sharepoint\SlideLib instead of sharepoint/SlideLib. Windows Explorer uses the same WebDAV redirector as PowerPoint 2007, but it doesn't contact SlideLibrary.asmx to detect slide collisions. Instead it uses WebDAV to detect if a file already exists. Figure 5 shows the slide library architecture for PowerPoint 2007.
Figure 5 PowerPoint and SlideLibrary architecture

InfoPath 2007 and InfoPath Forms Services
This column wouldn't be complete without mentioning InfoPath 2007 and InfoPath Forms Services. In fact, InfoPath 2007 is the biggest consumer of Web services among the Office applications discussed in this column. Of course, you can make extensive use of Web services as data sources in InfoPath forms, but even if you leave forms development aside and focus on publishing simple form templates that do not use external data sources, InfoPath 2007 communicates with SharePoint through Web services in addition to FrontPage/WSS RPCs and WebDAV, as illustrated in Figure 6. For an example that shows how to publish form templates in a SharePoint forms library, see the worksheet "Working with InfoPath Forms Services," available in the Code Download.
Figure 6 InfoPath and Forms Services architecture
Important Web services that InfoPath 2007 relies on are Webs.asmx and Lists.asmx. Among other things, InfoPath retrieves information about the definition of site columns and content types from the Webs service, and uses this information to populate the site column list boxes in the Select a Field or Group dialog box so you can associate form columns with existing SharePoint site columns when publishing a form template. InfoPath creates any new columns without an association in the SharePoint site by using the Lists service. InfoPath also interacts with the Lists service to create the forms library and a content type definition for the form template. For the actual template upload, InfoPath uses FrontPage/WSS RPCs and WebDAV, simply placing the template with the file name template.xsn into the new library's Forms subfolder.
For browser-compatible form templates, the Publishing Wizard in InfoPath might offer the option to enable a form to be filled out using a browser, depending on whether you have MOSS 2007 or Microsoft Office Forms Server 2007 on the SharePoint server. InfoPath detects whether Forms Services is installed and enabled for the current SharePoint site by using the FormServerDetector.aspx Web page (such as sharepoint/_layouts/FormServerDetector.aspx?IsFormServerEnabled=check), which returns <server IsFormServerEnabled = 'true' /> when Forms Services are present and enabled. If you then enable your form to be filled out using a browser, InfoPath 2007 calls the Forms Services Web service (FormsServices.asmx) during the publishing process to browser-enable the form template accordingly. For more information about browser-enabled InfoPath forms, see the Microsoft Office Forms Server 2007 General Reference available at msdn.microsoft.com/aa701145.

Conclusion
Web services are an important part of the SharePoint platform. They enable business solutions that can access local and remote resources, integrate distributed business applications with each other, and provide valuable features to Office applications. The most important Web services for Office apps are Webs.asmx and Lists.asmx, included in WSS 3.0, for working with SharePoint sites, lists, and libraries. Another Web service used occasionally is Views.asmx, which provides methods for working with list views. Most Office applications do not require a MOSS 2007 deployment, although some applications, such as PowerPoint 2007 and InfoPath 2007, can benefit from advanced features, such as Slide Libraries and Forms Services that are only available with MOSS 2007 or as separate products.
In the era of Software-plus-Services, Web services play an important role because they decouple hosted back-end environments from on-premise front-end applications. SharePoint is a key technology that drives online collaboration forward; Office applications and Office add-ins continue to run on local workstations, and Web services in combination with other Web technologies provide seamless access to features and data across corporate firewalls in distributed environments. It is no coincidence that SharePoint servers host 20, 40, 60, or more Web services. Web services are the right choice for business solutions that emphasize ease of use, simplicity of access, and flexibility while the object model is the right choice to build these Web services.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.


Windows PowerShell Building Your Own Software Inventory Tool
Don Jones

Contents
Finding the Information
Prototyping
Reading Computer Names
Modularizing
Pipeline Functions
In this installment of the Windows Power-Shell column, I am going to demonstrate a very practical use: I will build a tool that inventories the operating system build number (one of the best ways to determine the operating system version) and service pack version number from a list of computers. But I'm not just going to give you the solution outright. I'm going to walk you through the process I use to develop a script like this.
While this is obviously a useful tool, I think the process by which I develop the tool is even more important. Once you understand and can reuse this development process for your own tasks, you'll be well on your way to solving nearly any administrative problem using Windows PowerShell. (As the old saying goes, if you teach a man to build a tool …) So let's get started.

Video
Watch Don Jones build a Windows PowerShell-based inventory tool and demonstrate the process that goes into building such a solution.

Finding the Information
The first—and often hardest—task is to find out where you can actually find the operating system and service pack version numbers. You might be tempted to go spelunking in the registry. The registry is sometimes the answer for information such as this, but it's usually my option of last resort because the registry can be a little bit tricky to work with.
The words "retrieve" and "information" immediately trigger a possible answer in my mind: Windows Management Instrumentation (WMI). Another keyword that makes me think of WMI is "remote," since in version 1 of Windows PowerShell, WMI is about your only option for performing any kind of remote information inventory or management operation.
Unfortunately, there are tens of thousands of WMI classes in most Windows systems, and this can make it difficult to find the one that contains the information you need. I usually start with a Web search engine and punch in a phrase such as "wmi service pack version number." Note that you'll need a fairly long search phrase like that in order to generate more specific results.
You may even need to try some varying search terms, but don't be tempted to abbreviate ("wmi sp version" won't provide very useful results). Consider alternative terms. For example, what you may call "patches," others call "hotfixes," and still others call them "quick fix engineering" or "qfe patches." Trying all of those terms may be necessary to find the right results.
If you're searching on something related to computer hardware or the core Windows OS, adding "Win32" to your search phrase can help, since most of the relevant WMI classes start with a "Win32_" prefix. Adding "Win32" to my current search definitely yields the best results. I see several results with "Win32_OperatingSystem" in the titles—that's a WMI class name.
Now, the important trick is to refrain from clicking on any of the search results. (That way lies madness.) I first want to find the actual documentation pages for the class, so I start over with a new search using just the class name I discovered. Doing so will generally yield a link to the msdn.microsoft.com Web site in the first couple of results, and that should take you to somewhat directly to the class documentation page.
Figure 1 shows a portion of that page. I've scrolled to a particularly important table on that page, which lists the OS versions with which the class will work. I can't tell you how many times I've labored over something, trying to get it to work, only to discover that what I was trying to do didn't actually exist in the version of Windows I was using. So now I have the habit of first checking this table.
Figure 1 Looking up information about the WMI class
Scrolling up the page a bit, I see that there are two properties I am interested in: BuildNumber and ServicePackMajorVersion. In fact, ServicePackMinorVersion might be useful, too, although I've never seen a 2.1 service pack number from Microsoft. Nonetheless, it probably deserves to be checked if only to be thorough.

Cmdlet of the Month: Export-CliXML and Import-CliXML
Windows PowerShell has the ability to store a static snapshot of objects in a special XML format, allowing the information in those objects to be persisted in a file and loaded into memory for later examination. You can simply pipe objects to Export-CliXML to save those objects to a file:
Get-Process | Export-CliXML c:\processes.xml
When you import those objects into the shell later on, you can examine them just like any other object. They're not "real" objects, but they do enable more reporting options. Suppose you've scheduled a script that exports all the processes on a given server at 3:00 A.M. when some maintenance task is running. When you come to work, you can load those processes and look at them, perhaps sorting them on their virtual memory consumption, like so:
Import-CliXML c:\processes.xml | Sort VM -descending

Prototyping
I don't want to go any further without making sure these properties do what I expect. Windows PowerShell makes it very easy to do this. I start by checking this information on my local computer:
Get-WmiObject Win32_OperatingSystem | Select
BuildNumber,ServicePackMajorVersion,ServicePackMinorVersion
OK, the minor version was zero, which was what I expected, so I'm going to forget about it. The other information is also what I expected—a build number of 6001 for my Windows Server 2008 computer and a service pack version of 1.
Now I will do a similar test on a remote computer—one that I know I'm an administrator on:
Get-WmiObject Win32_OperatingSystem –computer Server2 |
Select BuildNumber,ServicePackMajorVersion
If that test doesn't work, I need to stop and figure out why before I can go any further. Any problems are likely related to connectivity, firewalls, or permissions, which are all outside the scope of Windows PowerShell itself. Once I've got everything working properly, I can move on to the next step in my problem: how to get a bunch of computer names out of a file.

Reading Computer Names
Assuming my list of computer names is in a text file and there is one computer name listed on each line, the simplest way to do this is to use the Get-Content cmdlet. (Don't fret if your computer names are not in a text file or listed one per line—I'll cover techniques for dealing with different circumstances in a follow-up column.)
Each name is returned as an independent string object. And a handy feature of the Get-WmiObjectcmdlet is that its –computerName parameter accepts a collection of computer names, so this should do the trick:
$names = Get-Content c:\computernames.txt
Get-WmiObject Win32_OperatingSystem –comp $names | Select
BuildNumber,ServicePackMajorVersion
The problem now is that my output is a list of numbers, with no indication of which number goes with which computer. Fortunately, the Win32_OperatingSystem class happens to have another property, CSName, that includes the computer name. So I can add that property to my output and I get a nice inventory:
$names = Get-Content c:\computernames.txt
Get-WmiObject Win32_OperatingSystem –comp $names | Select
CSName,BuildNumber,ServicePackMajorVersion

Modularizing
All of that might be a bit too much for a less experienced technician to use, so the final step is to modularize all of this into a function. One way is to write a function that accepts a filename and have the function do all the work:
Function Get-SPInventory ([string]$filename) {
  $names = Get-Content $filename
  Get-WmiObject Win32_OperatingSystem –comp  $names | Select   CSName,BuildNumber,ServicePackMajorVersion
}
As you can see, I've simply wrapped my working code in a function named Get-SPInventory. I've defined it with an input parameter named $filename, so it can just be called like this:
Get-SPInventory c:\computernames.txt
The results can still be piped to a CSV file, converted to HTML, or formatted differently, using normal Windows PowerShell commands, like so:
Get-SPInventory c:\computernames.txt |
Export-CSV SPInventory.csv
This still isn't perfect, though. What if I also wanted to inventory some information that wasn't included in the Win32_OperatingSystem class, such as the BIOS serial number for each computer? That would be useful since many Configuration Management Databases (CMDBs) use the BIOS serial number as the unique identifier for computers.
I might also want the output of the function to be a bit more flexible, perhaps allowing me to sort or filter the results more easily. Then, for example, I could choose to include only Windows Server 2003 computers with an older service pack version in the final output to create a list of computers I need to update.

Pipeline Functions
Now I want to rewrite my function to be a better player in the Windows PowerShell pipeline. Specifically, I want the function to directly accept computer names from the pipeline—that way, I can decide where I want to get the computer names from each time I use the function. The computer names may be in a file or they may be in Active Directory, and I want the function to work well either way. So, here's the function rewritten for the pipeline:
Function Get-SPInventory {
  PROCESS {
    $wmi = Get-WmiObject Win32_OperatingSystem       –comp $_ | Select     CSName,BuildNumber,ServicePackMajorVersion
    Write-Output $wmi
  }
}
This special type of function uses a PROCESS script block, which will execute once for each pipeline object I pipe into the function. (Dedicated readers will remember that I discussed the PROCESS script block in the July 2008 installment of this column, available at technet.microsoft.com/magazine/cc644947.aspx.) The special $_ variable will automatically populate with the pipeline input—as long as I'm piping in computer names, it'll work fine. The new function is used like this:
Get-Content c:\computernames.txt | Get-SPInventory
As you can see, this offers more flexibility for getting computer names from different sources. I just replace the Get-Content portion of the command with whatever command is necessary to retrieve the computer names. Note that I've also set it up so that I can create more robust output by querying different WMI classes (or any other data sources) before constructing my output.
But that's not the end of the discussion. Next month I'll expand this function to include the BIOS serial number in the output.

Don Jones is a cofounder of Concentrated Technology and author of numerous IT books. Read his weekly Windows PowerShell tips or contact him at www.ConcentratedTech.com.


Hey, Scripting Guy! Probing the Depths of WMI
The Microsoft Scripting Guys

Contents
Namespaces
WMI Classes
Properties
Methods
When one of the Scripting Guys was younger, he had two hobbies he really enjoyed. One was drinking fermented beverages; the other was winter camping. He suspects the two were related. A companion of his during those days was fond of suggesting that they "go deep." Well, this month we're going to follow the old friend's advice. We're going deep into the wilderness of WMI (that is, Windows Management Instrumentation).
Thankfully, we don't have to hike anywhere in this case, except perhaps to the coffee maker and back. Instead, we're going to probe the WMI depths using scripts.
Now, the Scripting Guys are well-known for being very practical folk. We try to present solutions to actual problems rather than lofty explanations that seem to leave few details—like how to actually accomplish anything—to the reader. Don't think we're jumping on that bandwagon. Although this column doesn't focus on achieving specific system administration tasks, it does have a practical goal. The primary aim is to educate you about the WMI infrastructure. And we'd also like to put some useful probing scripts in your hands. Fire up Notepad—we're going deep!

Namespaces
Figure 1 Displaying namespaces
Call EnumNameSpaces("root") Sub EnumNameSpaces(strNameSpace) On Error Resume Next WScript.Echo strNameSpace Set objWMIService=GetObject _ ("winmgmts:{impersonationLevel=impersonate}\\" & _ strComputer & "\" & strNameSpace) Set colNameSpaces = objWMIService.InstancesOf("__NAMESPACE") For Each objNameSpace in colNameSpaces Call EnumNameSpaces(strNameSpace & "\" & objNameSpace.Name) Next End Sub
Namespaces can include subnamespaces. You can think of the whole thing as being like a directory structure. So if we were to ask only for all the namespaces (starting with the top-level root namespace), we would get back just the first level of namespaces within root, which would miss any subnamespaces. Instead, we use the trick of recursion. We create a subroutine called EnumNameSpaces that takes a namespace as a parameter and returns all of its subnamespaces.
We kick things off by calling EnumNameSpaces with root as the parameter. This will return all the namespaces within the root namespace. Then we do the recursion. Notice that EnumNameSpaces actually calls itself, passing in each of the subnamespaces it identifies. Take a big slurp of your coffee and think about that. The result is that every namespace will be processed and, if it has subnamespaces, they will all be displayed.
Note that we included an On Error Resume Next statement at the beginning of the subroutine. This is in case you run the script under a security context that doesn't have access to all the namespaces. If that's the case, the script will still run, though it will be a little slow as it waits for timeouts.
Yes, you could just use wbemtest.exe (it's on every computer that has WMI installed) or Scriptomatic (go.microsoft.com/fwlink/?LinkId=125976) to do this. But with a starting script and your elite scripting skills, you can filter those namespaces or output them to Excel or compare the namespaces on two computers.
Now that we can see how the repository is divided up, let's develop a script that allows us to examine what's in each of those sections. We know that WMI classes are stored in each of those namespaces, so let's start by listing them.

WMI Classes
Remember we mentioned that the WMI repository houses the Common Information Model? Well, that model is stored within the CIMV2 (V2 for version 2) namespace. If you look into the CIMV2 namespace, you should see all the WMI classes that make up that model. The following script does that:
strComputer = "."
Set objWMIService=GetObject("winmgmts: _
    {impersonationLevel=impersonate}!\\" & _
    strComputer & "\root\cimv2")

For Each objclass in
    objWMIService.SubclassesOf()
    Wscript.Echo objClass.Path_.Class
Next
Let's see exactly how this script works. The call to GetObject returns an SWbemServices object. GetObject is a VBScript function that returns references to scriptable COM objects. In this case, because we passed it the string "winmgmts:…", GetObject returns an object from the WMI Scripting Library. Notice that the string we pass to GetObject includes the namespace to which we are connecting, \root\cimv2 in this case. So the SWbemServices object we have to work with is bound to the particular namespace we specified. Check out the SWbemServices documentation to see what possible actions you can take in your script.
One that probably looks very familiar to you is ExecQuery. That's the method that lets you run a WQL (Windows Management Instrumentation Query Language) query against the namespace to which you are connected. But there are a bunch of other actions you can take once you have an SWbemServices object associated with a namespace.
We want to see all the WMI classes in the namespace, and SubClassesOf accomplishes that. The documentation says it returns an SWbemObjectSet. That doesn't sound like something you'd want to face alone in the woods! Just focus on the last three letters—it's a set. And, as WMI scripters know, you can walk through a set using For Each.
Now, not too surprisingly, each member of an SWbemObjectSet is an SWbemObject. Each of those SWbemObjects represents one of the WMI classes in the CIMV2 namespace. Take a look at the documentation for SWbemObject and you'll see all the information we could output about those classes.
In our script, we've chosen to just display the name of the class. To do that, we accessed the Path_ property. As it turns out, the Path_ property is itself an object. It's an SWbemObjectPath and, being an object, has a bunch of its own properties. We're using Class, which is the name of the class.
So, not only do you have a script that can display all of the WMI classes in a namespace, but you also have a script that can be easily updated to display various other things pertaining those classes. For example, WMI classes can be extensions of other WMI classes. Imagine you have a model for a car (Win32_Car), but you really need to manage station wagons. Everything in the model for the car applies to the station wagon.
But you need a few additional things, such as a Boolean indicating whether it has that fancy wood paneling. You wouldn't want to recreate all of the Win32_Car functionality. What you'd want is a mechanism for extending the Win32_Car class to include all of the new properties. WMI includes just such a mechanism.
To see if a WMI class inherits properties from another WMI class, you can check the Derivation_ property of the SWbemObject class associated with that WMI class. The script in Figure 2 displays the WMI classes in the CIMV2 namespace along with a list of the classes from which they derive.
Figure 2 CIMV2 class derivations
strComputer = "."
Set objWMIService=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
    strComputer & "\root\cimv2")

For Each objclass in objWMIService.SubclassesOf()
    WScript.StdOut.Write objclass.Path_.Class
    arrDerivativeClasses = objClass.Derivation_
    For Each strDerivativeClass in arrDerivativeClasses
       WScript.StdOut.Write " <- " & strDerivativeClass
    Next
    WScript.StdOut.Write vbNewLine
Next

    For Each objNameSpace in colNameSpaces
        Call EnumNameSpaces(strNameSpace & "\" & objNameSpace.Name)
    Next
End Sub
The script starts out just like the previous one. It uses WScript.StdOut.Write instead of WScript.Echo to avoid automatically adding a new line character after the displayed string. (Note: you have to run your script using Cscript.exe instead of Wscript.exe for StdOut.Write to work.)
Looking at the documentation for SWbemObject, you can see it has a Derivation_ property. That property is an array of strings containing the names of classes from which the current class was derived. In our script, we walk through that array using For Each and display all of the classes separated by an ascii arrow. Once you are used to starting with the SWbemServices object returned by GetObject and are walking through the possibilities in the WMI Scripting Library documentation, you can test properties and methods on these oddly named objects to find what's possible.
Understanding which WMI Scripting Library object you are working with at any point in your script lets you move to the next level of WMI scripting. Instead of just using our scripts, you will also understand why we were able to call ExecQuery or reference the Properties_ property. And you'll be able to take things further.
The Scriptomatic tool doesn't live up to your expectations? No problem. Go ahead and modify it to do what you want. Maybe others will purchase your creation from you. In which case, just e-mail instructions to scripter@microsoft.com detailing how we will receive our royalty checks.

Properties
Each WMI class models something you can manage using a set of properties and methods. The properties are characteristics of the thing. A process, for example, has an ID and a priority and uses a certain amount of memory. Those properties are all included in the Win32_Process WMI class.
Once you have identified the class to manage an entity, look at the properties available to see if what you want to manage is in the management model. The SWbemObject class includes a property called Properties_. Funny, huh? The value of that property is an SWbemPropertySet object that includes a collection of SWbemProperty objects. Each of those SWbemProperty objects corresponds to a property in the WMI class associated with the SWbemObject. I know—all these SWbem* names make everything sound terribly complicated, but it's not all that bad. A Take a look at Figure 3.
Figure 3 SWbemObject exposes the properties of the WMI class to whichit is bound
Keep in mind that the classes that begin with SWbem* are members of the WMI Scripting Object library. They are the objects that let you work with WMI. They are not part of the WMI model of things you can manage.
In Figure 3, SWbemObject represents a WMI class, Win32_SomeClass, which has properties: Property_1, Property_2, and Property_3. It exposes them through its own Properties_ property. Of course, if it's bound to another WMI class, Win32_SomeOtherClass, then the name of its property doesn't change. It's still Properties_. But the properties of the class to which it is bound will likely be different.
Essentially, SWbemObject takes on the properties of the particular WMI class to which it is bound, but it lets you get at those differing properties using the same Properties_ mechanism. Make sense? Take another gulp of coffee and meditate on the diagram. It will all become clear.
The script in Figure 4 leverages SWbemObject and its Properties_ property to retrieve and display all of the properties of the Win32_Service WMI class. The beginning of the script should be familiar. The primary change is that we factored out the namespace and WMI class, making them easier to change. For instance, you can just change the value of strClass to Win32_BIOS to see the properties of that class instead of those of Win32_Service. In the For Each loop, we iterate through the SWbemPropertySet collection (objClass.Properties) displaying the Name of each SWbemProperty.
Figure 4 Getting the properties of Win32_Service
strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Set objClass = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
    strComputer & "\" & strNameSpace & ":" & strClass)

WScript.Echo strClass & " Class Properties"
WScript.Echo "------------------------------"

For Each objClassProperty in objClass.Properties_
    WScript.Echo objClassProperty.Name
Next

Methods
Finally, some WMI classes go beyond modeling properties or characteristics of a manageable entity and include methods that provide access to behaviors or actions that an entity can take—or have taken against it.
The format of the script to return all the methods of a WMI class (shown in Figure 5) exactly parallels the script that returns properties.
Figure 5 Getting the methods for a WMI class
strComputer = "."
strNameSpace = "root\cimv2"
strClass = "Win32_Service"

Set objClass = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
    strComputer & "\" & strNameSpace & ":" & strClass)

WScript.Echo strClass & " Class Methods"
WScript.Echo "---------------------------"

For Each objClassMethod in objClass.Methods_
    WScript.Echo objClassMethod.Name
Next
The difference, of course is that the Methods_ property is used instead of the Properties_ property. Now, I wonder, would it also be possible to display the types of the parameters these methods take? How might we display only the WMI classes that actually have methods? These are the kinds of questions that you should try to write scripts to answer after you finish reading this column.
Hopefully we've provided you with a useful first glimpse into how to probe the depths of WMI. You do have to make your way through a thick forest of SWbem*s. But scripts provide a nice, lightweight mechanism for going deep. The two winter camping friends weren't so lucky. They never really made it very deep. It turns out an adequate supply of the necessary fermented beverages wasn't very easily transported into the depths in the middle of winter.

The 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.


The Desktop Files Data Loss Prevention with Enterprise Rights Management
Wes Miller

Contents
Thinking about Data Loss Prevention
Building Blocks of Rights Management
How Does It Work?
Where Are the Holes?
Are You Protecting Your Assets?
At my day job, I work for a company that makes a whitelisting application, which fundamentally reverses the typical security approach that protects your computer. There's another approach to security, perhaps also atypical, that I'd like to discuss this month—Enterprise Rights Management and why it's the only way to truly protect confidential information.
At this year's RSA Conference in San Francisco, I was walking the show floor, comparing the wares being offered by each of the vendors, and I have to say I was confounded. With very few exceptions, the vendors on the show floor were selling reactive—not proactive—security solutions. Let me explain. When you construct a building, you secure it by including locks on the doors and windows. If you want more security, you get an alarm system. Want even more? Add a fence. What you don't do to secure a building is leave out the locks, the alarm, and the fence, and just hire a guard or two to walk around. By itself, that won't protect anything.
Additional Resources

Information Rights Management in the 2007 Microsoft Office system
office.microsoft.com/en-us/help/HA101029181033.aspx

Information Rights Management in Windows SharePoint Services
msdn.microsoft.com/library/ms458245

Windows Rights Management Services
microsoft.com/windowsserver2003/technologies/rightsmgmt

Windows Server 2003 Rights Management Services
technet2.microsoft.com/windowsserver/en/technologies/featured/rms/default.mspx

RMS: Protecting Your Assets
blogs.technet.com/rmssupp/default.aspx

Windows Rights Management Services Partners
microsoft.com/windowsserver2003/partners/rmspartners.mspx

Thinking about Data Loss Prevention
Here's a more realistic example. I've had many customers ask about blocking USB ports to keep information from leaking out of their company (after we have eliminated concerns about inbound threats). But the reality is that trying to stop data flow at the port itself doesn't protect you at all. In fact, it's just like leaving a building completely unsecured, then hiring that guard. Sure, he's a nice guy—but he simply can't realistically cover all of the entrances and exits. At the end of the day, in both scenarios, it's the wrong tool for the job.
The problem with blocking access to the port—and with all of the other solutions that attempt to help you scan or secure your UNC shares, or do stateful packet inspection, or do other kinds of inspection—is that they all are reactive. They all try to catch the data as it leaves your organization. But by then, it's usually too late.
This reminds me of a scenario that used to occur at Microsoft (and I'm sure will sound familiar to you, as well). In the era before Information Rights Management (IRM) in Microsoft Office and Rights Management Services (RMS) in Windows, any interesting e-mail, even if clearly marked confidential, would be forwarded to the press by the end of the business day. Unfortunately, policies, strong words, packet inspection, share security, and even the threat of termination can only go so far. Something more is needed—and that something may just be the rights management technologies from Microsoft, which can help you protect your Office content. I've become a fan of IRM and RMS primarily, as I've grown to respect them as security solutions instead of merely auditing, monitoring, or compliance technologies.
What are the advantages of IRM/RMS in protecting Office content over ordinary password protection of that content?
  • There are brute-force mechanisms that can compromise the password protection that is used by Office documents.
  • Ordinary password-protected content is not encrypted in the same way that IRM/RMS-protected documents are.
  • IRM and RMS work together to protect content at the lowest levels within Windows.
  • IRM/RMS lets you protect content using very granular access controls, which are assigned to Active Directory accounts.
But what exactly are IRM and RMS? These technologies, first shipped with Microsoft Office 2003, allow you to protect intellectual property that is stored in Office documents, including e-mail read through Microsoft Outlook, Outlook Mobile Access, and Outlook Web Access through Internet Explorer, by encrypting the documents and controlling access to the content itself.
Most Office document types, including the new XML-based documents, as well as e-mail, can be encrypted, though .msg files (e-mail messages often attached to other e-mail messages) can't. (Visit office.microsoft.com/en-us/help/HA101029181033.aspx for a complete list of the file types you can manage with IRM.) The document is not decrypted until it is opened by a user who has been authorized by the originator of the document.
IRM is essentially the rights management front end, exposed through an RMS-enabled app, while RMS is the back end. An RMS server holds the information used to identify the rights that have been granted to users and verifies the credentials of those users. The IRM component in the RMS-enabled app lets you set and manage those rights. Together IRM and RMS allow authorized users to read, change, or exert full edit control over a document (depending on the assigned rights).
When an authorized user opens IRM-protected content through an Office application, the content is decrypted and made readable or editable within that application. Keep in mind that although IRM and RMS work to keep information secure, there is always the potential for a user who is truly dedicated to compromising it to do so. If a user elects to use the "analog hole" (a digital camera or other screen-capture software, or even to retype crucial information by hand), there is little that IRM can do to protect the information. For most scenarios, however, this is pretty strong security.

Building Blocks of Rights Management
The Microsoft rights management solution consists of four components that I'll cover in detail. I'll also briefly describe the RMS SDK and the useful RMS Toolkit. The first component is built-in; the others can be downloaded from microsoft.com/windowsserver2003/technologies/rightsmgmt.
Information Rights Management A component built into Microsoft Office 2003 and the 2007 Office system (as well as the mobile versions of Outlook, Excel, Word, and PowerPoint through Windows Mobile 6x), it lets users assign permissions to Word documents, Excel workbooks, PowerPoint presentations, InfoPath forms, Outlook e-mail messages, and XML Paper Specification (.xps) files, thus allowing or preventing recipients of those files from forwarding, copying, modifying, printing, faxing, cutting and pasting, and using the Print Screen key. You can set the permissions on a per-​user and per-document basis.
In an Active Directory environment, you can also set permissions for groups, and if your organization uses Microsoft Office SharePoint Server 2007, you can set permissions on libraries (note that technically, content is decrypted when stored on SharePoint, then re-encrypted when served to users). Unless set to expire, IRM permissions remain with a document no matter when or where it is sent.
IRM is not available for Office versions for the Apple Macintosh, but there are ways for Mac users to utilize RMS-protected content. Stay tuned for next month's column for details.
Rights Management Services (Server) This is available for Windows Server 2003 and is an available role in Windows Server 2008. RMS server is the heart of the Microsoft Enterprise Rights Management. It takes care of certifying trusted entities (users, client computers, and servers), defining and publishing usage rights and conditions, enrolling servers and users, authorizing access to protected information, and providing the necessary administrative functions that allow authorized users to access rights-protected information.
Figure 1 shows the Server Manager screen that lets you install the RMS role on a Windows Server 2008 system. Though RMS has quite a few dependencies, the wizard will walk you through the entire process, installing all dependencies for you.
Figure 1 Selecting the Rights Management Services server role
The RMS server role (on either Windows Server 2003 or Windows Server 2008) requires a server system with:
  • Microsoft Message Queue Server (MSMQ)
  • IIS with ASP.NET enabled
  • Active Directory
  • Either SQL Server Enterprise Edition (for a production environment), the Microsoft SQL Desktop Engine (MSDE), or SQL Server Express (fine for a testing environment)
As noted, even if you do not have any of these components installed, they will be configured for you during installation on Windows Server 2008. For a production implementation, you will want a valid SSL digital certificate for your server(s) so that RMS can properly maintain security between clients and servers. However, for testing, RMS can provide a test certificate installed as a part of the role installation. Figure 2 shows what the RMS console looks like running under Windows Server 2008.
Figure 2 The RMS console
Rights Management Services (Client) This allows RMS-enabled applications to work with the RMS server to enable publishing and consuming of rights-protected content. The client is built into Windows Vista and Windows Server 2008; for earlier versions of Windows, it can be downloaded and installed to give those operating systems RMS capability.
If you're building out your own enterprise deployment, you will more than likely want to deploy the RMS client through new systems, Group Policy, or System Center Configuration Manager (SCCM) instead of having users deploy it manually.
Rights Management Add-on for Internet Explorer For Internet Explorer 6.0 and later, it allows you to view rights-protected content from inside Internet Explorer.
RMS SDK Allows developers to build their own applications that can protect their own custom content by using the SOAP-based Rights Management Services API.
RMS Toolkit You will probably find, as I have, that the RMS Toolkit is immensely useful in deploying and troubleshooting your own RMS infrastructure. The Toolkit contains a number of handy programs that can help you make sure your RMS system is working as it should. Note that the RMS Toolkit is not actually part of RMS and, as such, is not officially supported by Microsoft.

How Does It Work?
When you protect a document using RMS by clicking Protect Document under the Review tab in Word 2007 or Protect Workbook in Excel 2007, you must specify the account that you want to use as the author of the document—the account with ownership privileges on the document. This should ideally be an Active Directory account, though RMS does allow you to use a trial Windows Live account—which you may not want to use for an actual production system.
Once you've authenticated with an account (see Figure 3), you can specify that account or add accounts as the owner. Then, you can quickly specify high-level rights (see Figure 4) or more granular rights for users you want to have permissions to read or change the document you are protecting.
Figure 3 Specifying the account to use
Figure 4 Setting permissions
You have now protected the document. As a result, any users who attempt to open the document will have to provide credentials before it can be opened. Furthermore, the privileges defined by the owner of the document will be enforced.
RMS uses IIS and ASP.NET to authenticate any user who opens the document, to verify his identity and access rights, and to convey this information back to the RMS client and the IRM infrastructure in Office. Based upon Active Directory and the rights defined by the RMS server, the end user will either be allowed complete or limited access to the document, or none at all.
RMS uses an infrastructure that relies on XrML (extensible rights Management Language) to describe the rights held by end users of IRM-protected content. In effect, these rights are contained in an XrML license that can be attached to the digital content and thus persist. Because XrML is a standard, this language can also be used by other applications looking to protect content in a similar manner. You'll find more information at xrml.org.

Where Are the Holes?
As I mentioned earlier, RMS and IRM aren't bulletproof; if a malicious "authorized" user is dedicated to compromising IRM-protected content, it'll take some work, but he can do so.
Moreover, the content is potentially susceptible to interception by subversive malware and by screen-capture software working in non-standard ways. While RMS works hard to prevent screen captures and unauthorized cut-and-paste activity, it can only go so far. I have seen some solutions that attempt to go a bit further than IRM and RMS and protect additional content types. For other ISVs building solutions around RMS, see microsoft.com/windowsserver2003/partners/rmspartners.mspx.
Enterprise Rights Management is, I believe, the only rational way to truly secure content "not at rest" on systems today. If you examine the types of content compromised today—e-mail, Office documents, and so forth—most of them could be easily protected with IRM and RMS, but they aren't. While full-volume encryption technologies such as BitLocker in Windows Vista allow you to secure content at rest and to generally keep it secure in the event of a system compromise, they don't protect content that is on shares, on e-mail servers, or on SharePoint servers.
Because content generally can't be protected "in the wild," solutions have evolved that try to track content down and eliminate it. IRM and RMS were well designed to plug into Active Directory, Exchange, Office, and Windows—and as a result, don't take much of a training curve, especially for the end users actually consuming content—and the protection they can provide is immense. Please see the "Additional Resources" sidebar for more information.

Are You Protecting Your Assets?
Are you using RMS and IRM in your organization today? Send me your thoughts on RMS and IRM—I'd love to hear from some readers as to how and why you have (or have not) deployed RMS and IRM, or if you believe that your organization is secured from data loss through another mechanism.

Wes Miller is a Senior Technical Product Manager at CoreTrace (CoreTrace.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at technet@getwired.com.


Security Watch Revisiting the 10 Immutable Laws of Security, Part 2
Jesper M. Johansson

Contents
Law #4: If you allow a bad guy to upload programs to your Web site, it’s not your Web site anymore.
Law #5: Weak passwords trump strong security.
Law #6: A computer is only as secure as the administrator is trustworthy.
Law #7: Encrypted data is only as secure as the decryption key.
Conclusion
In last month's issue of TechNet Magazine, I kicked off a three-part series revisiting the well-known essay "10 Immutable Laws of Security." My objective is to evaluate them, eight years after they were first postulated, and see whether or not they still hold—in other words, to see if they really are "immutable." (You can find the first part of this series at microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.)
I found that the first three laws hold up pretty well. Now I'm ready to scrutinize four more of the laws. In next month's final installment, I will discuss the final three laws, as well as offer some new insight that benefits from eight years of hindsight.

Law #4: If you allow a bad guy to upload programs to your Web site, it's not your Web site anymore.
You may be thinking that Law 4 sounds a bit strange. After all, the other laws are quite high level, not speaking about specific services but general functionality. The first three laws all describe scenarios where your computer is no longer your computer. Then you reach Law 4, which talks about Web sites.
To understand Law 4, historical context is quite important. The laws were originally published in 2000. This was a time when the Web was still fairly new and immature. Sites like Amazon and eBay were still developing. And while exploits that ran arbitrary commands on Web sites were commonplace, patching them was not.
Against that backdrop, Microsoft likely saw Law 4 as a necessary public statement that you need to take responsibility for what your Web site serves. This point was driven home, sledgehammer style, in September 2001 when Nimda struck. Nimda was a multi-vector network worm, and one of the vectors it used for spreading was to infect vulnerable Web sites and modify them to carry the worm.
The time frame surrounding Law 4 was also one of Web site defacements. Attrition.org runs a mirror of many of the defacements from that time (attrition.org/mirror/attrition/months.html). There were many of these defacements, often of prominent sites. Even notable security training organization SANS Institute had its homepage defaced. Figure 1 shows the defacement of the State of Arizona Web site in October 1998.
Figure 1 Defacement of the State of Arizona Web site
The problem was that, back then, people were generally unclear on what really happened when a Web site was defaced. The consensus was that you got rid of the offending page and went on with life. If you were on the ball, you patched the hole that the bad guys used (if you could find it).
People weren't looking at the full picture. Law 4 was designed to make people think about what could have happened when a Web site was defaced, not what did happen.
Unfortunately, Law 4 was not entirely successful. In spite of Law 4, by 2004 I had grown weary of answering the question: "Can't we just remove the Web page the hacker put up and go on with our business as usual?" Not a man of few words, I tried to dispel those notions again with an article called "Help: I Got Hacked. Now What Do I Do?" (technet.microsoft.com /en-us/library/cc512587.aspx).
The question, however, is whether Law 4 still holds today. Does a bad guy really own your site if he can upload a program to it? More granularly, does he own your site, or your visitors, or both? Law 4 is not actually clear as to which it refers, so I'll analyze both.
With respect to owning your site, the answer is yes. The bad guy owns your site if you let him put programs on it (there are, however, a few exceptions that I will look at in a moment). With a typical Web site, there are two things the bad guy can do by uploading programs, and there is one very big implication from the fact that he is able to upload to your site.
The first thing the bad guy can do is make your site serve his needs. If somebody is interested in serving out illegal content, such as child pornography, what better place to do so than on a site that cannot be traced back to the hacker himself? Criminals would much rather serve that type of content off your Web site than off their own.
The second thing the bad guy can do by uploading a program to your site is to take control of the system behind the site. This, of course, is dependent on whether he can actually execute the program on your Web server. Simply having the program there without it doing anything is not going to help. However, if the bad guy can execute the program, he definitely owns your site and can now not only make it serve his own needs but also use it to take over other things.
The implication to which I referred is even more important than the specifics. In the "Help: I Got Hacked" article, the point I was trying to make was that you don't know exactly what the bad guy may have done after he broke in. If a bad guy manages to put his own content on your site, then you have to ask what else he could have done.
The answer could potentially be a lot of things. That is the really critical part of this puzzle. If a bad guy can execute programs on a server behind your Web site, he completely owns that site and what it does. It truly isn't your Web site any longer.
With respect to compromising the visitors to the site, that question is harder to answer. Browsers were riddled with security holes in the late 1990s. Around 2004, the situation improved drastically. Today's major browsers, Internet Explorer and Firefox, are both quite solid in terms of security. In fact, compared to what we had in the 1990s, today's browsers are veritable bastions of security.
Whether a bad guy can compromise your visitors is highly dependent on two things. First, are there holes in the browsers that he can exploit? There may be, but there are not nearly as many as there used to be. And second, can the bad guy persuade users to compromise themselves? The answer, disturbingly often, is yes.
Far too many users will install things that a Web site tells them to install. This is a serious problem, as we cannot solve this one with technology. In the July, August, and September 2008 installments of Security Watch, I discussed this problem. With respect to Law 4, it unfortunately means that the bad guy has a very good chance of being able to compromise your visitors.
The exceptions mentioned earlier should be obvious. Web sites do many things today that were not foreseen back in the late 1990s. For instance, internal collaboration sites, such as Microsoft SharePoint, are common. Anyone with proper permissions can upload a program to such a site, but it means that neither the site, nor any user that goes to it, will be compromised. That is simply what the site is designed for. Users are considered trusted, to some extent, merely by virtue of having the permissions necessary to access the site.
And then there are shareware sites. While there has been malware posted to them in the past, they are designed to share software. That in and of itself does not mean that any user is compromised. In short, all these sites have safeguards in order to ensure that they stay secure and that users are not automatically compromised by going to them. I consider that the exception that confirms the rule. Therefore, Law 4, at least in spirit, still holds—in spite of some sites that are designed to permit people, bad and good, to upload programs to them.

Law #5: Weak passwords trump strong security.
Passwords have been a passion of mine for many years. Passwords or, more generally, shared secrets are a great way to authenticate subjects. There is just one minor problem with them: they fall down completely in the face of human nature.
Back in the halcyon days of computing when time-sharing computing was first invented, the need for a way to distinguish between users became apparent. The system needed a way to distinguish between Alice's data and Bob's data. Ideally, Bob should be able to prevent Alice from reading his data, although this was a loose requirement.
The solution was user accounts and passwords. We used to have one account on one computer system. And we generally had one password, which was usually one of the following:
  • The name of one of your children
  • Your spouse's first name
  • Your pet's name
  • "God" (if you were the superuser)
Fast-forward 30 or so years. We now have hundreds of accounts—on Web sites all over the Internet and on several computers. Every one of those systems tells us that we should not use the same password on any other system. You are advised to make it strong, not to write it down, and to change it every 30 to 60 days.
Because ordinary humans cannot change four passwords a day and actually remember any of them, the net result is that they, unfortunately, use the same password on all systems (or possibly two different passwords). And they are typically chosen from the following list of possibilities:
  • The name of one of your children with the number 1 appended to it
  • Your spouse's first name with the number 1 appended to it
  • Your pet's name with the number 1 appended to it
  • "GodGod11" (only if you are the superuser)
We have not advanced nearly as far as one would hope in the intervening 30 years. Researchers are still finding passwords a fruitful area of research; for more information, see the PC World article "Too Many Passwords or Not Enough Brainpower" (at pcworld.com/businesscenter/article/150874/too_many_passwords_or_not_enough_brain_power.html).
Clearly, passwords, as they are normally used, are a very weak form of security. Yet there are ways to use passwords securely. For instance, you can generate strong passwords and write them down—there really is nothing wrong with that. However, people are so inundated with bad security advice from everywhere and everyone that users actually think it is better to use the same password everywhere than to write down their passwords.
The fact is that a whole lot of security boils down to one weak point. Take corporate Virtual Private Network (VPN) access, for example. I have been in numerous discussions about various VPN technologies; vendor evaluations where the vendors point out the virtues of their incredibly strong, and incredibly slow, cryptography; how they rotate the encryption keys to make sure an attacker can't sniff packets and cryptanalyze them.
But all of that completely misses the point. An attacker is not going to try to cryptanalyze a packet stream that will take 10 million years to break using currently available computing technology. Is there really any value in slowing down the network by an order of magnitude to obtain cryptography that will take 100 million years to break? Honestly, I don't particularly care if someone 100 million years from now (or even 10 million years from now) somehow manages to decrypt my work e-mail.
Is the cryptography really the interesting weak point? The attacker is far more likely to exploit the easy vulnerability—the fact that user passwords are often one of the passwords I just listed.
Incredibly strong cryptography doesn't really matter much if all of your users pick a six- or eight-character password. Consequently, we are now moving toward using stronger forms of authentication, such as smart cards and one-time PIN code generators.
These offer a huge improvement, but they do not always improve security. Smart cards, for instance, are very easy to lose or leave at home. And the one-time PIN code generators fit perfectly on your badge holder, which looks great hanging around your neck. The next time you go out to grab a coffee at the shop across the street, see if you can spot the guy looking at your current one-time PIN, reading your user name off your badge, and trying to guess the little tiny piece of randomness that is all he now needs in order to connect as you to your corporate network.
Law 5 most certainly holds today, and it will continue to hold into the future. However, I think it can be significantly generalized. More than just weak passwords trump strong security. More generally, it can say "weak authentication" or even "weak points" trump strong security.
IT security professionals at large are guilty of not stepping back and looking at the broader picture. We tend to focus on one small piece of the problem, one that we can comfortably solve with strong security technologies. Too often we fail to realize that there are systemic weak points that we have not mitigated, or even thought about, that render all the technology we are putting in place moot.
For instance, consider how many organizations try to regulate the removable devices that users can use, but permit outbound Secure Shell (SSH) and encrypted e-mail connections. How much data loss is really mitigated by limiting removable devices if you permit data to be transmitted with encryption so you can't even see the data? This is one of the major problems that we security professionals must solve if we are to survive and prosper.

Law #6: A computer is only as secure as the administrator is trustworthy.
I am amazed that, even today, we keep seeing reports of exploits that only work against administrators—even worse, exploits that only work if you are already an administrator. As I am writing this I am sitting in an airport on my way back from the Black Hat 2008 conference. Even there I caught a presentation that started out with the premise that "if you have root access, here is how you can take over the system."
On the one hand, it is comforting to know that the worst thing some people can come up with is how to modify the system, albeit a bit more stealthily, if they already have the right to modify the system. On the other hand, I find it frustrating that people do not seem to see how pointless that is and keep trying to invent new ways to do it—and more important, waste precious time and energy on protecting against it.
The fact is quite simple: any user who is an administrator (or root, or superuser, or whatever else you may call the role) is omnipotent within the world of that system. That user has the ability to do anything!
There are certainly noisier as well as subtler ways to do whatever it is a malicious user of this sort wants to do. But the fundamental fact remains exactly the same: you can't effectively detect anything that a malicious administrator does not want you to detect. Such a user has the means to hide his tracks and make anything appear to be done by someone else.
It is clear, then, that Law 6 still applies, at least at some level. If an individual that has been granted omnipotent powers over a computer turns bad, it really, truly, is not your computer any longer. In a very real sense, the computer is only as secure as the administrator is trustworthy.
There are some additional points to consider, however. First, the notion of administrator, from the computer's perspective, includes not only the person or persons granted that role. It also includes any software that is executed in the security context of that role. And by extension, then, the role of administrator also includes any author of any such software.
This is a critical point. When Law 6 states that the computer is only as secure as the administrator is trustworthy, the meaning is much broader than it first seems. Never forget that, as far as the computer is concerned, administrator means any process running within the security context of an administrative user. Whether that user intended to actually execute that piece of code or intended to do damage with it is irrelevant.
This is a critical point because it is only recently that an average user can feasibly operate a Windows-based computer as a non-administrator. This is a primary purpose of User Account Control (UAC) in Windows Vista. Even then, there is no security boundary between a user's administrative context and non-administrative context. Consequently, Law 6 applies to any user that has the potential to become an administrator, not just those who are administrators at the moment.
As a result, the only way not to be subject to Law 6 is to truly not be an administrator, but rather operate as a true standard user. Unfortunately, this is not the default even in Windows Vista, and many Original Equipment Manufacturers (OEMs) actually disable UAC altogether.
UAC, however, hints a little at the future to come. The most visible feature of UAC is the elevation process, shown in Figure 2. However, the most important strategic benefit is not elevation to an administrator but the ability to operate a computer effectively without being an administrator in the first place. Windows Vista includes several improvements to make that possible. For example, contrary to earlier versions of Windows, you can change the time zone without being an administrator, permitting travelers to be non-admins. Moving forward, there will likely be more of those types of improvements.
Figure 2 The most visible, and possibly least important, feature of UAC is the elevation prompt
Law 6 holds today and will continue to hold. However, the switch toward a world where users can operate their computers as a non-admin is one of two major moderating factors on Law 6. The second factor is not very new: mandatory access control systems.
In mandatory access control systems, objects have labels and there are strict rules for how objects can be relabeled. Software applies security to an object consistent with its label, outside of the immediate control of the administrator. Strictly speaking, in current implementations, the administrator can typically take various illegitimate steps to override these controls.
However, the principle is promising, and it may be possible one day to limit what administrators can do. But even if we were to get restrictions to limit what administrators could do, you could still argue that those users would no longer be administrators in the real sense of the term. Hence, Law 6 is decidedly immutable.

Law #7: Encrypted data is only as secure as the decryption key.
Law 7 is possibly the least controversial of all the laws. Encryption is far too often seen as the panacea for many security problems. The truth, however, is that while encryption is a valuable tool in the world of security, it is not, and never will be, a standalone solution to the majority of problems we face.
Encryption is everywhere you turn. In Windows, encryption is used for passwords, for files, for surfing the Web, and for authenticating. Not all encryption is designed to be reversible, but some of the more important examples of reversible encryption include the Encrypting File System (EFS) and the credential cache used for stored passwords and usernames, as illustrated in Figure 3.
Figure 3 The credential cache in Windows Vista is protected by encryption
Both EFS and the credential cache are protected by an encryption key derived from the user's password. This has several implications. First, if the user's password is reset (set to a new password without entering the old one), all of the data stored in these locations will be lost unless there is a recovery key designated.
But even more important for our discussion, while the encryption itself uses extremely strong keys and protocols, the security of the key is dependent on the user's password. In other words, the data is no more secure than the password is strong. The password, in effect, is a decryption key even though, in this particular instance, it is a secondary decryption key—meaning it decrypts another decryption key.
This is crucial. These types of dependency chains are everywhere in the IT world. Years ago, someone executed a social engineering attack against VeriSign and obtained two code-signing certificates in the name of Microsoft. A code-signing certificate is effectively a decryption key, which is used to verify that the entity named in the certificate has the encryption key.
However, in this case, the person requesting the certificate was not the entity named in the certificate. In other words, the attacker now had signature keys in someone else's name. The keys may have been secure, but once you analyze the remainder of the dependency chain, you discover the fatal flaw.
All this serves to prove one point: the decryption key is critical to the security of data, but the decryption key itself may be protected by far weaker secrets. I have seen too many systems where the implementers built in the strongest encryption thinkable and protected the decryption key with some other security measure but failed to realize that this second layer had a significant hole. When implementing any cryptography, you must ensure that you analyze the entire chain of protection. Simply being encrypted does not by itself make the data secure.
Law 7 still holds then. It is one of the most unassailable of the 10 laws. In fact, it is the closest we get to a law of physics in this business. It should also serve as a lesson to all of us, reminding us to analyze the entire protection chain of our sensitive data. Therefore, it is acceptable to have keys that do not have the strongest protection possible, but it's important that those keys should only be used to encrypt data that merely requires that lesser level of protection.

Conclusion
So far, the immutable laws of security are 7 for 7. Each of the laws I have reviewed still holds true these many years later, and it looks unlikely that they will be significantly disproven anytime soon.
In fact, the laws have demonstrated an impressive bit of foresight. The only one that seems out of place so far is number 4, but, as mentioned previously, even that one should still be considered immutable.
Next month I'll wrap up this series with a look at Laws 8, 9, and 10. And I'll comment on where the laws may not cover all aspects of security.

Jesper M. Johansson is a Software Architect working on security software and is a contributing editor to TechNet Magazine. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security, and is a Microsoft Most Valuable Professional (MVP) in Enterprise Security. His latest book is The Windows Server 2008 Security Resource Kit.


Field Notes Old Wine in New Bottles
Romi Mahajan

One can find the central logical principle behind the enormous rise of Internet-mediated communities by invoking a 600-year-old heuristic: Occam's Razor. "Entia non sunt multiplicanda praeter necessitate," or, translated in English, "Entities should not be multiplied beyond necessity." In other words, let's not overcomplicate our theories about why the Internet has changed the creation of community in the world of IT. Instead, just go back to the basics to understand specifically how the Internet has not radically altered core conceptions of community but has amplified and scaled them to heretofore unknown dimensions.
Communities form and grow to satisfy three central needs and desires: first is our need to connect, communicate, and commune with others of similar bent; second is our need to learn from those with similar experiences; and last is our desire to be part of something larger than ourselves.
This was true before technology found application in our daily lives, clearly before the Internet, and will remain true even if one day we revert to Luddism. So where does the Internet appear in this equation? Or does it appear at all?
In the area of amplification, the Internet has a game-changing impact. By harnessing the power of the Internet, we can connect and communicate with stunning speed, with vast geographical footprint, and against an incredibly nuanced set of parameters.
In this way, we can exchange both simple and complex information (in a variety of forms) and quickly solve problems, find others like us, and create complex models of dissemination and diffusion (of knowledge, ideas, even digital commodities). We can even spend countless hours using the Internet, building to a social crescendo of sorts, without having to leave our own zones of enormous comfort.
In each area, we amplify speed, scale, nuance, and the ability to do so under terms that each of us determines. The amazing success of Facebook, MySpace, and hundreds of other communities on the Internet is testament to this process of amplification.
Another such area, ironically, is the use of the Internet to facilitate physical community gatherings. In the world of IT, the importance of everything from pub crawls to user group meetings to large industry-wide events cannot be overstated. The process of amplification helps communities nourish themselves and grow in the interstitial times between physical meetings.
Ultimately, however, it is this very fact of physicality that brings the limitations of the Internet into bold relief. Relationships that are based primarily on the Ether cannot go the full distance. And in many cases, these relationships cannot provide the feedstock for epoch-making innovation and inspiration.
Thus, I draw incredible energy from the IT events I attend in person, and particularly from visiting user group meetings where the passion and beneficence are indelible. The three fundamental needs I mentioned align with fantastic strength in these meetings. IT companies still launch products at trade shows. People still line up to hear IT luminaries speak and relish time with their peers.
IT communities, like general communities, are fundamental to the well-being of IT practitioners (and, therefore, of the industry as a whole). So we all need to redouble our efforts to nurture them, participate in them, and to use them to create the virtuous loops that have worked to inspire greatness and heroics from each of you reading this column.
To do so, we have to be clear where, in this process, the Internet plays a role and where physical and emotional connections are the lifeblood. Given the need to discontinue the enormous tax on the environment, the challenge is how to use the Internet for as much as we can while not forgetting to punctuate the digital packets with an occasional handshake.

Romi Mahajan is Chief Marketing Officer of Ascentium Corporation. Before joining Ascentium, he spent more than seven years at Microsoft where his last role was as Director of Technical Audience and Platform Marketing. Romi is widely published in the areas of technology, politics, economics, and sociology.


Windows Confidential Windows Can but Won’t
Raymond Chen

Windows actually can replace a DLL that is in use by renaming the original then copying the new file into place. However, the Windows world prefers not to do this. Why?
Even if you replace a file that is in use, there may still be code in the system that wants to use the old version. For example, suppose you have two files, A.DLL and B.DLL, which work together. You issue a patch that updates both of the files, but A.DLL is in use. No problem. You simply replace both of them. As a result, programs that were still using A.DLL keep using the old version, but new programs will use the new one. And all programs get the new version of B.DLL.
Now a program that was using the old A.DLL decides to call a function in. It naturally expects the old version of B.DLL, but instead it gets the new version. Depending on what sort of change you made to B.DLL, this call may work—or it may crash. Both DLLs assume that its partner comes from the same matched set.
Even if you're updating just a single DLL with no dependencies, there are still potential problems since the DLL has to interoperate with previous versions of itself.
Suppose you replace ole32.dll while it is in use. Then a newly launched program calls into the new ole32.dll and initiates a drag-drop operation. The user drags the object over a window created by one of the programs that launched before the update. You now have the new ole32.dll sending messages to the old ole32.dll.
When you write code that communicates between processes, you generally expect that the same version of the code will be running in each process, because the two endpoints in the communication channel have to agree on how they're going to communicate! "I'm going to send you message 5, which means 'request text,' and I expect you to reply by sending me message 12, which means 'here is the text you requested.'" If the two sides are not running the same version of the code, there's a chance that the communications mechanism will be different; it may be subtle, but it can, in fact, cause an incompatibility.
Say you added a field to a structure, and that structure happens to be used as part of message 5. Well, great. You now have two incompatible versions of message 5 out there—one that uses the old structure and one that uses the new structure. If the two sides of the communication disagree on the structure, message 5 will not work.
If you're going to support running the old and new versions side-by-side, then you have to invent a new message, say, message 52, and have the new version of the DLL support both message 5 and message 52. It has to figure out what version of the DLL is running on the other side first and send it the appropriate message.
Even if you haven't changed the structure itself, you may have changed the meaning of some fields in the structure. If the structure has an enumeration and the new version adds a new value to that enumeration, that's still an incompatibility between the old and new.
Sure, you can try to define new messages each time you issue a patch and write code to support interoperating between the old and new versions during the window in which two conflicting versions of the DLL are running at the same time. This, however, can get unwieldy when you're on your third patch and you have four different sets of messages—one for the original version and one for each of the patches.
Even if you require that the patches must be installed in sequence, it won't save you any effort; as long as you permit the original program to keep running, you have to continue interoperating with it.
And then people write articles complaining that you're an idiot because you're too slow to issue patches!
So it's not that Windows has to restart after replacing a file that is in use. It's just that it would rather not deal with the complexity that results if it doesn't. Engineering is a set of trade-offs. Do you go to the effort of supporting older versions of yourself for a situation that isn't even a recommended steady-state configuration?

Raymond Chen's Web site, The Old New Thing, and his identically titled book deal with Windows history and Win32 programming. He wishes you a safe trip home.