 TechNet Magazine September 2006

TechNet Magazine September 2006

System Management: Unlocking the Mystery of WMI Events in MOM

Virtually every noteworthy Windows event generates a WMI event. Find out how you can monitor WMI events with MOM to provide an even more powerful solution for systems management.

Brian Wren System Management: Zero Touch Installation: Automating Operating Systems Migrations

Get an overview of how SMS 2003 and some powerful new tools can make your next desktop OS deployment a no-touch operation. We’ll take a detailed look at the process involved for three common migration scenarios.

Jason Cross System Management: Gathering WMI Data without Writing a Single Line of Code

WMI is a powerful tool, but writing scripts to harness it can be intimidating. Here’s a hidden command-line interface that makes it easier to take advantage of WMI. Best of all, the tool is already on your system.

John Kelbley System Management: Getting Started with Windows PE

You may have encountered Windows PE during OS deployment. But did you know it can also be used for recovery, diagnostics, and repairs? Here’s a look at some of the things you may not have known about Windows PE.

Wes Miller System Management: Monitoring Security Events with MOM

Looking for ways to maintain regulatory compliance? Learn how you can use MOM Management Packs to monitor security events and report data as required by HIPAA and Sarbanes-Oxley.

John Orefice System Management: Essential Tools for MOM Administration

The MOM 2005 Resource Kit was recently refreshed and some handy new tools were added. Here’s a quick overview of some of the best utilities that will help you get a lot more out of MOM.

Dave Cristini, Matt Goedtel, and Eric Kamor System Management: Integrating MOM into Your Existing Infrastructure

A solid monitoring solution must be highly available and it must integrate with existing systems. From fault tolerance to connectors, here’s what you need to know for planning a MOM deployment that meets both of these requirements.

Andrzej Lipka System Management: Customize SMS Using Local Policies

Do you need to override SMS site settings for just a few machines or configure specific settings for only some clients? Find out how SMS 2003 local policies let you configure custom policy on a per-client basis.

Jeff Tondt System Management: Set High Standards: Powerful Tools for Configuration Management

Problems with system configuration can be disastrous. These tools and best practices can help you keep a handle on system configurations throughout your enterprise computing environment.

Jeremy Chapman From the Editor:

Around the time you read this, the United States Senate likely will be considering a communications bill that may or may not contain guarantees of something called "net neutrality. " If you haven’t heard of this yet, now’s the time to look into it because it’s a matter that could change the very nature of the Internet and the broadband apps and services your company uses online.

Joshua Trupin Toolbox: New Products for IT Pros

Greg Steen Utility Spotlight: Access-Based Enumeration

As a systems administrator, you've probably had users complain that they can't access certain folders they see in Windows® Explorer. The cause is often simple: the user doesn't have permission to open those resources.

James D. Silliman SQL Q&A: Predicates, Stored Procedures, and More

Edited by Nancy Michell Post Mortem: Self-Service Identity and Access Management

Microsoft IT Showcase and Lana Chin Business of IT: Understanding Regulatory Compliance

Tony Noblett TechNet Radio: An Interview with Alan Levine of Alcoa

Every week, TechNet Radio covers the latest trends and technologies in the world of IT, and provides interviews with real IT professionals who work in the field. Alan Levine, Chief Security Information Officer for Alcoa Inc.

Hey, Scripting Guy!: Late-Night Scripting

The Microsoft Scripting Guys Beta Box: System Center Operations Manager 2007

Stewart Cawthray Inside Microsoft.com: Release Management

Jim Scardelis Security Watch: Lock Up Your Domain Controllers

Steve Riley Field Notes: The Job Candidate’s Job

Glenn Wasserman What is TechNet?: Resources for the IT Professional

Windows Confidential: Why are Shortcuts Files?

Raymond Chen


 System Management: Unlocking the Mystery of WMI Events in MOM
System Management Brian Wren

Unlocking the Mystery of WMI Events in MOM
At a Glance:
  • Understanding the workings of WMI
  • MOM classes for event notification
  • Writing scripts to manipulate WMI objects
  • Sample event queries

Microsoft Operations Manager (MOM) is a great tool for keeping an eye on your environment, but it can sometimes be tricky to monitor a particular activity. If the activity can be watched through the Windows event log or a counter in Performance Monitor, then it is relatively easy to create a corresponding rule in MOM. If the activity cannot be monitored through one of these means, however, then a custom script is often needed. Such a script will typically be written to sample a particular resource on a predefined schedule and generate an alert upon detecting that the defined activity occurred.
For example, an application may rely on a Windows® process that is not a Windows service. If this process ends unexpectedly, there likely wouldn’t be an event written to the Windows event log or any other application log. The only way to determine if this process is still running is to execute a script on a periodic basis to ensure that it is still healthy. Rather than writing a custom script to sample a resource periodically, you can take advantage of Windows Management Instrumentation (WMI) events. Virtually every interesting activity in Windows generates a WMI event, and MOM includes a provider for monitoring all of them.
To monitor WMI events in MOM, a WMI event provider is created to collect the appropriate events generated on the monitored computer. An event processing rule uses this provider to generate a MOM alert.

Understanding WMI
In order to monitor WMI events in MOM, a basic understanding of WMI is required. WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM) as defined by the Distributed Management Task Force (DMTF). It is the primary management technology for Windows operating systems, permitting management of a variety of computing resources using a common language and common interfaces. You can write scripts with the WMI Scripting Library in order to inspect and modify computer resources represented by WMI classes. Before you do, however, there are a number of WMI concepts that you should know.
Common Information Model (CIM) Repository The CIM repository is the WMI schema that stores the class definitions that model WMI-managed resources. The repository holds the information required to work with live resources in the computing environment. It does not contain actual data about these resources since this data is dynamically retrieved as required. It is this schema that allows the wide variety of different resources to be uniformly managed.
Namespaces CIM classes are organized into namespaces. Each namespace in the CIM repository contains a logical group of related classes representing a specific technology or area of management. Any time a connection is made to WMI, a namespace must be specified. Only the classes contained within this namespace may be accessed by the connection.
The most important namespace for Windows management is root\cimv2. It contains the classes with the Win32_ prefix representing various components of the Windows operating system and hosting computer. Examples include Win32_Process (running processes in Windows), Win32_LogicalDisk (Windows logical disk drives), and Win32_ComputerSystem (the computer hosting Windows). This namespace also includes the CIM_DataFile class which can be used to monitor files and folders. Two other important namespaces are root\default, which contains registry events, and root\MOM, which contains classes for accessing MOM from external processes.
Class Every resource that can be managed by WMI is defined by a class. A class is a template for each type of resource and defines the properties that will be collected for that resource. Examples of common WMI classes are shown in Figure 1.
Figure 1 Sample WMI Classes (Close Figure 1)

Class | Description
Win32_Process | Processes running on a Windows computer
Win32_ComputerSystem | A computer running a Windows operating system
CIM_DataFile | A file stored on a disk
MSFT_Alert | An alert in MOM
Property A property is unique piece of information about an instance. All instances of a class will have the same set of properties although the values of each instance’s properties may differ. Some Properties of the Win32_Service class are shown in Figure 2.
Figure 2 Sample Properties of Win32_Service Class (Close Figure 2)

Property | Description
Name | Unique name of the service
DisplayName | Displayed name of the service
PathName | The command-line path that was executed to start the service
StartMode | Startup type of the service (Auto, Manual, or Disabled)
State | Current state of the service (Running, Stopping, or Stopped)
Instance An instance is a unique occurrence of a particular class. For example, each service installed on a computer running Windows is an instance of the Win32_Service class. The C: drive is an instance of the Win32_LogicalDrive class. Figure 3 shows sample properties of one instance of the Win32_service class.
Figure 3 Sample Properties of a Win32_Service Instance (Close Figure 3)

Property | Description
Name | Winmgmt
DisplayName | Windows Management Instrumentation
PathName | C:\WINDOWS\system32\svchost.exe -k netsvcs
StartMode | Auto
State | Running
WMI Events Just as each resource is identified by a WMI class, each type of WMI event is represented by a class. When an event occurs, an instance of the corresponding WMI event class is created. The two types of WMI event classes that are used by MOM are intrinsic and extrinsic. (Note that there is also an event class type of Timer that is rarely used. This type is not relevant to MOM so I won’t discuss it here.)
Intrinsic events are used to monitor resources that have a WMI class. Each time an instance of any such class is created, modified, or deleted, an intrinsic event is generated within the class’s namespace. The most common intrinsic event classes used in MOM are __InstanceCreationEvent, __InstanceDelectionEvent, and __InstanceModificationEvent. (Notice the double underscore characters at the beginning of each name.) Extrinsic events are used to monitor resources that are not represented by a WMI class. There is no common set of extrinsic events, and individual ones must be implemented for a particular resource using them.
The most common extrinsic events that would be used in MOM are for monitoring the registry. The registry must use extrinsic events since there is no WMI class for individual registry settings (the intrinsic events associated with the Win32_registry class represent the registry as a whole). The registry-related extrinsic events are RegistryKeyChangeEvent, RegistryTreeChangeEvent, and RegistryValueChangeEvent, and are located in the root\default namespace.
Other applications may implement extrinsic events that may be monitored. It is their responsibility to provide the names and other information for these events. The Application Center 2000 Management Pack, for example, has a number of WMI Event Providers using these events.

WMI Tools
Tools for working with WMI include CIM Studio and Object Browser, which may be used to inspect the WMI repository and determine the appropriate class and related properties to monitor. The toolset also includes the WMI Event Viewer and WMI Event Registration Editor.
While all of these tools are useful, all the required functionality for the purposes of this article can be achieved with CIM Studio, which is designed to work with classes defined in the CIM Repository. The first step in using WMI events in MOM is determining the class corresponding to the resource of interest, and CIM Studio may be used for this purpose.
When CIM Studio is started, you are required to connect to a namespace. This will default to root\cimv2, which is typically the namespace you will be using anyway. The namespace can be changed later by typing a new one into the textbox in the top left-hand corner of the UI. By default, you will be connecting to the local machine, but you may specify another computer by clicking on the computer button. Fortunately, WMI lets you connect to a remote repository as easily as to a local one. CIM Studio looks daunting when first started, and it does provide a complete set of services for working with WMI, but for the purposes of this article you won’t have to worry about most of that complexity.
The simplest method of locating a class is to search the repository. This is done by clicking on the binoculars button next to the namespace textbox (the result is shown in Figure 4). This example returns a set of classes that include the word "process" in their name, including the class I’m interested in: Win32_Process. Selecting this class will cause it to be displayed in the tree in the left pane. The details of the class will appear in the right pane (see Figure 5). The most important information is the list of properties. The property names may be used for specifying criteria in WMI notification queries.
Figure 4 Class Search in CIM Studio
Figure 4 Class Search in CIM Studio
In addition to the structure of the class, CIM Studio can display the instances of the class with their values for each property. Instances can be viewed by clicking the Instances button with the appropriate class selected. The Instances button is located in the top-right of the CIM Studio window. It is circled in Figure 5.
Figure 5 Win 32_Process Class in CIM Studio
Figure 5 Win 32_Process Class in CIM Studio
The instances viewed in CIM Studio represent live data extracted from the operating system. In the example of Win32_Process, these are the details of the processes currently running on the computer. Figure 6 shows an example. The information in this view can be valuable in determining the criteria required for a WMI query since the value of each property is provided.
Figure 6 Instance View in CIM Studio
Figure 6 Instance View in CIM Studio

WMI Notification Queries
A WMI notification query leverages WMI events that provide notification when a particular action occurs. Executing a query creates a WMI event subscription, which is similar to a Simple Network Management Protocol (SNMP) trap. When the requested event occurs, the subscribing process is notified and can take appropriate action.
The query parameter of a WMI event provider is a WMI notification query and is the most important and most complex parameter of the provider. Therefore I’ll cover the structure of these queries in further detail. A WMI notification query typically includes the parts listed in Figure 7.
Figure 7 Sections of WMI Notification Event Query (Close Figure 7)

Keyword | Example Code | Description
SELECT | SELECT | Specifies what properties are returned. Typically the * wildcard is used to simply retrieve all properties.
FROM | FROM__InstanceCreationEvent | Specifies the event class to query. This will be the extrinsic or intrinsic event class.
WITHIN | WITHIN 60 | Polling interval. Specifies how many seconds should elapse between samples. For intrinsic events only.
WHERE | WHERE TargetInstance ISA ‘Win32_Process’ AND TargetInstance.Name = ‘notepad.exe’ | Filters the results. For intrinsic events, will usually include the ISA keyword to specify the class of the TargetInstance.
Note that the WITHIN clause specifies the polling interval for intrinsic event classes. Because the class being monitored does not have a corresponding event provider, the WMI polling mechanism is used to periodically check if an intrinsic event has occurred for the particular class. This polling interval is specified by the WITHIN keyword and measured in seconds.
If the polling rate is set too low (typically under 30 seconds), then excess overhead may be generated. If the polling rate is set too high, then events may be missed. For example, if the polling rate is set to 60 seconds when looking for the creation of a Windows process, a process may start and end within the 60 seconds. In this case, no event would be recognized. In addition, the detection of the event will be delayed up to the length of the polling interval. A general rule of thumb for MOM notifications is to set the polling interval to 60 seconds. This ensures that MOM detects any events in under a minute, limiting overhead on the agent computer.
Extrinsic event classes typically do not require the WITHIN keyword since the class being monitored has its own event provider. In this case, the polling mechanism is not used. For intrinsic event classes, the WHERE clause will typically have two parts. The first part specifies the class being monitored using the TargetInstance object with the ISA keyword. Here’s an example:
WHERE TargetInstance ISA ‘Win32_Process’
The ISA keyword (is a) is similar to an equals sign, but must be used instead because TargetInstance is an object, not a simple string. Note that the name of the class (Win32_Process in the example) must be contained within single quotes.
The second part of the WHERE clause contains one or more filters to narrow the results. These will use the AND or the OR keyword and attributes of the TargetInstance object and potentially the PreviousInstance object. TargetInstance is generated by all events and represents the WMI instance resulting from the event. PreviousInstance is only generated by instance modification events and represents the instance just prior to the event. Both the TargetInstance object and the PreviousInstance object will be of the same class as the class being queried and have all the same attributes. Here’s an example:
SELECT * FROM __InstanceDeletionEvent
WITHIN 60
WHERE TargetInstance ISA ‘CIM_DataFile’
AND (TargetInstance.Name = ‘c:\\AppFolder\\CriticalFile1.Log’
OR TargetInstance.Name = ‘c:\\AppFolder\\CriticalFile2.Log’)
Note the use of single quotes to specify strings and double backslashes in place of each backslash. These are required conventions of WMI.
Extrinsic event classes will not use the TargetInstance object or the ISA keyword since their class is already defined. They will use the WHERE clause to filter results, as in the following example:
SELECT * FROM RegistryValueChangeEvent
WHERE Hive=‘HKEY_LOCAL_MACHINE’
AND KeyPath=‘Software\\Mission Critical Software’
AND ValueName = ‘TraceLevel’
With extrinsic events, the properties are used with their simple name. This is distinctly different than intrinsic events, which are in the form TargetInstance.Property. This is because properties used in intrinsic events are properties of the TargetInstance object.

Testing WMI Queries
The most difficult part of creating a WMI notification provider and rule is writing and testing the WMI notification query. In order to test the query using MOM, a provider and event rule would need to be created, deployed to an agent, and then an activity simulated to trigger the MOM event. If there is a problem, there will be little available information to assist in determining the cause.
The Windows Management Instrumentation Tester (WBEMTest), which is installed by default on all computers running Windows XP, Windows Server 2003, and Windows 2000, can be used to test a WMI query quickly and easily prior to placing it in MOM. Note that the WMI Event Viewer and WMI Event Registration Editor can also be used for this purpose. These tools are more refined than WBEMTest but are also more complex. In addition, the WMI Event Registration Editor creates permanent registration which can remain after the tool is closed. WBEMTest is more straightforward to use and does not leave registrations after it is closed.
Let’s now look at the process for testing a WMI notification query. There is no icon for starting WBEMTest. Simply select Start | Run and type wbemtest. When it loads, connect to a WMI namespace by clicking on the Connect button. The only field in the resulting dialog box (shown in Figure 8) that will typically be required is the unlabeled box that requires the name of the namespace to connect to. This will typically be root\cimv2 or root\default. Change it if required and click Connect.
Figure 8 Connect to a Namespace
Figure 8 Connect to a Namespace
Once a valid namespace has been specified, the buttons in WBEMTest become enabled. Click the Notification Query button to test the WMI Query Language (WQL) intended for MOM providers (see Figure 9). Once you do, a dialog box will appear to allow you to type in the WQL for a notification query. After clicking the Apply button, if there is a problem with the WQL, you will receive an immediate error message similar to ones in Figure 10. The error message may or may not be descriptive enough to help you root out the problem, but it is a clear indication that the query is invalid and requires modification.
Figure 9 Valid Namespace Connection
Figure 9 Valid Namespace Connection
If the query is valid, then the dialog box in Figure 11 will be displayed. This dialog box is waiting for the defined event to occur and will display the results when it does. The WQL used in the example will fire each time a new process is created in Windows. You can test this by simply starting Notepad (assuming you used the query in Figure 7). The entry in the dialog box indicates that the event was fired as expected. If you double-click on the event, detailed information about it will appear (see Figure 12). There you’ll see the properties of the event.
Figure 10a Notification Query Error
Figure 10a Notification Query Error
Figure 10b Notification Query Error
Figure 10b Notification Query Error
The most interesting information is contained in the TargetInstance property, which is an object representing the instance of the WMI class that you are monitoring (in the example, this is the process that was just created). You can view the details of the target object by selecting TargetObject in the property list, selecting Edit Property, and then clicking the View Embedded button (see Figure 13).
Figure 11 Query Result Dialog Box
Figure 11 Query Result Dialog Box
Figure 12 Event Details in WBEM Test
Figure 12 Event Details in WBEM Test
If you find a result in the Query Result window after simulating the event you want to monitor, then your WQL has detected the intended event and is therefore valid. You may also find the detailed properties of the related instance to be useful, though, in further refining the criteria of the WQL since this will show the available properties and their values (see Figure 13).
Figure 13 TargetInstance Object Properties
Figure 13 TargetInstance Object Properties

Providers and Event Rules
A provider is a source of information collected by MOM. All MOM event rules require a provider. The event rule collects information from the provider and applies its own criteria to determine if this information should be collected, generate an alert, or execute any of a number of responses. As the name would imply, a WMI event provider monitors for WMI events.
A WMI event provider requires the following information:
Namespace, the namespace in which the WMI class being queried exists.
Query, the WMI notification query. This is identical to the WQL that was created in the previous section.
Property List, which specifies the properties of the event class that are returned. It is typically left blank so that all properties are returned.
Figure 14 shows a sample WMI event provider. The query in this provider is identical to the one in the previous testing example and, in fact, was entered with a copy/paste to ensure there were no typos. The property list was purposely left blank to simply return all properties of the WMI event.
Figure 14 Sample WMI Event Provider
Figure 14 Sample WMI Event Provider

Event Processing
Once the WMI provider has been created, an event rule is required based on the provider. If the provider is already specific enough (firing when the specific process is started, for example), then the event rule needs no criteria. It only needs to be configured to generate an alert or execute a response.
For example, suppose you want an alert to be generated when a process called notepad.exe is started. The following notification query could be used in the provider with no criteria on the event rule:
SELECT * FROM __InstanceCreationEvent
WITHIN 60
WHERE TargetInstance ISA ‘Win32_Process’
AND TargetInstance.Name = ‘notepad.exe’
In this case, the event will only fire if a process called notepad.exe is started. The event rule does not need to provide additional criteria.
An alternate strategy would be to remove the specific criterion in the provider and use the following query:
SELECT * FROM __InstanceCreationEvent
WITHIN 60
WHERE TargetInstance ISA ‘Win32_Process’
In this case, the event rule would generate an alert each time any process was started, regardless of its name. If you want to receive an alert only when notepad.exe is started, then the event would need to provide additional criteria, as I’ll explain.
Intrinsic Events For intrinsic events, the parameters of the generated MOM event contain information from the WMI event itself as opposed to the properties of the target instance, which is the information you would typically want. Unfortunately, WMI events in MOM lump the useful information into a single parameter, the text of which can be searched for the info you need. The entire set of properties of TargetInstance are contained in a long string in a single parameter for all events. For a modification event, an additional parameter holds the properties for PreviousInstance, which represents the instance prior to modification. Figure 15 lists the MOM event parameters that contain these sets of properties. These are the parameters that may be specified in the event criteria.
For example, to filter the generic provider from the query you just saw, the following criteria could be used: "Parameter 12 contains substring ‘notepad.exe’".
This is a simple, typical example. More complex criteria may be specified using regular expressions. For example, to determine if either Notepad or Calculator has been started, the following criteria could be used: "Parameter 12 matches regular expression ‘notepad.exe|calc.exe’".
Extrinsic Events The properties for extrinsic events are placed into the event parameters in order of their occurrence. This order will vary for each resource, so you may need to collect some sample events to determine which parameter contains each property. For example, the RegistryValueChangeEvent provides the following properties: Hive (parameter 11), Key Path (parameter 12), and Value Name (parameter 15).
The use of criteria for extrinsic events will vary depending on the provider. In the case of the registry, event criteria typically are not useful since the RegistryValueChangeEvent requires the Hive, Key Path, and Value Name to be specified in the query anyway. Other extrinsic events may allow more general queries.
Specific Provider Versus Generic Provider There are two basic strategies in determining whether to use a specific provider (with no criteria on the event rule) or a generic provider (with criteria on the event rule). Both will provide the same result, but each has distinct advantages and disadvantages.
If you use a generic provider, multiple events can share a single provider. For example, the provider may specify the creation of any process. Events attached to that provider would specify in their criteria which process they were looking for. This results in fewer providers. The drawback, however, is in greater overhead. The provider will register in WMI to receive events for every process that is started. Each time an event is received, MOM must do a text search on the description to determine if an event criteria has been matched.
If you use a specific provider, then more providers must be created. The overhead, however, is minimal since you will only receive the specific events from WMI you are interested in. The typical strategy is to use specific providers because of the minimal overhead. It is rare that complex criteria are required to the point that a large number of providers end up being used. This is not a hard and fast rule, however, and in those cases where a more general provider makes sense you should use one.
Generating an Alert The default description for an alert generated from an event rule is $Description$. This replicates the description from the event that generated the alert. In the case of a WMI event, this is not recommended, since the description will include the text from each event parameter. While useful information, it is not entirely presentable, as is shown in Figure 16.
Figure 16 Default WMI Event Description (Close Figure 16)
Description:
__CLASS=__InstanceCreationEvent
__DERIVATION=__InstanceOperationEvent,__Event,__IndicationRelated,__SystemClass
__DYNASTY=__SystemClass
__GENUS=2 (0x2)
__NAMESPACE=//./root/CIMV2
__PATH=<null>
__PROPERTY_COUNT=3 (0x3)
__RELPATH=<null>
__SERVER=MOM05
__SUPERCLASS=__InstanceOperationEvent
SECURITY_DESCRIPTOR=<null>
TargetInstance={
instance of Win32_Process
{
Caption = "notepad.exe";
CommandLine = "\"C:\\WINDOWS\\system32\\notepad.exe\" ";
CreationClassName = "Win32_Process";
CreationDate = "20050112170509.053027-480";
CSCreationClassName = "Win32_ComputerSystem";
CSName = "MOM01";
Description = "notepad.exe";
ExecutablePath = "C:\\WINDOWS\\system32\\notepad.exe";
Handle = "372";
HandleCount = 17;
KernelModeTime = "100144";
MaximumWorkingSetSize = 1413120;
MinimumWorkingSetSize = 204800;
Name = "notepad.exe";
OSCreationClassName = "Win32_OperatingSystem";
OSName = "Microsoft Windows Server 2003 Standard Edition|C:\\WINDOWS|\\Device\\Harddisk0\\Partition1";
OtherOperationCount = "31";
OtherTransferCount = "2147344384";
PageFaults = 456;
PageFileUsage = 585728;
ParentProcessId = 3832;
PeakPageFileUsage = 585728;
PeakVirtualSize = "30822400";
PeakWorkingSetSize = 1826816;
Priority = 8;
PrivatePageCount = "585728";
ProcessId = 372;
QuotaNonPagedPoolUsage = 1640;
QuotaPagedPoolUsage = 25856;
QuotaPeakNonPagedPoolUsage = 1640;
QuotaPeakPagedPoolUsage = 33256;
ReadOperationCount = "0";
ReadTransferCount = "0";
SessionId = 1;
ThreadCount = 1;
UserModeTime = "0";
VirtualSize = "23449600";
WindowsVersion = "5.2.3790";
WorkingSetSize = "1826816";
WriteOperationCount = "0";
WriteTransferCount = "0";
};
}
TIME_CREATED=127500519325625901
A specific description is typically used in order to provide plain English to the operator receiving the alert. For example, rather then use $Description$ for the event in Figure 16, a more appropriate description for the alert would be "An instance of notepad.exe was started."
Launching a Script In addition to generating an alert, a common response to a rule based on a WMI event provider is launching a script. (An introduction to writing scripts in MOM can be found at "Scripting for MOM".) If a script is launched in this manner, it may well need access to the properties of the WMI instance that initiated the event. These properties are available in the event parameters, as noted earlier, but they are lumped together in a single string. It may require a significant number of string searches for the script to access individual properties of the instance.
The VBScript function in Figure 17 may be used in a MOM script to parse the text returned from a WMI event query. This will return a Dictionary object with the properties of the instance that may be used almost as if it were an object of that class. (Documentation on the Dictionary object may be found at "Dictionary Object".) The function works by performing string searches against the known format of the event parameter. It plucks out the individual properties and places them into items of the Dictionary object. This function may be called by passing the appropriate event parameter, depending on the instance desired. Here’s an example using the process creation:
Set objEvent = ScriptContext.Event
Set objWMIObject = _
    GetWMIObject(objEvent.EventParameter(12))

WScript.Echo "Name: " & _
    objWMIObject.Item("Name")
WScript.Echo "Process ID: " & _    objWMIObject.Item("ProcessId")
WScript.Echo "Executable path: " & _
    objWMIObject.Item("ExecutablePath")
Figure 17 VBScript Function to Extract WMI Object Properties (Close Figure 17)
    Function GetWMIObject(strEventWMIString)

    Set GetWMIObject = CreateObject("Scripting.Dictionary")
    intClassRef = InStr(strEventWMIString,"instance of ") + 12
        strClass = Mid(strEventWMIString,intClassRef, _
        InStr(intClassRef,strEventWMIString,Chr(10))-intClassRef)
    GetWMIObject.Add "__CLASS",strClass

    intAttributeStart = InStr(intClassRef,strEventWMIString,"{" & _
        Chr(10) & Chr(9)) + Len("{" & Chr(10) & Chr(9))
    strAttributeString = Mid(strEventWMIString,intAttributeStart, _
        InStr(intAttributeStart,strEventWMIString, _
        Chr(10) &  "};" & Chr(10)) - _
        intAttributeStart - 1)

    arrAttributes = Split(strAttributeString, ";" & Chr(10) & Chr(9))

    For i = 0 To UBound(arrAttributes)
        intSplitRef = InStr(arrAttributes(i),"=")
        strAttributeName = Trim(Left(arrAttributes(i),intSplitRef-1))
        strAttributeValue = Trim(Right(arrAttributes(i), _
            Len(arrAttributes(i))-intSplitRef))
        If Left(strAttributeValue,1) = """" Then
            strAttributeValue = Mid(strAttributeValue,2, _
                 Len(strAttributeValue)-2)
        End If
        GetWMIObject.Add strAttributeName,strAttributeValue
    Next

End Function

MOM Classes
Similar to the WMI classes provided by Windows, MOM provides WMI classes for accessing its objects—including alerts, events, and computers. These are primarily intended for access to MOM from outside processes (a custom connector, for example), but they can be used to detect actions in MOM otherwise not possible by using a WMI event provider referencing an intrinsic event for one of these classes. (Full documentation on the MOM WMI classes is provided in the MOM SDK.)
MOM WMI classes are stored in the root\MOM namespace and are only available on management servers. Because of this, any rule based on a WMI provider using a MOM class must be deployed to a computer group such as Microsoft® Operations Manager 2005 Servers. If it is deployed to an agent, it will fail since the root\MOM namespace will not exist.
For most operations, notifications with the MOM WMI classes are not useful from within MOM, since MOM provides more effective methods to detect these actions. For example, while you could create a WMI provider looking for an __InstanceCreationEvent of an instance of MSFT_Event (the name of the class for MOM events), it is much easier to simply create an event rule which is designed to detect this action.
Events based on MOM WMI classes can be useful, though, in detecting actions that MOM does not normally detect. The most obvious example is a change to an alert (represented by the class MSFT_Alert). An alert rule in MOM detects the creation of an alert, but there is no obvious means of detecting a change to an alert property, such as a change to the owner or to the resolution state. This action can be detected with the following query:
SELECT * FROM __InstanceModificationEvent
WITHIN 60 WHERE TargetInstance ISA ‘MSFT_Alert’
This query will detect any change to any alert. In order to determine which property changed, a comparison between the TargetInstance and PreviousInstance needs to be included. The following example detects a change in the Resolution State:
SELECT * FROM __InstanceModificationEvent
WITHIN 60
WHERE TargetInstance ISA ‘MSFT_Alert’
and TargetInstance.ResolutionState <>
PreviousInstance.ResolutionState
Here’s a query to detect change to the owner MOM alert:
SELECT * FROM __InstanceModificationEvent
WITHIN 60
WHERE TargetInstance ISA ‘MSFT_Alert’
and TargetInstance.Owner <> PreviousInstance.Owner

Conclusion
Now that you have seen how you can use WMI and MOM to capture system events that you were unable to monitor before, you will undoubtedly find many uses for the concept, including watching events whose status had never interested you before. If you would like to see some more real-world examples with the code to match, take a look at the sidebar "Monitoring Events: Real Examples." Don’t forget to check out other resources indicated throughout this article, and download the MOM SDK. Plus, for more on how WMI itself works, see "Windows Management Instrumentation", "WMI Scripting Primer", and the book Microsoft Windows Scripting with WMI: Self-Paced Learning Guide by Ed Wilson (Microsoft Press®, 2005).
Monitoring Events: Real Examples
The following are some examples of various WMI events that may be monitored. For each example, you’ll see the details for the provider and the event rule(s) to generate an alert.
Process Ending This example generates an alert when a particular process on a computer stops. The process name in this example is "coreapp.exe". This may be a critical process for a particular application that is not a Windows service. Here for the provider namespace of root\cimv2 the provider-specific query is the following and there are no event rule criteria:
SELECT * FROM __InstanceDeletionEvent
WITHIN 30
WHERE TargetInstance ISA ‘win32_process’
AND TargetInstance.Name = ‘coreapp.exe’
Here is the query for a general provider:
SELECT * FROM __InstanceDeletionEvent
WITHIN 30 WHERE TargetInstance ISA ‘win32_process’
And the event rule criterion is: Parameter 12 contains substring ‘coreapp.exe’.

Stopping a Service This example generates an alert when a service stops by monitoring for a modification in an instance of the service class. You must check if the name of the service is the one you are interested in, if its current state is not running, and if its previous state was running. If the check on previous state is not performed, then we could be firing the alert for a simple modification to the service’s configuration as opposed to a change in its running state. The service used in this example is the IIS Web service. Here is the provider query for a specific provider when there are no event rule criteria:
SELECT * From __InstanceModificationEvent
WITHIN 30 WHERE TargetInstance ISA ‘Win32_Service’
AND TargetInstance.Name = ‘w3svc’
AND PreviousInstance.State = ‘running’
AND TargetInstance.State <> ‘running’
For a partially specific provider under these same circumstances, the provider query and the event rule criteria are as follows:
SELECT * From __InstanceModificationEvent
WITHIN 30 WHERE TargetInstance ISA ‘Win32_Service’
AND TargetInstance.Name = ‘w3svc’
And Parameter 11 contains substring ‘Running’. Parameter 13 doesn’t contain substring ‘Running’.

Creating a File This example monitors for the creation of a specific file. This may be an error log generated by an application. The creation of the file indicates that an error has occurred in the application. The name of the file in this example is c:\appdir\errorlog.txt. Note that there is no example of a generic provider since this is not recommended for a class as large and volatile as CIM_DataFile.
Here the provider query is the following and there are no event rule criteria:
SELECT * FROM __InstanceCreationEvent
WITHIN 30 WHERE TargetInstance ISA ‘CIM_DataFile’
AND TargetInstance.Name = ‘c:\\appdir\\errorlog.txt’
Note the use of double backslashes (\\) in place of the backslash (\) character in the path.

File Modification This example is similar to the previous one but instead of the file being created, it monitors for the file being modified. There are no event rule criteria and the provider query is:
SELECT * FROM __InstanceModificationEvent
WITHIN 30 WHERE TargetInstance ISA ‘CIM_DataFile’
AND TargetInstance.Name = ‘c:\\appdir\\errorlog.txt’

The Creation of a File within a Directory This example is similar to the previous one, but instead of looking for a specific file, the query monitors for any file created within a certain directory:
SELECT * FROM __InstanceCreationEvent
WITHIN 30 WHERE TargetInstance ISA ‘CIM_DataFile’
AND TargetInstance.Path = ‘\\appdir\\’ and
TargetInstance.Drive = ‘C:’

Modification of a Registry Key This example monitors for a change to a particular registry key. The sample key for this example is HKLM\Software\Company\Application\AdminLevel. Note that there is no example of a general provider since the RegistryValueChangeEvent requires the Hive, KeyPath, and ValueName to be specified in the query:
SELECT * FROM RegistryValueChangeEvent
WHERE Hive=‘HKEY_LOCAL_MACHINE’
AND KeyPath=‘Software\\Company\\Application’
AND ValueName = ‘AdminLevel’

Modification of Alert Resolution State The example monitors for the change in the resolution state of a MOM alert:
SELECT * FROM __InstanceModificationEvent
WHERE TargetInstance.ResolutionState <>
PreviousInstance.ResolutionState

Modification of Alert Owner This example monitors for the change to the owner of a MOM alert. Additional criteria are specified to exclude alerts that have already been resolved:
SELECT * FROM __InstanceModificationEvent
WHERE TargetInstance.Owner <> PreviousInstance.Owner
AND PreviousInstance.ResolutionState <> 255

Brian Wren is a Principal Consultant with Microsoft Consulting Services in Southern California. In addition to architecting and deploying a variety of solutions for customers, he writes and speaks regularly on management technologies. He can be reached at bwren@microsoft.com.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 System Management: Zero Touch Installation: Automating Operating Systems Migrations
System Management Jason Cross

Zero Touch Installation: Automating Operating Systems Migrations
At a Glance:
  • Three types of deployment scenarios
  • Key components needed for automated deployment
  • A walk through the three main scenarios

Historically, desktop OS migration has been a very labor intensive project. The number of obstacles and questions to consider can be intimidating. Will all the targeted machines support the new
operating system? Will your organization's applications work after migration? How will the data on systems be preserved? How do you save money if specialists have to visit every computer? How do you prepare for and minimize the barrage of help desk calls that will ensue? And once deployed, how will you manage the new operating system?
During the typical roll-out, a herd of IT staffers descend upon a workgroup of computers during off hours and do the heavy lifting. They manually save user data to a file share (or even take an entire snapshot of the PC), pull down the master image, configure the system (manually join the domain, let policies flow down, reinstall applications, and so on), manually restore user data, and then pray that the desktop is functioning properly and hope that the user won't be too upset when he discovers his previous settings have been lost. It's not a pretty process.
But I did start this article by saying "historically." These deployment blockers and resource intensive processes have been addressed, and now you can automate the work with the Systems Management Server (SMS) 2003 Operating System Deployment (OSD) Feature Pack and the Solution Accelerator for Business Desktop Deployment (BDD). The OSD adds support for operating system deployment to SMS, offering a similar paradigm for deploying OS images as used to deploy applications. If you are accustomed to creating software packages with SMS, you'll find image packages are just as easy since you use the same SMS administrator console (see Figure 1).
Figure 1 Using SMS to Create an OS Image Package
Figure 1 Using SMS to Create an OS Image Package
BDD provides end-to-end guidance on desktop deployments for moving to Windows® XP and Microsoft® Office 2003. It's very comprehensive, offering more than two dozen documents covering the key topics of desktop deployment from soup to nuts. Included in BDD are the Zero Touch Installation (ZTI) files that are used to augment the capabilities of the SMS OSD for the following scenarios.
Bare-Metal This involves a new, fresh installation. In this case, a new image is deployed to a computer that does not have any operating system installed on disk. A variation on this theme is when an operating system is already installed on the computer, but you are performing a fresh install and do not need to save and restore any data or settings.
Replacement In this scenario, a user is moving from a legacy computer to a new system. This means the user's data and settings must be moved to the new computer and operating system.
Refresh In this situation the user retains the same hardware, but is migrating over to a new operating system. Once again, the user's data and settings must be moved to the new operating system.
The remainder of this article focuses on these scenarios and how ZTI can greatly reduce the time and resources needed to migrate a desktop.

What You Need
If you plan on using ZTI, there are some prerequisites. The primary products, technologies, and components you'll need are: SMS OSD Feature Pack, BDD Enterprise Edition, Remote Installation Services (RIS), and User State Migration Toolkit (USMT). Let's take a closer look at each of these, exploring how they are used in ZTI deployments. For details on where you can get these tools, see the sidebar "Get the Core Components."
The SMS OSD Feature Pack is a publicly available download that you install (very quickly) on your SMS primary site server. The OSD includes a version of the Windows Preinstallation Environment (Windows PE) and features for capturing your master image. Out of the box, the OSD supports bare-metal and refresh scenarios. For a bare-metal build, a CD is used to boot the targeted machine. This is called the Operating System Installation CD and is created using the SMS Administrator Console. When you use ZTI, however, the functionality of this CD is replaced by RIS, which I will cover in a moment.
BDD Enterprise Edition is also a publicly available download. It includes all the documentation and scripts needed to implement ZTI, as well as complete coverage of desktop deployment guidance for Office Professional 2003 and Windows XP Professional (including the Windows XP Professional x64 and Windows XP Tablet PC editions). The Enterprise Edition of BDD is geared for organizations with 500 or more PCs. But if you have the necessary infrastructure in place, BDD Enterprise Edition can assist any size company.
Remote Installation Services ships with Windows Server® 2003, and has been greatly enhanced since Windows 2000. In particular, it delivers better performance and lets you automatically bypass configuration screens during OS deployment. This is a key feature essential for ZTI. RIS provides PXE (Pre-Boot Execution Environment) capabilities and is used to stream Windows PE over the network.
Finally, the User State Migration Toolkit (USMT) is a publicly available download that you can use for migrating user data and settings. The latest release has been significantly upgraded—it now supports migration of multiple profiles at once and can run unattended (meaning the user does not need to be logged on). USMT is governed by .inf files so you can explicitly control what is saved. For example, you can ignore a user's vast library of MP3 files, reducing the amount of time and storage space used during the migration process.

Putting the Pieces Together
To implement ZTI, you'll need a stable infrastructure that contains Active Directory®, DNS, DHCP, and SMS 2003 (with SP1 or higher). The basic components for this solution are highlighted in the "How IT Works" section of this article, though your environment may have a different mix of servers and services.
There are two excellent guides that provide information and step-by-step instructions on how to configure the OSD and set up ZTI: the Users Guide that is included as part of the OSD download and the Zero Touch Installation Deployment Feature Team Guide that is part of the BDD Enterprise Edition download. Here's a quick overview of the key steps involved in setting up a ZTI solution.
First you need to install the OSD on your SMS primary site server. Once this is installed, you can use the SMS Administrator Console to create an Operating System Image Capture CD and an Operating System Image Installation CD. The Image Capture CD is used to capture your master image into a single file. This file conforms to the Windows Imaging Format (WIM), which is the new Microsoft file-based imaging technology that was introduced with the OSD. WIM offers modern capabilities, such as enhanced compression that allows for smaller image sizes and the ability to retain user data and settings on the local disk during the image process (this saves space on your file servers). The Image Installation CD enables the installation of the image package and is used to configure the RIS server for ZTI.
Then you can create a master image. This is the baseline image that will be distributed to all the computers receiving the OS deployment. To do this, you should use a fresh reference computer that has Windows XP SP2 and all the related updates installed. You may want to include other core enterprise applications, such as virus protection and the Microsoft Office System, on the reference computer as well. (For more information on setting a ZTI baseline, see "Design More Secure Desktop Deployments" in the March/April 2006 issue of TechNet Magazine.) The computer should be part of a workgroup, but not joined to an Active Directory domain.
Install the SMS Advanced Client on the reference computer. You must run ccmdelcert.exe—a utility in the SMS Toolkit—after you install the SMS Advanced Client. The sysprep directory and related files must be on the system drive, as well. For more instruction on creating your master image, review the documentation and check out the Computer Imaging System (CIS) utility in the BDD. CIS will help you quickly generate a master image that can be used with the OSD and ZTI.
Once the image has been created, you use the OSD Image Capture CD to grab the master image and save it to a file server. This process is as easy as placing the CD in the player and following the prompts. Then using the SMS Administrator Console, create an image package and program. You then update the custom actions of the image program to run the ZTI script, ZeroTouchInstallation.vbs, as seen in Figure 2, and update accordingly for the State Capture, Preinstall, Postinstall, and State Restore phases.
Figure 2 Update Custom Actions of the Image Program
Figure 2 Update Custom Actions of the Image Program
Now create a standard SMS software package and include the files from USMT and ZTI. This package will be used to capture the user state in the Replacement Scenario. The ZeroTouchInstallation.vbs script is used to drive the state capture in the Replacement Scenario so you will need to use the following command line for the package, which is shown in Figure 3:
wscript //b ZeroTouchInstallation.vbs /phase:OldComputer.
On a machine running SQL Server™, create the ZTI Administration Database (AdminDB) with the supplied SQL scripts. If at all possible, create this on the SMS primary server so you can take advantage of the existing instance of SQL Server. The ZTI AdminDB is not large in regard to the number of tables and the amount of data it stores.
Figure 3 Specifying the ZTI Script
Figure 3 Specifying the ZTI Script
The ZTI AdminDB is queried by ZeroTouchInstallation.vbs to retrieve configuration information about the computers that are going to be migrated. Therefore, the database needs to be populated with information about the systems being updated—information like the time zone, Active Directory domain to join, Active Directory Organizational Unit to be used to create the computer account, MAC address of the target desktop, and so on.
RIS must be installed and configured. Keep in mind you'll need two partitions on the server since the RIS files need to be stored on a different partition than the operating system. You use the SMS Operating System Installation CD to create the RIS boot image. This CD includes the necessary files to stream Windows PE over the network. Then you create a ZTI share. This, for example, can be a file share on the SMS server. This share is where all the related files for ZTI (ZeroTouchInstallation.vbs, CustomSettings.ini, and USMT) are stored.
This is just a general guide to the essential steps in setting up and preparing for a ZTI deployment. For the most part, you will follow these steps, though the order can vary somewhat depending on your scenario.

Advanced Features
Beyond these basic features offered by BDD and the SMS OSD, there is additional functionality that may be useful in your environment. (These advanced features are further described in the Zero Touch Installation Deployment Feature Team Guide.) You can create a custom version of Windows PE so that it uses WMI during the migration process. By using WMI you can determine the make and model of the machine from the local computer BIOS. The ZeroTouchInstallation.vbs script does this automatically. With this information, you can further refine which SMS image package and program to use as well as define any pertinent drivers you need for a particular model. This avoids having to include all drivers for all your computer models in the golden image, thus saving valuable space. Application reinstallation is a key part of any migration. Most often the golden image will not contain all applications needed by everyone, therefore targeting these workgroup needs is very important. BDD can assist by defining a computer to a certain role which in turn can determine the applications to install. This information can be stored in the CustomSettings.ini file or the ZTI AdminDB. By using this functionality, for example, the Accounting Group can receive the applications it needs, but not those needed by the Sales Group.
Get the Core Components
  • SMS OSD Feature Pack
  • BDD Enterprise Edition
  • Remote Installation Services (RIS) is included with Windows Server 2003
  • Use State Migration Toolkit (USMT)

Jason Cross is a Senior Consultant with Microsoft. He has been involved in Zero Touch Technologies from their inception.


 System Management: Gathering WMI Data without Writing a Single Line of Code
System Management John Kelbley

Gathering WMI Data without Writing a Single Line of Code
At a Glance:
  • Data available to WMI
  • Simple command-line data collection in WMIC
  • Formatting the output
Download the code for this article: WMIC2006_09.exe (151KB)

Can a command be your best friend? Maybe not, but it can make the job of administering Windows a whole lot easier. Writing scripts to take advantage of the power of Windows Management Instrumentation (WMI)
can be intimidating, but leveraging the relatively unknown command-line interface of WMI, called WMIC, makes it easier. What is WMIC, and why do I like it so much? Read on.
WMI is the Microsoft implementation of an industry-wide initiative called Web-Based Enterprise Management (WBEM), which defines standards for accessing and managing systems in an enterprise environment. WMI gives you control over many components of your systems, from the hardware all the way up to installed applications. You can use it to access event logs, operating system attributes, processes, installed applications, and much more. When you want to know the MAC address of a network card, the size of installed DIMMs, a list of running processes, user account information, installed operating system patches, and so forth, you can retrieve them via WMI. But getting all that information is not straightforward.

Easier Access
Before WMIC, the power of WMI was typically accessed via programs or custom scripts. For example, let's say you wanted to find out the type of CPU inside your system. In the past, you might have written a short VBScript script that uses WMI to query the name of the CPU on the local system:
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Processor",,48)
For Each CPU in colItems
    Wscript.Echo "Name  " & CPU.Name
Next
Then you'd execute the script using a command line like so:
cscript /NOLOGO cpuname.vbs
And the output of the script would look something like this:
Name    Intel(R) Pentium(R) M processor 2.00GHz
That's a lot of heavy lifting to get the name of the CPU!
Look how easy it is to retrieve the same information using WMIC. Just type the following at a regular command prompt:
WMIC CPU GET NAME
Here's the output:
Name
Intel(R) Pentium(R) M processor 2.00GHz
As you can see, using WMIC vastly simplifies accessing information via WMI. WMIC lets you modify your system configuration as well. You can start or stop processes and change various configuration options—all from one command. And you can save the all the information in useful CSV or HTML files.

Using WMIC
Now that I've whetted your appetite, open a command window and type WMIC. The first time you do this, WMIC installs itself and drops you at a command prompt within the WMIC shell; your prompt changes to wmic:root\cli>. Start by typing /? to get a helpful listing of what you can do within WMIC. The help output (some of which is shown in Figure 1) is organized into two key sections: global switches and aliases. Try it on your own to see the full output.
Figure 1 Output of WMIC /? Excerpt (Close Figure 1)
[global switches] <command>

The following global switches are available:
/NAMESPACE           Path for the namespace the alias operate against.
/ROLE                Path for the role containing the alias definitions.
/NODE                Servers the alias will operate against.
/IMPLEVEL            Client impersonation level.
/AUTHLEVEL           Client authentication level.
/LOCALE              Language id the client should use.
/PRIVILEGES          Enable or disable all privileges.
/TRACE               Outputs debugging information to stderr.
/RECORD              Logs all input commands and output.

...

/?[:<BRIEF|FULL>]    Usage information.

For more information on a specific global switch, type: switch-name /?

The following alias/es are available in the current role:
ALIAS                    - Access to the aliases available on the local system
BASEBOARD                - Base board (also known as a motherboard or system
                         - board) management.
BIOS                     - Basic input/output services (BIOS) management.
BOOTCONFIG               - Boot configuration management.
CDROM                    - CD-ROM management.
COMPUTERSYSTEM           - Computer system management.
CPU                      - CPU management.
CSPRODUCT                - Computer system product information from SMBIOS.
DATAFILE                 - DataFile Management.
DCOMAPP                  - DCOM Application management.
DESKTOP                  - User’s Desktop management.
DESKTOPMONITOR           - Desktop Monitor management.
DEVICEMEMORYADDRESS      - Device memory addresses management.

...

For more information on a specific alias, type: alias /?

CLASS     - Escapes to full WMI schema.
PATH      - Escapes to full WMI object paths.
CONTEXT   - Displays the state of all the global switches.
QUIT/EXIT - Exits the program.

For more information on CLASS/PATH/CONTEXT, type: (CLASS | PATH | CONTEXT) /?
Global Switches are universal modifiers to the WMIC command line you'd like to execute, and aliases are references to the actual WMI data you'd like to manipulate.
When you try it on your machine, look through the alias section—it's packed with commands to get all sorts of great information. Perhaps you'd like to know which processes are running and the amount of memory they are using. That's simple enough—at the WMIC prompt, type:
process
This gives you a dump of all the active processes on the system in a predefined, default layout (the same as if you had typed "process get" at the WMIC prompt). Notice all the information you receive for each process, organized in nice labeled columns. Scroll all the way to the right to make sure you don't miss anything. Of course, all this data may be more than you want. Once you know the columns you're interested in, you can select only those by using the get verb with names of the attributes. Perhaps all you want is the process name and the memory it is using. If you type the following, you'll get the output you see in Figure 2:
process get name, workingsetsize
Figure 2 Processes and the Memory They Use
Figure 2 Processes and the Memory They Use

Getting Data from Remote Systems
WMIC lets you access systems remotely as well as locally, which makes it extra useful for the busy administrator. To get the process listing from a remote system, simply add the /NODE: global switch followed by the remote computer name:
/node:"server1"
process get name, workingsetsize
You can provide the names of multiple computers in a command line at the same time if you like:
/node:"server1","server2"
process get name, workingsetsize
In a multi-node query like this, it makes good sense to ask for the computer name as well, otherwise you might not know which system the process is running on. Here's how:
/node:"server1","server2"
process get CSName, name, workingsetsize
The /NODE global switch can also accept the name of a text file containing a list of host names you'd like to access via your WMIC command line. Simply create the file and include system names or IP addresses, one system per line, and WMIC will process each entry. Here's the command to access a file called serverlist.txt:
/node:@serverlist.txt process get CSName, name, workingsetsize
When processing WMIC commands against multiple systems, it's a good idea to use the /FAILFAST:on global switch, which tells WMIC not to wait around for an unresponsive host. Here is an example of how you could use the /FAILFAST switch to check the OS version on several systems:
/failfast:on /Node:johnkelnc6000, "
johnkel-fer" os get Caption, CSDVersion, CSName

Output Formats
The default text output of WMIC is useful, but it's not exactly easy to read. WMIC supports a variety of output formats, including HTML, CSV, MOF, and XML. The two I use most often are CSV and HTML. CSV is perfect for manipulating data using Microsoft® Excel® or for importing into a database tool such as Access or SQL Server™. To generate a CSV formatted file, you simply use the /OUTPUT global switch, specify a file, and select the appropriate format:
/output:c:\os.csv os get /all /format:csv
This generates output values separated by commas and written to the file c:\os.csv.
Note that WMIC doesn't add the double quotes that Excel uses to parse a typical CSV file, so you will likely have to open the file from within Excel and select the appropriate delimiter to properly parse the data (see Figure 3).
Figure 3 Data in Excel
Figure 3 Data in Excel
Figure 4 HTML Output in Tabular Form
Figure 4 HTML Output in Tabular Form
WMIC does a nicer job with HTML output and provides multiple ways to organize the output (see Figure 4). First let's output the same operating system data into a tabular format similar to the CSV file:
/output:c:\os1.html os get /all /format:htable.xsl
The output is the same as that in the CSV file, but formatted as HTML. This is useful when listing and evaluating multiple lines of similar data—perhaps for comparing operating system information for multiple systems. Here is the code that does that. Figure 5 shows the output:
/output:c:\os_list.html /Node:johnkelnc6000,
"johnkel-fer", "johnkel-lhsrv"
os get Caption, CSDVersion /format:htable.xsl
You can see how useful this tabular HTML format might be for retrieving and comparing information from multiple systems, processes, or volumes. Not all data is best displayed in tabular format, though. You may not want to scroll endlessly to the right to see data from queries with long lists of returned attributes. Instead, you can return data in a vertical format. For example, Figure 6 shows the output from the following query:
/output:c:\os2.html os get /all /format:hform.xsl
Figure 5 Side-By-Side Comparison in HTML
Figure 5 Side-By-Side Comparison in HTML
Figure 6 Data in a Vertical Presentation
Figure 6 Data in a Vertical Presentation
Maybe you'd like to create a series of HTML reports that could be accessible at any time, showing the status of key servers. Perhaps you're not a coder or an HTML expert, but do write the occasional batch file. Figure 7 shows an example batch file I wrote to create an HTML index page of other HTML files generated using WMIC.
Figure 7 DoltAll.bat (Close Figure 7)
@Echo off
rem
rem
rem    The next few lines of echoes are to create the HTML to setup the page -
rem    I’ve added a bunch of carets to allow the required greater than and less than symbols to echo properly
rem    These echoes can be eliminated if you put all the required "header" HTML into a file and redirect it
rem    into the front of the target HTML file with a copy or type command - makes the batch file easier to read
rem
echo    ^<HTML^>^<HEAD^>^<TITLE^>TechNet WMIC Monitoring Page Example^</TITLE^>^</HEAD^> >> list.html
echo    ^<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"^> >> list.html
echo    ^<h1 align="center"^>^<b^>^<font face="Arial" size="+4" color="Red"^>TechNet WMIC Monitoring Page Example^</font^>^</b^>^</h1^> >> list.html
echo    ^<p align="center"^>^<table border="1" width="600"^> >> list.html
rem
rem    Table headers on the page are defined here, should you want to add more...
rem
echo    ^<tr^>^<td^>^<B^>Server Name^</td^> >> list.html
echo    ^<td^>^<B^>OS Info^</td^> >> list.html
echo    ^<td^>^<B^>Patches^</td^> >> list.html
echo    ^<td^>^<B^>Drive Volume Info^</td^>^</B^>^</tr^>^</p^> >> list.html
rem
rem
rem    The loop below does all the heavy lifting
rem
for /F %%i in (serverlist.txt) do (
    echo Processing %%i...
    wmic /Failfast:on /node:"%%i" /output:"%%i_OS.html" OS Get /All /format:hform.xsl
    wmic /Failfast:on /node:"%%i" /output:"%%i_qfe.html" QFE where "Description<>’’" Get /All /format:htable.xsl
    wmic /Failfast:on /node:"%%i" /output:"%%i_drives.html" logicaldisk get caption, description, filesystem, size, freespace,
         compressed /format:htable.xsl
    echo ^<tr^>^<td^>%%i^</td^> >> list.html
    echo     ^<td^>^<a href="http://%%i_OS.html"^>OS Info^</a^>^</td^> >> list.html
    echo     ^<td^>^<a href="http://%%i_QFE.html"^>Patches^</a^>^</td^> >> list.html
    echo     ^<td^>^<a href="http://%%i_drives.html"^>Drive Volumes^</a^>^</td^> >> list.html
    echo ^</tr^> >> list.html
)

    echo ^<p align="center"^>^<b^>^<font size="+1" color="Red"^>
         ^<BR^>Completed at >> list.html
time /T >> list.html
echo - on >> list.html
date /T >> list.html
echo ^</font^>^</b^>^<BR^>^</p^> >> list.html
Echo .
Echo DONE!!!
The batch file only looks complicated, because it contains all sorts of HTML tags that are used to create the properly formatted HTML index file (list.html). The core loop in the batch file is the key—here it is without any of the HTML mumbo jumbo or WMIC output switches:
for /F %%i in (serverlist.txt) do (
    echo Processing %%i...
    wmic /Failfast:on /node:"%%i"
    /output:"%%i_OS.html" OS Get /All
    wmic /Failfast:on /node:"%%i"
    /output:"%%i_qfe.html" QFE where
        "Description<>''" Get /All
    wmic /Failfast:on /node:"%%i"
    /output:"%%i_drives.html" logicaldisk
        get caption, description, filesystem,
        size, freespace, compressed
)
The loop simply reads though a text file (serverlist.txt) containing a list of system names (one per line) and calls WMIC to create uniquely named output files. The HTML output of the batch file looked like Figure 8. (Note that the batch file is available from the Code Downloads section of the TechNet Magazine Web site.
Figure 8 Output from Several Servers
Figure 8 Output from Several Servers

Controlling Processes
Now you've seen how useful WMIC is for reporting, but it's handy for managing systems as well. I'll show you a few favorite time-saving tricks I use to control processes, make changes to network configuration, control services, and restart systems.
Using WMIC to stop and start processes on a system (remote or local) is a hugely useful capability. For instance, you could start a process on a remote system simply by typing the following:
/Node:"johnkel-fer"
process call create "notepad.exe
Sure, kicking off an instance of Notepad isn't that interesting, but it does make the point. Note that you'll be prompted to confirm the request. You could disable this prompt by setting the /INTERACTIVE global parameter to OFF.
Terminating processes is just as easy. Now that I have created all these instances of Notepad on my remote system, I'd like to get rid of them, so I issue this command:
wmic /interactive:off /node:"johnkel-fer"
PROCESS WHERE NAME="notepad.exe"
CALL Terminate
WMIC lets you terminate processes by name, rather than via process ID as you might have done in the past. This can be quite handy. Imagine you had an out-of-control process on multiple systems. Using WMIC combined with the process name and the list of system names or IP address, you could quickly shut down the rogue processes across your network. (Maybe not such a great idea—and an even better reason to carefully manage Administrative credentials in your enterprise.)
Note that I turned off interactive mode from outside of the WMIC command shell in batch mode from the command line (I preceded my request with WMIC, and it dropped back to the command prompt once the request completed). This is how you would automate the use of WMIC within a batch file, or as part of a scheduled process, rather than using interactive mode.

System Configuration Changes
All manner of system configuration options may be changed using WMIC. I find the NICCONFIG alias really useful. Perhaps you'd like to change a system from using a statically assigned IP address to leveraging DHCP without a desktop visit. You could look up the NIC card info using the following command:
WMIC nicconfig get description, DHCPEnabled, index
and change it to use DHCP (assuming the index number listed was 1) with the line:
WMIC NICCONFIG WHERE Index=1 CALL Enable DHCP
There are a number of other configuration settings for a network interface you can manage this way, such as the default gateway and WINS Servers.
Here's how to disable a service (Virtual Server in this case) on the local system:
wmic service where "caption='Virtual Server'"
call changestartmode disabled
... and on more than one system:
wmic /interactive:off /Node:johnkelnc6000,
"johnkel-fer"
service where "caption='Virtual Server'"
call changestartmode disabled
... and on a list of systems:
wmic /interactive:off
/Node:@serverlist.txt service where
"caption='Virtual Server'"
call changestartmode disabled
What kind of tool would WMIC be if it didn't allow you to remotely reboot systems? Luckily, it does:
wmic /interactive:off /Node:@serverlist.txt os
WHERE Primary=True call reboot

The Upshot
As useful as WMIC can be, it is not a replacement for WMI scripts or more powerful management tools. You can't easily automate the manipulation of data accessible via WMIC—calculate the percentage of free disk space, for example. Pulling the same data via a Visual Basic® script may allow you to manipulate or filter it and act on information more easily in customizable ways. One other key limitation of WMIC I've found is the need for systems to be online to generate reports. It is wonderful to be able to interrogate systems and create HTML or other reports using WMIC, but it is not a management solution. It sounds silly to say, but it's hard to ask a system about its configuration if it is offline! Tools with persistent information storage coupled with robust reporting and alerting (such as SMS 2003 and Microsoft® Operations Manager) should be the core of every secure, well managed infrastructure. Still, for quick and easy access to system information, WMIC is hard to beat.
WMIC does provide a wonderful way to harness the power of WMI, and I've only scratched the surface here. There's still a great deal left for you to explore and discover on your own. New command-line and shell options are on the way for Windows, including the upcoming release of Windows PowerShell™ (formerly known as MONAD or MSH). PowerShell, with stunning new capabilities for managing and automating Windows systems, should be released later this year. Until it is generally available, WMIC can lighten your administrative burden.
WMIC Requirements
Though WMIC is not available on Windows 2000, it can be used from a Windows XP or Windows Server 2003 system to access WMI—it even works to a limited degree with Windows NT, if WMI support is installed. WMI in Windows NT does not expose the event logs, so they may not be queried successfully from WMIC.
You’ll need a good amount of rights to use many of the capabilities of WMIC. Everything I’ve done in this article I did with full administrator rights. Also note that some aliases have not been implemented in both Windows XP and Windows Server 2003. The memorychip alias, for example, which can display the size and slots of memory modules (handy if you want to order RAM for an upgrade without opening up the system before hand) is not available in Windows XP.

WMIC Resources
If you want to read more about WMIC, check out these valuable resources:
  • Windows Management Instrumentation Command Line
  • WMIC—Take Command-Line Control over WMI
  • The Script Center

John Kelbley is an Account Technology Specialist for Microsoft based in the Northeastern USA. He is the author of many poorly written VBScript and Perl scripts for server and workstation administration, many of which are obsolete since the introduction of WMIC. You can reach John at kelbley@hotmail.com.


 System Management: Getting Started with Windows PE
New information has been added to this article since publication.
Refer to the Editor's Update below.

System Management Wes Miller

Getting Started with Windows PE
At a Glance:
  • The history of Windows PE
  • How Windows PE can stand in for MS-DOS
  • How to customize Windows PE
  • Windows PE Q&A
Download the code for this article: WinPE2006_09.exe (155KB)

Chances are you don't know much about the Microsoft Windows Preinstallation Environment, or Windows PE as it's usually called, even though it shipped the same day as Windows XP. Windows PE was
designed to allow Windows® setup or a 32-bit imaging program to run on a PC even with no version of Windows installed. The idea was to make things easier for OEMs. Windows PE has evolved over the years and, as you'll see, it can make your life easier as well.
For quite some time, MS-DOS® played a big part in Windows installation and setup, but eventually that became problematic. As both Windows and hardware grew more sophisticated, MS-DOS couldn't keep up. Its shortcomings as a setup initiator for doing a custom setup were plentiful. Performance was a big issue, so was driver availability. These problems became the key impetus for replacing MS-DOS for OEMs and eventually enterprise customers.
A developer on the Windows setup team came up with the idea of integrating the different components of setup into one solution so that a simple boot CD could provide a minimal environment that would let 32-bit setup run, eliminating the problems with MS-DOS. With that, Windows PE was born. Originally, the Windows setup CD included both a prebuilt version of Windows PE and a toolset that let you create your own build. Today, Windows PE is shipped only as the toolset; you need to build your own copy.
Eventually, Windows PE spread beyond the OEM community it was designed for. ISVs, enterprise, education, and government customers all took advantage of it, and they used it for far more than the deployment scenarios we initially envisioned. They used it for recovery and diagnostics as well. Today, Windows PE is available for customers with Software Assurance, as well as Enterprise Agreements, Campus Agreements, and as a component of several other licensing agreements with Microsoft.
[ Editor's Update - 8/22/2006: Windows PE is only available as a Software Assurance benefit with certain types of license agreements. See the Microsoft Volume Licensing Web site for more details, or contact your Microsoft licensing specialist.]
When running, Windows PE looks like Figure 1. You'll note that it doesn't include Windows Explorer, and as such does not have any of the regular Windows shell available. It's truly a bare-bones installation.
Figure 1 Default Configuration of Windows PE Booted to the Command Shell
Figure 1 Default Configuration of Windows PE Booted to the Command Shell

What You Get
As you can see in the sidebar "Windows PE Releases," there have been a number of upgrades. The basic functionality of Windows PE was broadly expanded to allow OEM partners and enterprise customers to perform WMI queries on hardware and to initialize classes of devices that no one originally had expected would be used under Windows PE. Windows PE was initially designed to boot from CD; network boot via PXE was an afterthought, and the hard drive method came very late in development. The intent with Windows PE was always to allow for a 32-bit environment with TCP/IP networking, hard disk access to enable imaging or scripted installation of Windows, and basic video support. Windows PE always uses the same basic VESA mode video driver regardless of the card in use. This lets it display very good color depth and resolution on modern VESA-compliant hardware, though some older hardware may default to a very unpleasant (though usable) color depth and resolution.
From the beginning Windows PE had only very basic Win32® API support, meaning that the Microsoft® .NET Framework, DirectX®, TAPI/MAPI/SAPI, audio, and many other high-level Windows APIs would not be available. Windows PE users began to regularly request a number of additional features. We were unable to officially engineer these features into the product, but we did provide a script that would allow a Windows PE admin add ADO connectivity to a Microsoft SQL Server™, and HTML for Applications (HTA) and Windows Script Host (WSH) support to an image. These provided a handy framework of tools that have enabled some creative deployment and recovery solutions. Windows PE 2.0, which is scheduled to ship with Windows Vista™, will add notable new capabilities.

Booting Windows PE
When you're starting with Windows PE, one of the first considerations is how you want to boot. Over the years the number of boot mediums supported by Windows PE has grown (see Figure 2).
Figure 2 Windows PE Boot Options
  • PXE (Pre-boot eXecution Environment) using RAMDisk boot technology
  • RIS (the Microsoft proprietary PXE implementation, which is traditionally used to launch Windows setup over the network)
  • Hard Disk (either directly or via a RAMDisk)
  • CD (or an ISO-formatted DVD)
  • RAMDisk (this allows for some very interesting scenarios which I’ll describe in depth in an upcoming article)
  • USB Flash Drive (UFD)

Technically, Windows PE can also boot from an LS-120/LS-240 disk, though I'd never recommend it due to serious performance issues. USB Flash Drive boot is something we worked hard on for Windows PE 1.6. It works very well, though it's only supported by Microsoft when an OEM provides it with a new system because there's no reliable way to ensure that systems would have the necessary capabilities. This method requires BIOS-specific functionality that must be provided by the PC manufacturer, as well as USB 2.0 support.
Your particular needs will determine how you can best use Windows PE. The important thing to remember is that you can basically reuse the same technology across multiple boot methods, no matter which one(s) you choose.
Before you begin creating your build of Windows PE, you'll need to make some decisions. A key question you'll need to answer is who's in charge. Will this be a self-service reinstallation solution that non-technical users will execute, or will it be used by your technical or IT support staff?
This is a critical question, since it will dictate whether you'll have corporate branding on the user interface, whether you need to build protections in to keep users from running the installer accidentally, and many other issues. Here roaming user profiles or a separate user data partition for Documents and Settings can come in handy.
You'll also need to decide if you'll build in some help and support for your users, and whether the solution should run completely hands free.
Deployment and recovery solutions with Windows PE can be as simple or as highly engineered as your requirements deem necessary. I've seen some incredible solutions developed on this platform, including hidden partitions, getting build information from SQL Server or a network share, and mixing and matching PXE and CD/DVD boot mechanisms. The best part about Windows PE is the countless ways in which you can configure it to do your bidding.
Windows PE Q&A
Send your Windows PE questions to tnmag@microsoft.com and I’ll answer them as time allows.

Q Doesn’t using Windows PE completely violate the NTFS security of Windows? Under Windows PE, the user runs all tasks as System, which is more powerful than local administrator.

A It turns out this really isn’t an issue. Law number 3 of the 10 Immutable Laws of Security says, "If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.". The point is that if someone can physically access your computer, there are numerous other methods besides Windows PE (a parallel install of Windows, an NTFS-capable install of Linux or even Mac OS X, or physical removal of the drive to another system running Windows) to remove or potentially destroy your data. True, Windows PE makes this more convenient. To counter this threat—as well as Law number 3 as a whole—you should either physically secure your system at all times or use EFS to at least secure your data, or a full disk encryption product, which will secure your data and even your entire system volume. This is something you should be doing with your mobile systems anyway if they are storing any sort of confidential data.

Q Can I PXE-boot Windows PE from anything besides RIS?

A With the RAMDisk boot capability in Windows PE 2005, yes. I’ll show you how in an upcoming article.

Building Windows PE
Building Windows PE generally requires two things: Windows PE build tools and a matching set of Windows media. The rule of thumb is that Windows PE build tools require a copy of Windows from that build of Windows (same service pack and product family) or the one immediately preceding. So for Windows PE 1.5, the build tools will check for either Windows Server® 2003 RTM media (either the Standard or Enterprise Editions) or Windows XP Service Pack 2 (SP2) integrated media. Note that the WMI features in 1.5 require Windows XP SP2, and the RAMDisk and USB Flash Drive features in 1.6 require Windows Server 2003 SP1.
To create a build of Windows PE 1.6, then, you will want to have the 1.6 build tools as well as a copy of Windows Server 2003 SP1 integrated media. Launch a command prompt and go to the directory where you copied the Windows PE build tools. At the prompt, type the following (the last four arguments are optional):
mkimg.cmd [source] [destination] [ISO Image] [/PNP] [/WMI] [/NOWF]
Let's say your Windows Server 2003 SP1 integrated media is on your D: drive; you want to build in C:\Staging and add WMI support; and you don't want to create an ISO image immediately. Enter the command
mkimg.cmd D:\ C:\Staging\ /WMI
and you'll end up with a CD-ready layout of Windows PE with WMI support in your
C:\Staging\ directory.
Now let's add HTA and WSH support. At the same command line, enter:
buildoptionalcomponents.vbs /S:D:\ /D:C:\Staging\ /HTA
You don't need to specify WSH; the script implicitly adds it because it's required by HTA. (You could also add ADO, but you don't need it for the samples here.) Once this build has completed, be sure to add the optional components installation command to the startnet.cmd file (the "autoexec.bat" of Windows PE, if you will—it's the file that automatically executes every time Windows PE boots after Win32 has started). Open the startnet.cmd file in Notepad (be careful not to execute it on your PC as it can cause an errant machine rename). To the bottom of startnet.cmd, add the line:
OC.BAT
This batch file will install HTA and WSH support once Windows PE has booted.
Now you can add the sample HTA-based wizard that's available on the TechNet Magazine Web site to your Windows PE image. Just download the ZIP file, open it, and copy all the files to your C:\Staging\I386\System32 directory. I've designed these scripts so that the most destructive parts are placeholders that show you what the command should be, but they don't really repartition, reformat, or reinstall anything. If you want the wizard to run automatically upon boot, add wizard1.bat after the OC.bat line. See Figure 3 and Figure 4 for a view of what the finished utility wizard looks like. This is merely a simplistic HTA example I'll build on in future articles, but the basics are here to allow you to begin a user-initiated setup procedure.
Figure 3 Windows PE Wizard
Figure 3 Windows PE Wizard
Figure 4 Choosing a Task
Figure 4 Choosing a Task
Once you have added the HTA files and any drivers or other files you want on your CD, you can easily create an ISO image by entering the command:
OSCDIMG -n –betfsboot.com C:\Staging\ C:\Staging.ISO
Note that you must include the -n parameter in this command or the names of the WinSxS directory (containing Windows side-by-side assemblies) will be trimmed and basic elements of Windows PE, such as Notepad, will silently fail.
After you create the ISO, you can burn it to a blank CD or DVD. Remember that the CD-burning software built in to Windows XP won't work for this—you'll end up with a coaster with a copy of the ISO on it. You need either a third-party software package that will burn ISO images directly to media or use the freely available solution called ISO Recorder. You can download it at ISO Recorder.

Maintenance
When we first shipped Windows PE in 2001, I thought people would have to maintain it periodically to install new drivers. The ubiquity of IDE drives and standard 10/100 Ethernet meant that the driver set we shipped with Windows XP was huge. The set that shipped later with Windows Server 2003, while more refined (it dropped some NIC and storage controllers that are more consumer-focused), still covered most systems unless they had SCSI storage or gigabit or other high-end Ethernet. The proliferation of Serial ATA and Gigabit Ethernet (and other high-end storage and networking) means that adding drivers to Windows PE isn't something reserved for the datacenter build team anymore. Adding network controllers used to be quite complicated. Since Interim Windows PE, all that has changed, thanks to DRVInst.
To add a new driver now, all you do is run drvinst, specifying the class of drivers you want to install, the source, and the destination Windows PE install. To add all network drivers from any Windows CD that have not been included yet, run:
drvinst.exe /OSCD:D: /onlyclass:NET C:\staging
Adding the operator /q to this command will cause it to run without asking for any verification. Only network drivers (they have class=Net in their .inf files; most also have names that begin with "net*" but you can't count on that) are installed post-boot for Windows PE. If you want to add any other driver types, you can use drvinst to add them to your Windows PE image, but you'll also have to add the /PNP command when building Windows PE, or Windows PE won't initialize them.
Alas, mass-storage controllers aren't so easy. You either need to press F6 very early as Windows PE boots and specify a floppy disk that contains a txtsetup.oem file and the driver to use or use the following steps (specific to the Windows PE install we've been building) to add the driver. (Note that you can't use a USB Flash Drive or any other kind of media here.)
  1. Create a directory called Driver1 under C:\Staging\I386\System32.
  2. Copy the entire contents of the floppy disk/image provided by your vendor to the Driver1 directory. This is the best way to ensure you don't omit any DLL or other files required by the driver in order for it to load.
  3. Using Notepad, open C:\Staging\I386\system32\winpeoem.sif.
  4. Remove all semicolons from the [OEMDriverParams] section (three lines total).
  5. Add Driver1 to the OEMDriverDirs line. Do not include quotes, and if you need to repeat the first step for multiple drivers, add them here as well, separated by commas.
Note that you may have to edit the vendor's txtsetup.oem file to ensure the device you are trying to load is the one specified in the [Defaults] section of txtsetup.oem. Only one default can be specified.

Next Up
In my next article I'll take a look at two of Windows PE's boot options: RAMDisk boot and USB Flash Drive boot. I'll discuss their benefits and limitations and also see how they can help us build a more powerful deployment solution.
Windows PE Releases
Here are the five releases of Windows PE, along with the name used to refer to each and its new features.
  • Windows XP RTM (Windows PE). This version included PXE boot, CD boot, and a complicated boot from hard drive method that used the Windows Recovery Console as a bootstrap. You could build it from Windows XP Professional RTM media.
  • Windows XP SP1 (Windows PE 1.1). It supported standalone Distributed File System (DFS) roots, improved boot from hard drive technique. You could build from Windows XP SP1 media.
  • Windows Server 2003 RTM (Windows PE 1.2). This version could build from Windows XP SP1 or Windows Server 2003 (Standard or Enterprise Editions) media.
  • Windows XP SP2 (Windows PE 2004/Windows PE 1.5). This version had support for WMI, the ability to add additional classes of drivers, the ability to cause plug and play rescan after boot, and the Windows Firewall. It could build from Windows XP SP2 or Windows Server 2003 media.
  • Windows Server 2003 SP1 (Windows PE 2005/Windows PE 1.6). RAMDisk boot capability, USB Flash Drive boot capability, WMI, Drivers, PnP, Windows Firewall. It could build from Windows XP SP2 or Windows Server 2003 SP1 media (RAMDisk and UFD only supported with Windows Server 2003 SP1 Windows PE).
The last two releases became known as "Interim Windows PE" or simply iWinPE for short. They delivered a collection of features often requested by enterprise customers and OEM partners that simply could not wait for the arrival of Windows Vista.

Wes Miller is the Product Technology Strategist at Winternals Software in Austin, Texas, where he focuses on all Winternals products, including Protection Manager, the Winternals Enterprise Security product. Previously, Wes worked at Microsoft as a Program Manager and Product Manager for Windows enterprise deployment.


 System Management: Monitoring Security Events with MOM
System Management John Orefice

Monitoring Security Events with MOM
At a Glance:
  • Rule Group creation
  • Creating event rules
  • Setting alerts and notifications
  • Viewing and analyzing results

Monitoring your infrastructure for general health and uptime is a complex job in itself. But the typical IT administrator doesn't have such a focused work life. If you're like most administrators, you're
being pulled in a hundred different directions, planning upgrades, maintaining systems, responding to security issues, implementing new technologies—and the list keeps growing.
And then there are tasks related to matters such as ensuring compliance with Sarbanes-Oxley (SOX) and the Health Insurance Portability and Accountability Act (HIPAA). These are not to be taken lightly and add yet another level of responsibility to your job. However, if you already rely on Microsoft® Operations Manager (MOM) 2005, you can use it to help simplify your compliance-related tasks.
MOM, a key building block in the System Center family of management products, is designed to simplify monitoring and management of large, heterogeneous IT infrastructures. I'll walk you through the process of creating a new MOM Management Pack that can be used to monitor certain security events in your domain controller (DC) Security event logs. In addition, I'll show you how to generate alerts, send notifications, and view the data needed for SOX- and HIPAA-related reporting.
By using MOM to monitor your Security event logs, you will be in a position to lower the total cost of ownership (TCO) of your infrastructure through trend analysis and compliance reporting, as well as ensuring that your extensive IT investment is secure.

Create Rules, Notifications, and Alerts
Using MOM 2005 to automate monitoring of your event logs is quite simple and can greatly improve the efficiency of how you gather and act upon events in your infrastructure. For the example here, I'll step you through creating the rules necessary to monitor for certain events and create notifications and alerts based on these events. After you've created your Management Pack, I'll discuss viewing and reporting on the data you've gathered.
Processing Rule Group
Whether you're a seasoned MOM user or you're thinking about deploying it for the first time, rule group creation is perhaps the most important task you can learn to do with MOM 2005. The first step in the creation of any fully functional Management Pack (not just those for security) is to create a new Processing Rule Group for the rules that will collect information from the services you will be monitoring. We'll begin our security monitoring the same way.
In the MOM Administrator Console (shown in Figure 1), you can create the event rules, set up alerts based on events in the event logs, specify to which computers this new set of rules will be applied, and set up notifications based on alerts for administrators. On the left-hand side, expand Management Packs, right-click on Rule Groups, and select "Create Rule Group..." from the dropdown menu. You are going to create a new rule group called "Security Monitoring." Type in the name, leaving all other fields set to the default, click Next, and then click Finish.
Figure 1 Administrator Console
Figure 1 Administrator Console
Once the wizard is completed, you are prompted to deploy the new rule group to a group of computers. This is where you specify which computers this set of rules will be applied to. In order to tie this new rule group to a computer group, click Yes. Since you want to monitor the Security event logs on the domain controllers, you need to tie the new Security Monitoring rule group to the DC computer group(s). If your organization is running Windows® 2000 DCs, this group is called Windows 2000 Domain Controllers. Similarly, if your organization is running Windows Server® 2003 DCs, this group is called Windows Server 2003 Domain Controllers. In some cases, you may have more than one type of DC; in such instances you deploy the new rules to both groups. In this example, I'll step you through deployment to a single group, the Windows Server 2003 Domain Controllers group (as shown in Figure 2).
Figure 2 Specifying a DC Group
Figure 2 Specifying a DC Group
Event Processing Rule
Now you need to create the event rules that will be used to capture events as they occur in the DC Security event logs. MOM 2005 makes it easy to automatically deploy rules and Management Packs to systems without administrator intervention. Since you tied the Security Monitoring rule group to the appropriate computer group, the rules you create will be automatically deployed to those servers. In turn, as soon as events that match your rules are generated on your DCs, the events will be collected and the appropriate action taken.
There are five types of event rules that you can create for any given Management Pack: Alert on or Respond to Event (Event), Filter Event (Pre-Filter), Detect Missing Event (Missing), Consolidate Similar Events (Consolidation), and Collect Specific Events (Collection). For this project, I am only going to look at two of these types.
The first type is used to alert on or respond to events and is used when you want to take a specific action when a particular event occurs in the event log. For this example, you will be monitoring the membership of the Domain Administrator group. Due to the controlled state of the Domain Admins group, you want a security alert to be generated if the membership to this group changes unexpectedly.
The second type of rule you'll use here is one that collects specific events that occur, but doesn't take any action—perfect for collecting information for audit reports. I will show you how to configure MOM 2005 to collect events as they occur and then store the events in the MOM OnePoint database and then in the System Center Reporting (MOM Reporting) database for reporting and trend analysis.
For this Management Pack, you are going to use this type of rule to audit for when the password is reset on any account in the domain. You could go a step further and set up a rule to alert you when a password is changed on a high privilege account (such as a Domain Administrator account). Other collection rules that are commonly created are for the deletion and creation of accounts and for failed logon attempts.
At this point, I want to outline the rules that we'll be looking for in the Security event logs of our DCs (see Figure 3). These events, as well as all audit events, are listed and well documented in the Windows 2000 Security Event Descriptions support article. In order for these events to be inserted into the Windows Security event log, the proper auditing needs to be turned on. The directions for doing this are available at "How to enable and apply security auditing in Windows 2000". Figure 4 shows the appropriate level of auditing needed for this example.
Figure 3 Rules Used in Sample Management Pack (Close Figure 3)

Event Number | Type | Description
628 | Success Audit | User Account Password Set
632 | Success Audit | Security Enabled Global Group Member Added
633 | Success Audit | Security Enabled Global Group Member Removed
641 | Success Audit | Security Enabled Global Group Changed
Figure 4 Setting Audit Policy
Figure 4 Setting Audit Policy
Now let's create the appropriate event rules in your Security Monitoring rule group. You'll start with a rule for monitoring event ID 641 in the Security event log. Make sure that Rule Groups is expanded in the left-hand side of the MOM Administrator Console, expand the newly created rule group called Security Monitoring, and right-click on the Event Rules section of the tree. Select Create Event Rule... from the dropdown menu, choose Alert on or Respond to Event (Event) from the list, and click Next. In the Data Provider window, make sure to change the Provider name to Security (notice that the Provider type automatically changes to Windows NT® Event Log). After selecting Security, click Next to continue.
The Criteria window is where you define exactly what event in the event log you want to look for. Figure 5 shows the configuration settings for this window. Note that you need to enter some detailed information into the Criteria description. Since you want to look specifically for changes to the Domain Admins group, you need to define the rule to look for this. To do this, click on the Advanced... button and enter the information as shown in Figure 6.
Figure 5 Defining What to Look For
Figure 5 Defining What to Look For
Figure 6 Entering Advanced Criteria
Figure 6 Entering Advanced Criteria
When finished, click Close and then click Next until you reach the Alert window. This is where you define the type of Alert that will be generated in response to the event being discovered. Since this is a security-related issue, pick Security Issue from the dropdown box. Figure 7 shows this window with the appropriate information. Click Next, choosing all the defaults until you reach the last screen where you will find the Rule Name box. Here, type Domain Admins Global Group Member Changed, and click Finish.
Figure 7 Setting Alerts
Figure 7 Setting Alerts
In addition to this rule, you need to create two more event rules that provide more detail about the change to the Domain Admins group. To do this, you'll create similar rules for event IDs 632 (which will tell you who was added) and 633 (which will tell you who was removed). The processes are identical to the process that we just completed, simply substituting the new event ID numbers in place of event ID 641. Be sure to add the detailed Criteria Description for Domain Admins as before.
As mentioned earlier, the second type of event rule you are going to use will collect information from the event logs, but will not generate an alert. For this example, you will be collecting all events that occur when a user account password is changed. To do this, right-click on the Event Rules section of the Security Monitoring Management Pack, just like you did for the previous event rules. Click on Create Event Rule..., and choose Collect Specific Events (Collection) from the list of rule types. Click Next and pick Security from the Provider name list. On the Parameter Storage screen, make sure to choose Store all event parameters—this ensures that all of the information available in each event is brought over to the MOM database for audit reporting purposes. Click Next, leaving all of the defaults until the last screen where you can specify the Name field. Type User Account Password Set and click Finish.
Once you've finished creating all of the event rules, make sure to read this next step carefully. When you make any change under the Management Packs node in the Administrator Console, you must right-click on Management Packs and choose Commit Configuration Change. This will ensure that the changes are propagated down to the servers for which the rules apply. Without doing this, the new rules you created may never be applied to your domain controllers and, in turn, will never begin monitoring the Security event logs.
Notification Group
The next step is to set up a notification group that contains the users to receive the alerts—this can really benefit the security of your infrastructure. Imagine getting a page after business hours because someone gained control of your DC and added a user to the Domain Admins group. You could immediately take corrective action.
Using the MOM Administrator Con-sole, create a notification group called Security Administrators. Since this is an optional step, I won't go into all the details. You may already know how to do this; if not, you may be able to use one of the built-in notification groups that ship with MOM 2005.
Alert Rule
The last step in building your Management Pack is the creation of an alert rule that responds to the security alert that is generated by the Domain Admins Global Group Member Changed rule. When generated, the alert will show up in the MOM 2005 Operator Console. But due to the severity of an unauthorized change to the Domain Admins group, you should also have the notification sent to the Security Administrators Notification Group. This is where the Alert Rule comes into play.
Expand the Security Monitoring Rule Group, right-click on the section titled Alert Rules, and select Create Alert Rule.... In the Alert Criteria window, set the options as shown in Figure 8. These settings specify that any time a security issue alert is generated from the Security Monitoring rule group, a specific action should take place. In this case, you want to send a notification to the Security Administrators notification group.
Figure 8 Setting Alert Criteria
Figure 8 Setting Alert Criteria
To continue, click Next on the Schedule screen. In the Response screen, add the response to be sent. Click Add and choose Send a notification to a Notification Group.... From the dropdown menu, choose Security Administrators and leave all other fields on the other tabs at their default settings. Click OK and then click Next on the Knowledge Base screen. On the General screen, type a name for the new Alert Rule and click Finish. Again, you must right-click on Management Packs in the Administrator Console and choose Commit Configuration Changes.
Now, you can avoid getting alerts about planned changes to your Domain Admins group. MOM 2005 has a feature called Maintenance Mode, which can be turned on by right-clicking on any computer in the Operators Console. By placing a computer into Maintenance Mode, you will suppress alerts from being generated for that computer. (The events will still be collected, though.) Most organizations find this feature extremely helpful during scheduled maintenance windows.

Viewing and Reporting
Now that you've configured MOM to collect and respond to events, you need a way to look at the information both in real-time and for trending purposes. The real-time data is excellent for looking at information as it occurs on a day-to-day basis whereas the trending data is good for running reports that can be used for your own analysis or for SOX and HIPAA compliance.
Operator Console
To look at the alerts in real-time, you need to use the Alerts view inside the MOM 2005 Operator Console. Open the Operator Console and go to the Alerts button in the bottom-left quadrant of the screen (see Figure 9). This brings up a view of all the alerts that MOM has generated based on the events occurring in your environment.
Figure 9 shows MOM-generated alerts, each containing a lot of detailed information. This information was captured by MOM when the event was collected and then inserted into the alert that was generated. It offers a great way to get all the information you need immediately, shortening your time-to-resolution and lowering your TCO.
Figure 9 Alerts Generated by MOM
Figure 9 Alerts Generated by MOM
You're not creating alerts for all the events being generated. When you're doing event collection, you may want to look at your specific events in real-time. You can look at these in the Events view in Operator Console. With the Operator Console open, click on the Events button to bring up a view of all the events that MOM is collecting in your environment. Figure 10 shows what the events look like; all the information that exists in the event log is copied over to MOM.
Figure 10 Viewing Events
Figure 10 Viewing Events
Reporting Console
MOM 2005 provides an extremely intuitive reporting tool based on SQL Server™ Reporting Services. With it, you can customize reports and schedule automatic offline report generation for delivery via e-mail or shared disk space. If you're interested in finding out more about the capabilities in the MOM 2005 Reporting solution, review the MOM 2005 Conceptual Guide.
I've found that most people are unaware of one of the most versatile reports that MOM 2005 offers right out of the box. This report, called Event Analysis, allows you to view the information on any event that MOM is collecting. In a default MOM Reporting installation, the Event Analysis report can be found within the reporting tool by going to Home | Microsoft Operations Manager Reporting | Operational Health Analysis. Using event 641 as an example, navigate to MOM Reporting, which is available from the Go menu in the Operator Console. After you've filled out all the fields, as shown in Figure 11, scroll to the right and select View Report. You'll see all of the events that occurred matching the criteria you've specified. Many people use reports almost identical to this for audit reporting purposes.
Figure 11 Event Analysis
Figure 11 Event Analysis
In addition, since MOM Reporting is built on SQL Server Reporting Services, you can create your own reports using Visual Studio® (if you're running the MOM Data Warehouse on SQL Server 2000) or using the new Report Builder tool (if you're running the MOM Data Warehouse on SQL Server 2005). For help authoring reports using Visual Studio, see Chapter 8 of the MOM 2005 Management Pack Development Guide.

Wrap Up
MOM 2005 is a robust tool that can be used to monitor many business functions in an IT environment. The Management Pack I've discussed here will monitor the Security event logs on your domain controllers, providing an easy way to meet many of the auditing requirements associated with SOX and HIPAA. However, the techniques outlined here can be applied more broadly. You can create rules to monitor the overall health of your infrastructure and identify potential security threats.
Using these events as a base, you can see how flexible MOM can be to proactively monitor other apps that you always rely on. By creating other Management Packs you'll be able to dramatically increase uptime and meet your Service Level Agreements.

John Orefice is a Technology Solution Professional in the Microsoft Mid-Atlantic States district. He has worked with Microsoft management solutions for several years. He can be reached at john.orefice@microsoft.com.


 System Management: Essential Tools for MOM Administration
System Management Dave Cristini and Matt Goedtel and Eric Kamor

Essential Tools for MOM Administration
At a Glance:
  • MOM Resource Kit basics
  • Management Pack Toolkit utilities
  • Troubleshooting tools
  • MOM Power Toys

Resource kits have always provided administrators with a Swiss Army knife of useful add-ons, and the one for Microsoft Operations Manager (MOM) is no exception.
At the time of its release, MOM 2005 included a resource kit, but it was refreshed in February 2006 and contains some nifty new tools, divided into five categories as shown in Figure 1. We'll explore only the first three here. Look for a follow-up in the coming months where we'll discuss the connectors and accelerators.
Figure 1 MOM Resource Kit Categories (Close Figure 1)

Category | Purpose
Management Pack Tools | Modules to help develop, test, and deploy customized management packs.
Troubleshooting Tools | Tools to help you determine what’s wrong when MOM is not doing what you expected.
Power Toys | Cool add-ons that extend functionality and usability.
Product Connectors | Extensions that allow you to leverage the Microsoft Connector Framework in MOM to integrate with other management frameworks.
Solution Accelerators | Solutions, guidance, and scripts to help your organization build its operational efficiency with MOM 2005.

Management Pack Tools
There may be over 170 management packs in the MOM catalog, but if you are like most MOM administrators, you have internally developed line-of-business apps you need to manage for which you can't find an off-the-shelf solution. The 11 tools that make up the management pack toolkit can help you develop, document, test, and maintain your customized rules.
Management Pack Wizard This wizard lets you quickly and easily create a basic management pack to monitor services, performance, and events for an application. It also lets you create a custom state role with subcomponent detail—the same type of component/subcomponent state health you get from other management packs. For instance, the Base Operating System Management Pack shows overall operating system health, with details for disks, processors, and services. You can manage nearly any app with MOM in just a few minutes.
To monitor services, launch the wizard and browse to any machine to specify what services MOM should watch. The wizard creates all the necessary service discovery and monitoring rules—no need to know that you are looking for a 21207 event and parameter 5 must match a specified string! You can even define which subcomponent's health state this is associated with.
Performance threshold monitoring is just as easy and lets you specify both yellow (warning) and red (critical) threshold values (see Figure 2).
Figure 2 Performance Thresholds
Figure 2 Performance Thresholds
And it's the same for event log monitoring. If you've used the MOM 2000 Import Dynamic Link Library feature, you'll find the Management Pack Wizard to be a much more powerful replacement. This portion of the wizard lets you point to any machine and read the list of message DLLs that are registered to write to the event viewer. Simply select the event source, and the list of event IDs and messages from that provider is presented. Select the ones you want MOM to monitor, edit the message or alert severity, even combine items (the wizard creates the necessary regular expression syntax), then save your selections. The result is a custom management pack .akm file you can import into your MOM Administration Console with full state health awareness. Be careful, though—since you can't easily uninstall a management pack, be sure to test it first!
Remove Blank Rule Names If you are importing any custom management packs from a MOM 2000 Service Pack 1 (SP1) environment, you'll want to run them through the Remove Blank Rule Names utility first or your import into the MOM 2005 infrastructure may fail. This utility simply validates that each processing rule has a name, generating a new one if necessary. Believe it or not, you could have had an unnamed or blank rule in the past. Now every rule must have a name.
Response Tester Developing and debugging scripts run by MOM outside of the infrastructure is difficult. MOM executes scripts under the agent Action Account and accesses the internal object model presented by the MOMHost process. ResponseTest.exe helps you overcome those challenges by emulating the MOM agent environment. With ResponseTest.exe you can now test scripts before introducing them into your infrastructure. For more information, check out the discussions of the Response Tester utility on Brian Wren's Scripting MOM series at the TechNet Script Center.
Event Creator Do you have rules that should respond to a particular event log entry and want to test them? Event Creator allows you to specify the event log, event source, event ID, calling user, and event type, then it creates the event log entry for you. Let's say you need to verify that MOM gets an alert for a serious problem in Active Directory® or another critical application. You can't simply force the problem to occur to create the real event, but you can use Event Creator to generate it for you. Figure 3 shows how we've created an event from source COM+ with eventID 5069, as an error. The event viewer shows the results as seen in Figure 4.
Figure 3 Building an Event
Figure 3 Building an Event
Figure 4 Test Event in Event Viewer
Figure 4 Test Event in Event Viewer
Event Creator needs to be installed on the machine from which you want to generate the alert. It installs quickly, but doesn't create an icon or an entry in a program group; you'll find it in the %Program Files%\EventCreator folder. Note that hidden in the documentation folder of your resource kit install is an XLS file which lists the internally generated MOM event IDs and their text. This can be very useful for testing MOM health-related rules.
Managed Code Response Utility One of the MOM 2005 alert responses lets you call a method on a managed code assembly. Unless you're a developer, you probably won't know what to enter into each field or where to get that info. The Managed Code Response Utility can get the information for you (see Figure 5). Run MCRUtil.exe against the assembly name to get the full assembly name, use the /type switch to get the types, and the /method switch to get the methods it provides. Now that you've got the information you need, you can use the tool to execute the managed code on your MOM management server or MOM agent.
Figure 5 Managed Code Response Utility
Figure 5 Managed Code Response Utility
Resultant Set of Rules Need to generate a list of the rules targeted to a particular agent? The Resultant Set of Rules tool is what you want. You can think of it as the MOM equivalent of the Group Policy Resultant Set of Policy (RSoP) tool. When you run RSOR.exe against a specified MOM agent, this tool creates a text file listing all the rules applied to that agent. There are two things to be aware of: the tool doesn't include Overrides and it drops the results into the folder C:\ResultantSetOfRules.
Configure Action Account If you're using a specific account (instead of the default LocalSystem) as your agent Action Account, chances are you've received alerts that MOM can't monitor its performance or something similar. The problem is that the Action Account needs certain permissions to carry out some of the monitoring, which it may not have in a low-rights scenario. The Configure Action Account utility can set those permissions for you. You may need to run it on a Windows Server® 2003 hosted agent not using LocalSystem as its Action Account. When run, it creates the Action Account membership in the Users and Performance Monitor Users local groups and grants the necessary security rights for the MOMHost process.
Convert Management Packs to XML If you need to document your management packs, the Convert Management Packs to XML tool is one way to do it. Run MP2XML.exe against an .akm file and it generates an XML version of the management pack. You can then open the XML document in Microsoft® Excel® or Word, select the fields you want, and there you have it—documentation of your rules. One caveat: you can't go the other way—convert an XML document into an .akm file.
Management Pack Differencing Tools Combined with the output of the Convert Management Packs to XML utility, the Management Pack Differencing Tools can identify what has changed between two versions of a particular management pack, with either GUI or command-line output. Once you export your management pack and convert it to XML, you can load it into the differencing tool and see what has changed. You can even automate this process to perform a periodic comparison to a user-defined lockfile (a file containing a list of rules that should not change).
Rule and Group Toggle Utility Do you need to bulk-enable or disable rules or computer groups and dread the thought of clicking so many times in the administrator console? Relax! The Rule and Group Toggle Utility makes it easy. You can run RuleUtil.exe with a /list switch to get the list of rule group or computer group names, their object IDs, and the current state (enabled or disabled) for each one. With that, you can run RuleUtil.exe with the /enable or /disable switch and pass the name of the group to perform the action against—very useful during testing when you may need to enable or disable one or more processing rule folders of a management pack.
Business Activity Monitoring Wizard If you're monitoring BizTalk® Server, the Business Activity Monitoring (BAM) Wizard can help create the necessary scripts in MOM to retrieve key performance indicators (KPIs) that you define.

Troubleshooting Tools
The MOM Resource Kit includes a selection of tools that ease setup, maintenance, and troubleshooting.
Cleanup MOM No doubt you've seen the fire alarms that say "break in the event of an emergency." The Cleanup MOM utility is just that sort of tool, to be used only as a last resort. Cleanup MOM is designed to remove MOM from a system, including the Windows® Installer registry keys relevant to the installation of MOM server or agent components. It will remove MOM 2000 (including SP1) and MOM 2005 (including beta and release candidate installations).
The normal methods of removing the agent or components should always be tried first. Do note that if you use this tool to remove an agent from an agent-managed system, its primary Management Server will not be aware of this and will alert on a heartbeat failure. To clean the management server, you will need to manually delete the entry from the MOM Administrator Console. This program should be run on the agent-managed server locally.
Management Group Utility Sometimes you may have to move an agent-managed server from your test lab into production in haste, perhaps without removing the agent or forcing it to unmanaged management mode and then deleting the cache directory. In that case, the rules are orphaned on the agent-managed server. The Management Group Utility (MGUtil.exe) can help in cleaning up the configuration the server received from the management group membership. Execute MGUtil.exe /r to remove any management groups the agent reported to.
This tool can also assist in situations where you have a multi-homed agent and you want to identify which management groups the agent reports to. Simply run MGUtil.exe without any switches to receive a list. As with other resource kit tools, this tool must be run locally.
MOM Information Utility The MOM Information Utility can clear the queue on an agent-managed system, and dump the rules, VarSets values, and responses from a MOM agent to an XML file when you need to troubleshoot or review your management pack rules. It also lets you debug custom scripts and place an agent into maintenance mode. That last feature gives you extra flexibility—you can put your server into maintenance mode by configuring a script or batch file with Task Scheduler, without having to use the Operators console. MOMInfo.exe can place an agent into maintenance mode infinitely or for a certain timeframe, by calling:
MOMInfo.exe /maintenancemode:<Timeout>
Timeout equals number of seconds; the default is -1 (infinite).
MOM Inventory If you need to open a case with Microsoft Product Support Services (PSS), you may be asked for detailed information from your agent managed system or management server. If so, MOM Inventory is just the tool to help. It is designed to collect vital information, including Windows Installer logs, trace logs, MOM registry information, configuration information stored in the database and locally, running processes on the system, and event logs.
This tool should be run locally and requires the Microsoft .NET Framework. The program has a graphical interface; to execute it, simply click the Run Collection button and specify where you want to save the CAB file that stores all the collected data. As Figure 6 shows, you can monitor the utility's progress as it runs.
Figure 6 Gathering MOM Inventory
Figure 6 Gathering MOM Inventory
MOM Trace Log Viewer Ever look at the .mc8 files under the %SystemRoot%\Temp\Microsoft Operations Manager folder on an agent-managed server and wonder what was in these files and how to view them? Well wonder no more: the MOM Trace Log Viewer will shed some light on the matter. To view these log files, copy MOMLogViewer.exe to the agent or management server, run the executable, and point it to the specific log file you need to view. To see just a glimpse of what the Log Viewer displays, check out Figure 7.
Figure 7 Viewing a MOM Trace Log
Figure 7 Viewing a MOM Trace Log
By default, MOM Trace Log Viewer will display the entire contents of the file, but you can filter within a specific time, by thread, and so on. If you're dealing with a large log file, a handy feature lets you create bookmarks for specific entries by highlighting that line and pressing Ctrl+B. You can then jump to a bookmark by pressing Ctrl+G (or by selecting a bookmark from the Edit menu). Note that the log viewer shows a snapshot of the trace log, not a real-time view of events as they occur.

MOM Power Toys
The MOM Resource Kit contains a set of useful tools called the MOM Power Toys, designed to simplify some of the administrative tasks and integration points of a MOM 2005 deployment.
Agent Helper The Agent Helper automatically allows management of agents when there is no heartbeat present by restarting the agents and reinstalling them as needed. This is an update to the MOM 2000 utility and leverages the managed code response feature of MOM 2005. This tool is extremely helpful as a last-ditch effort to maintain client health. Agent Helper will attempt three checks on the agent: verifying the MOM service exists; if so, restarting it; and if not, performing an agent reinstall.
Alert to RSS Utility The Alert to RSS Utility can provide current information about the number of unresolved alerts on the management server, categorized by resolution state, as well as a summary of the number of computers being managed. The utility is based on RSS 2.0 and can be used to publish other data from MOM via the MOM APIs. It must be installed on a MOM management server and must be compiled before first use.
Computer Group Hierarchy Utility The Computer Group Hierarchy Utility helps to export your computer group hierarchy and recreate it elsewhere, as well as create computer groups based on Active Directory containers and their hierarchies. It can be used when you need to replicate work done on one management group to another disconnected management group. The utility needs to be run on the MOM server. The output is in XML and can be used to recreate the data on the target system.
Console Scope Utility You can use the Console Scope Utility to automatically update console scope membership, as well as to mirror Active Directory security group membership to a console scope. This helps you synchronize Active Directory group members with MOM 2005 console scope members. Console Scope runs only on a MOM management server and could be run as a scheduled task to keep group members in sync with scope users.
DAS Role Update Utility The DAS Role Update Utility removes the BUILTIN\Administrators group from the MOM Administrator role. The default behavior from a security perspective is that the MOM Administrator and Operator consoles are accessible to the local administrators group. This utility will remove that access so that only the MOM Administrators group can access those consoles.
Management Group Utility If you have orphaned management group data on your agents from test management groups, the Management Group Utility can help to identify and clean up the data. This utility lets you list and remove management groups from the agent side, and it will list the current management groups an agent reports to, and diagnose and remove any corrupt management groups.
MOM Remote Prerequisite Checker The MOM Remote Prerequisite Checker can determine whether the required services and ports are accessible in order to push an agent or run discovery. It is a great tool for troubleshooting security and network issues for MOM deployments, and lets you export results to a log file. This is a standalone GUI utility and can be run under alternate credentials.
Operators Console Notifier Have you ever wanted a pop up dialog to tell you about open alerts in MOM? Then take a look at the Operators Console Notifier, which alerts operators through a pop-up from the System Tray. This tool notifies MOM users and administrators about changes in the alert state. When a change is detected in any of the counters, the changes are shown in bold until the notification is closed. The Operators Console Notifier requires both the .NET Framework and the MOM console to be installed. The utility is right-click enabled to force a manual update or auto-hide notifications (see Figure 8).
Figure 8 Console Notifications
Figure 8 Console Notifications
Password Updater Password Updater is a handy new Power Toy that aids in updating many aspects of Windows that require a security principle, including services, COM+ objects, scheduled tasks, and IIS virtual directories. This tool can help to automate the password or account update of the MOM Data Access Server (DAS) COM+ object on MOM management servers, the SystemCenterDTSPackageTask scheduled task on the MOM reporting server, and the MOMCONN NT service on any source management group management servers. This utility can reference a text file for a bulk password change among large groups of servers. We've presented Password Updater from the perspective of its usefulness to MOM, but this utility could also be used for updating passwords in bulk on any system.
SharePoint Web Part The SharePoint® Web Part enables the presentation of MOM data in a browser-based console, along with the RSS feed. This lets you show MOM data from within SharePoint, by taking advantage of the MOM 2005 SDK. The utility requires that the management server be running both MOM 2005 and either Windows SharePoint Services (WSS) or SharePoint Portal Server (SPS) 2003. It is recommended that you use a separate management server that does not manage agents to provide the data to SharePoint, and that the server not be listed as a failover server for the MOM agents. This is source code you can modify as necessary, but needs to be compiled before first use.
Task Launcher The Task Launcher utility starts MOM tasks from the command line and is very useful for leveraging tasks in scripts. The task must already exist in MOM in order to be used and the utility should only be used for runtime tasks—those that run on the MOM server or agent, not for console tasks. This utility requires the .NET Framework.
Exchange Server Management Pack One of the many management packs offered for MOM 2005 is the Exchange Server Management Pack. A Power Toy called Exchange Server Management Pack Configuration Wizard provides a graphical user interface for configuring it. Among the items you can configure are test mailboxes, message tracking, and service monitoring. You can use it for both Exchange Server 2000 and Exchange Server 2003.

Wrap-Up
You can download the MOM Resource Kit. You'll want to install it onto either your MOM management server or at least a workstation having the MOM consoles installed as some of the tools have dependencies on those pieces of code. As we noted, a few need to be compiled, so for those you'll also need Visual Studio® installed. If you've done any custom reporting for MOM, you probably already have that.

Dave Cristini is a Management Specialist with Microsoft in the New York region. He has been working with management solutions for the last six years. He can be reached at davidcri@microsoft.com.
Matt Goedtel is a Management Technology Solutions Professional working out of the Microsoft NY/NJ District and has been with Microsoft for over two years focusing on SMS and MOM specifically. Reach him at mgoedtel@microsoft.com.
Eric Kamor is a five-year veteran of Microsoft and works as a Management Specialist focused on the System Center product family. He can be reached at eric.kamor@microsoft.com.


 System Management: Integrating MOM into Your Existing Infrastructure
System Management Andrzej Lipka

Integrating MOM into Your Existing Infrastructure
At a Glance:
  • Plan a highly available MOM 2005 deployment
  • Integrate MOM with existing systems
  • Configure escalation for MOM notifications

As a central administrator, you want a single point of view into your whole IT infrastructure and you need it to be available at all times. A solid IT monitoring solution must be highly available and it must be able to
integrate with existing systems. With Microsoft® Operations Manager (MOM) 2005, you can achieve a high degree of availability and integrity of the monitoring solution. In this article, I will detail some of the methods you can use to achieve these two requirements.
For a highly available deployment of MOM 2005, you must ensure that each and every component of MOM is in some way fault tolerant. You may have read about the Service Continuity Solution Accelerator for MOM in the article "Five Solution Accelerators to Lend MOM a Helping Hand". This is a valuable tool, but it deals primarily with disaster recovery and multiple management groups. In this article, I focus on how to provide high availability for a single management group. Figure 1 illustrates the architecture I'll describe.
Figure 1 MOM High-Availability Architecture
Figure 1 MOM High-Availability Architecture

Deploying MOM Databases
At the heart of all MOM functionality is the operational database called OnePoint. This is where all data is written to and read from. If this database crashes, all MOM functionality becomes unavailable and results in the following problems:
  • Agent data from management servers is not written to the database.
  • Data is not transmitted to and from applications integrated with MOM.
  • MOM consoles cannot display content.
The first point is the most critical. When the OnePoint database is down, new alerts can't be generated. If you rely on notifications—e-mail or SMS alerts, for example—you may not even notice the database is down since alert rules will not run (they are, in fact, plain SQL triggers).
If the database is unavailable, the management server will store incoming agent data (including alerts, events, and performance counter values) on the local hard disk by default, up to 30MB. And when the database is back up and running, the locally cached data will be sent to the database. But this is by no means fault tolerance. For high availability of MOM databases, you should install them on a SQL cluster.
There has always been some confusion around MOM 2005 Service Pack 1 (SP1) and support for clustering databases. The operational (OnePoint) database is supported on active/passive and active/active SQL clusters. With the second option, you need to use the momcreatedb.exe tool to install the database. The historical reporting database (SystemCenterReporting) is only supported on active/passive SQL clusters. With the active/passive option, there can only be one instance of a MOM database on the SQL cluster. Therefore, you can have more than one operational database on a single SQL cluster (simply by installing them in different instances), whereas you can have only one reporting database on a SQL cluster. For step-by-step instructions for installing MOM databases on clusters, see the Deployment Guide.
Hardware for clustering solutions is much more expensive than the hardware for standalone servers. Of course, you can use existing SQL Server™ instances to install the MOM databases provided these SQL clusters have enough capacity in terms of both storage and performance. To measure current use of the SQL Server instances, use the Performance Monitor and the System Center Capacity Planner. In addition, you can use the MOM 2005 Sizer Tool to roughly forecast load and storage minimum requirements for the computer running SQL Server.
It is essential to install the OnePoint database on a cluster to achieve high availability. The SystemCenterReporting database can also be clustered, but this is not as critical since its downtime only leaves reports inaccessible. Of course, if you rely heavily on reports, clustering the reporting database may be critical to your operations.
It's worth noting that SQL Server 2005 provides greater stability and availability than SQL Sever 2000. Once you've installed three hotfixes, MOM 2005 SP1 can be run on SQL Server 2005. I've detailed how to set up this configuration on my blog.

Configuring Management Servers
MOM management servers are responsible for communication with agents, consoles, and transferring data to and from the OnePoint database. They also provide the point of entry for connecting to third-party platforms through the MOM Connector Framework Web service.
To provide fault tolerance for your management server, you simply install more than 1, but fewer than 10, management servers in the management group. The agents installed in the management group will automatically switch to another management server if the primary MOM server goes down. If all the management servers in the group are unreachable, the agent will locally cache up to 3MB of data, by default.
The MOM administrator console only shows the primary management server of an agent. You can verify or modify all the agents' management servers in the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Mission Critical
Software\OnePoint\Configurations\MG1\Operations\Agent\Consolidators]
"Consolidator 1 Host"="MOM1.vs.local"
"Consolidator 1 AD Name"="MOM1.VS.LOCAL"
"Consolidator 2 AD Name"="MOM2.VS.LOCAL"
...
You can also do this via add/remove programs (on the Advanced button) for the MOM 2005 agent software, as shown in Figure 2. When the agent is running in control level full, you can only set the primary management server (through discovery rules). All the other management servers in the management group are automatically assigned to that agent as secondary. Any changes made in the registry or through add/remove programs will be overwritten. When the agent is running in control level none, you can specify exactly which management servers are secondary in the registry and those values will not be overwritten.
Figure 2a Microsoft Operations Manager 2005 Agent Configuration and Setup
Figure 2a Microsoft Operations Manager 2005 Agent Configuration and Setup
Figure 2b Microsoft Operations Manager 2005 Agent Configuration and Setup
Figure 2b Microsoft Operations Manager 2005 Agent Configuration and Setup
You should distribute the load on management servers evenly (proportional to each management server's capacity). The primary management server is defined by the discovery rule. All other management servers in the management group are applied as secondary to the agent. If you want to modify the primary management server, you need to change the original discovery rule or the ManualMC.txt file. Thus it is not a good idea to delete your original discovery rules.
If you have a lot of servers to monitor with MOM you may want to put forth regular expressions in your discovery rules. Tools like Ultrapico's Expresso, used for creating and testing regular expressions, can become handy in developing those rules.
You might be tempted to install management servers on virtual machines. This is acceptable as long as the capacity is evaluated properly. It depends on the number of reporting agents and deployed management packs. Generally, the biggest obstacle is the single processor inside the guest operating system in Virtual Server 2005 and Virtual Server 2005 R2.
Management server operations are processor intensive, so it is a good idea to install the management server on a dual processor machine when the number of reporting agents exceeds 50 (assuming about 10-15 management packs, including major ones like Active Directory® and SQL). You definitely need a dual processor server for more than 100 agents.

Integrating MOM 2005 into Your Infrastructure
To get the most out of a highly available monitoring solution, it must be capable of integrating into your existing environment. Take trouble-ticketing/service desk systems, for example. Many organizations, especially large enterprises, rely heavily on these systems for reporting and tracking IT problems and resolutions. Synchronizing MOM with the trouble-ticketing system adds some important enhancements:
  • A single console lets you manage problems related to servers.
  • Service desk can be used as an escalation mechanism for MOM.
  • Built-in service desk reporting can be used as an enhancement to MOM reporting services.
MOM has a Software Development Kit you can use to develop connectors. The MOM SDK exposes several interfaces that are exerted for development:
  • Operations Database SQL Views
  • Reporting Database SQL Views
  • Windows Management Instrumentation (WMI) classes
  • .NET Framework classes for: Microsoft.EnterpriseManagement.Mom namespace; Microsoft.EnterpriseManagement.Mom.Runtime namespace for developing managed code responses; MCF (Microsoft.EnterpriseManagement.Mom.Connector and Microsoft.EnterpriseManagement.Mom.Connector.V2)
  • MOM Connector Framework (MCF) Web service
The last component is available as an install option on MOM management servers. This is the recommended method for developing connectors and will be the main SDK access method in the next version of MOM. The SDK contains a sample connector (based on MCF) to an XML file emulating a ticketing application. This gives a simple example of how to utilize the MOM APIs.

Using the MOM Connector Framework
The current version of MCF is a Web service with 16 methods (shown in Figure 3). Six of these methods are used most often: Setup, Initialize, GetData, AckData, UpdateAlerts, and Uninitialize. Setup is used to identify the connector in MOM with a unique registration ID. Initialize prepares the Web service for communicating with the connector. GetData retrieves alerts from MOM. AckData is used to acknowledge that alerts from MOM were received. UpdateAlerts updates existing alerts in MOM with information from the external system. And Uninitialize clears most of the settings and prepares for new settings or a complete service stop. You can call these methods from managed code, and using just these six methods to build a full connector that transfers data to and from MOM.
Figure 3 MCF Web Methods (Close Figure 3)

InsertAlerts
Cleanup
InsertDiscoveryEvents
UpdateAlertsWithHistoryFlag
GetDiscoverySchemaForForwardee
SetupWithResolutionState
AckData
GetKnowledge
GetGlobalConfig
GetData
Uninitialize
AssociateDiscoverySchemaToForwardee
Setup
Initialize
SetBookmark
UpdateAlerts
Figure 4 shows the snippets of code you can use to take advantage of these methods in order to retrieve and update data in MOM. The best practice is to develop connectors as a Windows NT® service. This ensures greater stability and the service runs in the background, polling the MCF Web service at a given interval for new or updated alerts. You can specify any value for the interval that meets your needs. I have successfully tested intervals of as little as 10 seconds in production environments with over 200 agents. This setting depends on the performance of the SQL Server where the OnePoint database resides.
Figure 4 Retrieve and Update Data in MOM (Close Figure 4)

Set up the connector
Dim connector As CompName.ConnectorServiceV2 ‘CompName is the Web reference to MCF Web service (ConnectorServiceV2.wsdl)
Dim registrationid As System.Guid
Dim flag As DataChanges
registrationid = connector.Setup(info, resolutionstate) ‘setup the connector and retrieve its GUID
flag = DataChanges.NewAlerts Or DataChanges.UpdatedAlerts
‘set the flag to get new and updated alerts
connector.Initialize(registrationid, flag) ‘initialize the connector
Retrieve data from MOM
Dim getdataalerts As sendtoSystem.CompName.Data = connector.GetData(registrationid, flag, 100)
Dim newalerts() As sendtoSystem.CompName.Alert = getdataalerts.NewAlerts
Dim newalert As sendtoSystem.CompName.Alert
Dim updatealerts() As sendtoSystem.CompName.Alert = getdataalerts.UpdatedAlerts
Dim updatealert As sendtoSystem.CompName.Alert
Acknowledge data from MOM

For Each newalert In newalerts
Dim ack(1) As Guid
      ack(0) = newalert.AckId
      connector.AckData(registrationid, ack)
Dim comp As String
      comp = newalert.ComputerName.ToString
Update data in MOM
Dim AlertUpdate As New sendtoSystem.CompName.AlertUpdate
Dim AlertUpdateTable(0) As sendtoSystem.CompName.AlertUpdate
MakeUpdate(AlertUpdate)
‘internal procedure to prepare for update (define what fields are updated)
AlertUpdate.CustomField2 = "PENDING_FORWARD_TO_SYSTEM"
 ‘the introduced change
AlertUpdate.AlertId = updatealert.AlertId
AlertUpdateTable(0) = AlertUpdate
connector.UpdateAlerts(registrationid, AlertUpdateTable)
...
This is only a general approach to developing MOM connectors. It is a complex issue that requires detailed planning, consideration of business requirements, and analysis of available access methods (to the connected system).
The complexity involved can vary greatly. Developing your own connector may be a good approach if your requirements dictate a relatively simple design. For a simple connector, you may be able to avoid any complex coding, basing your design on MOM alert rules and management server scripts. These scripts can use the Management Class Libraries as they run locally on the MOM server. Or you may need a custom connector if there are no MOM connectors available for your specific system. If the connector has more functionality, then developing a Windows NT service that calls MOM Connector Framework is the best approach. Otherwise, you may want to check to see if a MOM connector has already been developed for the system in question.

Adding Escalation
You may want to implement some kind of escalation mechanism inside MOM. The easiest way to achieve this is to use MOM alert custom fields and rules. Figure 5 demonstrates how to utilize the WMI classes to check whether alerts may need to be escalated. The following code can be adapted as a script in an alert rule response to mark alerts with given escalation time (through a parameter):
Set objAlert = ScriptContext.Alert
paramEscalation = ScriptContect.Parameters.Get("EscalationThreshold")
objAlert.SetCustomField 4, paramEscalation
Figure 5 Implementing Escalation (Close Figure 5)
Set objWMI = GetObject("winmgmts:\\.\root\mom")’get the alerts from WMI
Set colAlerts = objWMI.ExecQuery("Select * from MSFT_Alert where Severity >=50 and ResolutionState =
    0 and CustomField4 > 0") ‘return alerts matching conditions for escalation
For Each objAlert in colAlerts ‘enumerate through the alerts
If CInt(DateDiff("n",ConvertDateFromUTC(objAlert.TimeRaised),Now)) > CInt(objAlert.CustomField4) Then ‘take action when alert time raised is over the threshold stored in Custom Field number 4
‘Take action accordingly to the requirements for escalation, e.g. run executable file
wshshell.CurrentDirectory = WorkDir
      Result = wshshell.Run(CmdLine, 0, TRUE)
         If Result <> 0 Then
          CreateEvent(CompName) ‘log a MOM event on failure
End If
End If
Next
When an alert remains unattended for a length of time that exceeds the specified escalation time, a particular action can be taken. The administrator can indicate what action to take (fire an external command, send a new alert, change the alert that caused the escalation, or so on). The interval for running the script in Figure 5 depends on the requirements, but it should not be less than five minutes in a large MOM deployment. Many thanks to Brian Wren who has published a management pack that fully implements exactly this escalation mechanism.
The escalation process can be layered with different levels depending on elapsed time. This can be implemented by expanding the solution described here to the next custom fields defining further escalation levels.
The next version of MOM, named System Center Operations Manager 2007, is expected to be released in late 2006. It will natively implement notification escalation mechanisms, with the ability to base escalation on a notion of "alert aging." The administrator will be able to define criteria that are used to generate a notification when an alert "ages" beyond the specified threshold.

Andrzej Lipka is an Infrastructure Consultant in Microsoft Services in Poland. He works in management and operations, specializing in MOM, SMS, and Active Directory. He can be contacted through his blog at blogs.technet.com/alipka or by e-mail at alipka@microsoft.com.


 System Management: Customize SMS Using Local Policies
System Management Jeff Tondt

Customize SMS Using Local Policies
At a Glance:
  • Overriding remote tool settings with local policy
  • Collecting special inventory from targeted clients
  • Advertising to untargeted client machines
  • Configuring local policy using customized MOF files
Download the code for this article: SMS2006_09.exe (155KB)

Have you ever wanted to override SMS site settings for just a few machines? How about sending an advertisement without targeting the client? Or collecting special inventory from just a few machines
while the rest report what the site has set? Or even configuring specific remote control settings for some clients while leaving others based on site settings? You can do it all with Microsoft® Systems Management Server (SMS) 2003 local policies.
Because Agent Policy settings apply on a site-wide basis, it can be useful to configure a custom SMS policy on a local, per-client basis. (Note that you need to be a local administrator to configure a local client policy.) A custom local SMS policy can override either a full policy instance or individual properties of an instance. Local SMS policy settings can be added either by compiling a Managed Object Format (MOF) file or programmatically through Windows® Management Instrumentation (WMI). In this article, I'll cover only the MOF approach. The SMS 2003 SDK version 3.1, available from the SMS downloads page, explains the techniques used in this article.

Remote Tools
Say you have both servers and desktops in a single location. You don't want two SMS sites, but you want to force the SMS 2003 Advanced Client to ask users for permission when remote controlling desktops, even while you automatically control servers. You can accomplish this through a local policy that overrides the site settings.
You can use a MOF file to define a new policy instance. The existing instances of the same class are not overwritten when you compile the new MOF. During the evaluation of the policy, the settings need to be combined. For this process, it's not important whether the policy instance is complete or partial. A complete policy will not be merged with others from other sources, while a partial policy will.
A new policy will not be applied until the Advanced Client has completed a policy evaluation cycle, which is invoked automatically within two minutes after the Advanced Client has retrieved new policy from the management point. Similarly, if local policy is applied to the client, it will not take effect until a policy evaluation cycle has taken place. If this is required sooner than the scheduled policy retrieval, the policy evaluation may be invoked using the Advanced Client Control Panel applet or programmatically using the CPApplet client action for "machine policy retrieval and evaluation cycle". There are many ways to invoke policy evaluation, including the SendSched.vbs script found in the SMS 2003 Toolkit 2.
To see an example, take a look at TypicalMPpolicy.mof in the downloadable code for this article. This MOF file has an instance of the RemoteToolsConfig class as found on a management point. Note that the PermissionRequired property has been set to 1. Each client that uses this management point will, as a site-wide policy setting, have this policy property value applied for PermissionRequired.
Figure 1 shows the full local policy that will be used to override the site-wide policy settings. To invoke the local policy, first save the text in Figure 1 as remote.mof, then run the following command on the machine for which you want to override the site wide settings:
mofcomp.exe remote.mof
Figure 1 Full Local Policy (Close Figure 1)
#pragma namespace("\\\\.\\root\\ccm\\policy\\machine\\requestedconfig")

instance of CCM_RemoteToolsConfig
{
     Type = 1;
     PolicySource = "Local";
     AllowChat = false;
     AllowClientChange = true;
     AllowFileTransfer = false;
     AllowRAUnsolicitedControl = true;
     AllowRAUnsolicitedView = true;
     AllowReboot = false;
     AllowRemoteExecute = false;
     AllowTakeover = true;
     AllowViewConfiguration = true;
     AlwaysVisible = false;
     AudibleSignal = true;
     CompressionType = 0;
     ControlLevel = 0;
     DefaultProtocol = "TCP";
     DisableToolsOnXP = false;
     EnableRA = true;
     EnableTS = true;
     EnforceRAandTSSettings = true;
     IndicatorType = 1;
     ManageRA = true;
     ManageTS = true;
     PermissionRequired = false;
     PermittedViewers = {"DOMAINA\\Administrator","DOMAINA\\joeuser"};
     RemoteToolsEnabled = true;
     UseIDIS = true;
     VisibleSignal = false;
};
Remember this only works on a SMS 2003 Advanced Client. An alternative, more flexible approach is to only override certain settings from the management point. The following text can be used with the same method to compile the MOF:
#pragma namespace(\\\\.\\root\\ccm\\policy\\machine\\requestedconfig)

[CCM_Policy_PartialPolicy(true)]
Instance of CCM_RemoteToolsConfig
{
     PolicySource = "Local";
     Type = 1;
     [ccm_policy_override(TRUE)]
     PermissionRequired = false;
};

Collecting Special Inventory
You might want to collect additional hardware inventory details on just a few clients. Refer to SpecialInventory.mof in the download for this article.
In this configuration, PolicySource set to Local indicates that the policy source for this inventory is the local computer. As the Inventory Agent performs hardware and software inventory, the action identifier InventoryActionID is used to identify the inventory type. In this case a value of 1 indicates a hardware inventory. The remainder of the MOF file expresses the class, namespace, plus various other properties to be collected as part of the inventory.
Just compile the MOF on the SMS 2003 Advanced Clients for which you want to collect additional hardware inventory details. Of course the site SMS_DEF.MOF file must be configured to allow this information to be processed. For more information on configuring SMS_DEF.MOF refer to the SMS 2003 Operations Guide.

Advertise to Untargeted Clients
Why would you want to send advertisements to an untargeted client? Say you have a package you want to make available to users, but you expect they will find it by means other than SMS. For example, you might want to put the package on a commonly used file share. You do want all other SMS services, such as status reporting, to work. Or you might want to force the advertisement to run as part of the logon script as soon as the client is installed. You don't want to wait for the discovery data records (DDR) to flow to the site, the collection to be evaluated, and the policies to be received.
Sending advertisements to untargeted clients is a little more complicated because you need to gather information from an existing advertisement in order to create the local policy with the correct information. Let's go through the steps.
First, you must create an advertisement that targets any client. This does not have to be the clients you want to apply the local policy to. In fact, you could just use a test client so the advertisement will not interfere with operations. To keep things simple, it's a good idea to advertise to a brand new SMS 2003 Advanced Client or to a machine that has never been targeted for an advertisement. If you target such a machine when you set up your example advertisement, the next steps of retrieving the information to make a functional local policy are straightforward. This is because there are no other advertisements to complicate the data retrieval necessary to create the local policy. If you are brave and like matching policy IDs, you can use any machine for setting up the example advertisement. I recommend using the clean machine approach, though, as this technique can get complicated quickly. Be warned.
I like to use Wbemtest.exe to gather the information, but you can also use CIM Studio. Beware of PolicySpy from the Systems Management Server 2003 Toolkit 2, though, as it does not provide all the advertisement instances needed to create a functional local policy. On systems running Windows XP, Wbemtest.exe is usually installed in the %WINDIR%\system32\Wbem folder.
Now let's get the CCM_SoftwareDistribution advertisement instance. Execute Wbemtest.exe and connect to root\ccm\policy\machine\requestedconfig on the test client you advertised previously. Click the Open Class button and open the CCM_SoftwareDistribution class. Click the Instances button and then double-click the CCM_SoftwareDistribution policy instance. As you can see, the policy ID is part advertisement ID and package ID. But if you kept things simple and created just one advertisement, there will be no confusion. Simply click the Show MOF button, highlight the instance text, copy it, and then paste it into Advert.mof.
Your Advert.mof file should look similar to the snippet here. Refer to the Advert.mof file in the downloadable code for the full listing. Of course your example will vary, but having a frame of reference is helpful as it's easy to get lost:
#pragma namespace("\\\\.\\ROOT\\CCM\\Policy\\Machine\\RequestedConfig")

instance of CCM_SoftwareDistribution
{
    ADV_ActiveTime =
        "20060315074200.000000+***";
    ADV_ActiveTimeIsGMT = FALSE;
...
Next, follow the same basic steps, but this time for the CCM_Scheduler_ScheduledMessage class. Again, if you have only one advertisement, you won't have to decode the policy ID to find the one that corresponds to the CCM_SoftwareDistribution you copied in the first step.
Exit all the Wbemtest.exe windows from the previous steps so we have a common place to start. Execute Wbemtest.exe and connect to root\ccm\policy\machine\requestedconfig on the test client you advertised in the preceding section. Click the Open Class button and open the CCM_Scheduler_ScheduledMessage class. Click the Instances button and double-click the instance that has the same Policy Rule ID as the one for the CCM_SoftwareDistribution instance you selected in the previous section. Now simply click the Show MOF button, highlight the instance text, copy the text and paste it into Advert.mof. Your Advert.mof should look similar to the snippet that follows. Again, refer to the full listing of Advert.mof you downloaded. Now we're halfway there—two more classes and we'll be ready to fire it up:
instance of CCM_Scheduler_ScheduledMessage
{
    ActiveMessage = "<?xml version='1.0' ?>
<SoftwareDeploymentMessage MessageType='
Activation'><AdvertisementID>TOP20005
</AdvertisementID><PackageID>TOP00006
</PackageID><ProgramID>TestWMI</ProgramID>
</SoftwareDeploymentMessage>";
    ActiveTime = "20060315074200.000000+***";
...
Again we'll follow essentially the same steps, this time with the CCM_Policy_Rules class. As before, exit all the windows so we have a common starting place. Execute Wbemtest.exe and connect to root\ccm\policy\machine\requestedconfig on the same test client. Click the Open Class button and open the CCM_Policy_Rules class. Click the Instances button and double-click the instance that has the same value for the CCM_Policy_Rules.PolicyID as the value for the CCM_SoftwareDistribution.PolicyID and CCM_Scheduler_ScheduledMessage.PolicyID you selected last time. Click the Show MOF button, highlight the instance text, and copy and paste it to Advert.mof. Be sure to write down the RuleStateID as you'll need it for the next step. Your Advert.mof should look similar to this:
instance of CCM_Policy_Rules
{
    PolicyID = "TOP20005-TOP00006-F6A80ED0";
    PolicyRules = {
instance of CCM_Policy_Rule2
{
...
Our last class is the CCM_Policy_Rule_State class. Once again, exit all windows, execute Wbemtest.exe, and connect to the test client. Click the Open Class button and open the CCM_Policy_Rule_State class. Click the Instances button and double-click the instance that has the same RuleStateID you wrote down in the last section. Click the Show MOF button, highlight the instance text, and copy and paste it to your Advert.mof, which should look similar to this:
instance of CCM_Policy_Rule_State
{
    RuleStateID =
        "{60DE19AE-AE25-48D8-92E8-
        EDE79B3DB258}";
    State = "Active";
};
Now you have all the necessary advertisement instances to create a valid MOF. All you need to do is to run a script to change some key parts, then fire up Mofcomp.exe to instantiate the local policy. Refer to the file SWD_RunAtUntargeted.vbs in the download for this article to get the full listing.
Before executing the script, replace the sourcesite variable with the site code for your site. Also replace the original_schedule variable with the time from the ScheduleString value for the Triggers part within the CCM_Scheduler_ScheduledMessage instance. Then execute SWD_RunAtUntargeted.vbs on the machine you want to have the advertisement run on. This can be any machine with the SMS 2003 Advanced Client installed that has access to the DPs for the site you gathered the information from. The VBScript code creates a file called Changed_AD.MOF in which it has made adjustments to create a valid local policy that executes immediately. You'll notice there is no difference at this point between the client running an advertisement that was targeted from the site server and the local policy you just instantiated. Status messages, reporting, and everything else work the same.

Wrapping Up
There are many powerful local policy techniques that can help customize your SMS 2003 implementation. To remove a local policy, you can either change the MOF definition to set CCM_Policy_Override to FALSE for partial instances or delete the entire instance using the key properties. Deleting the instance will have to be done via Wbemtest.exe or a similar application, or programmatically by using WMI.
Note that local policy-based scripts may not be guaranteed to work or be supported in the next release of SMS, which will be known as System Center Configuration Manager 2007, and may have settings or schema not compatible with local policies.

Jeff Tondt is a Senior Consultant for Microsoft Consulting Services. He is focused in the areas of systems management, automation, and patch management. He is a SMS subject matter expert and can be reached at jeff.tondt@microsoft.com. Special thanks to Mark Seely, SMS Administrator, and Paul Thomsen, Senior SMS Engineer, both with Microsoft; this article is based on their work.


 System Management: Set High Standards: Powerful Tools for Configuration Management
System Management Jeremy Chapman

Set High Standards: Powerful Tools for Configuration Management
At a Glance:
  • Configuration management basics
  • Best Practices Analyzers
  • SMS 2003 Desired Configuration Monitoring
  • Configuration monitoring in practice

Almost half of all unplanned service outages happen because of system configuration mistakes or oversights. With that in mind, several useful tools are available from Microsoft to help you keep
configuration issues under control in environments of all sizes and levels of complexity. These tools provide both the technology and the guidance you'll need to get started managing configuration.
First, it's important to understand the concept of configuration management. Within IT organizations, configuration management is the process of identifying, defining, and documenting the environment, its components, and the relationships between components. Ultimately, you are trying to define a known, standard system state and to maintain that standard state across your environment. Part of this process entails discovering and updating configuration items (CIs) for your systems, as well as tracking and documenting these CIs as they change.
If, for example, you have a known state for a workstation and define the CIs that represent that state within your environment, adding a patch represents a deviation from your defined state. Now imagine there's a tool that informs you of any such deviations. Each patch you install will trigger a number of alerts, telling you those patched workstations are not complying with the previously defined state. These alerts let you document any changes to the defined state, and future checks will therefore reflect the revised state you have documented.
On one hand, this sounds like a lot of additional work just to accommodate planned updates. But there's another benefit: you'll also be warned if a rogue element changes one of your defined CIs. The consequence of not being informed of an unplanned state deviation can result in amounts of work much greater than the effort invested in defining and maintaining CIs. Managing and updating your CIs puts you in control to make sure that only undesirable CIs trigger alerts.
So what goes into a CI? CIs generally consist of configuration attributes such as description, version number, component, relationships, location, and status. In an ideal state, that patch you just authorized and installed would be populated in a CI and all of the CIs would reside in a relational configuration management database.
Most people aren't willing to check configuration items against a spreadsheet or database, despite taking the time and care to define them. Likewise, automating the compliance checking and alerting process has been difficult. Let's say you have 100 configuration attributes per computer, and a skilled tester can check 50 configuration attributes manually in an hour. Now think about a company that has 1,000 servers and 20,000 desktops and imagine the workload required to maintain a desired state and check all these computers on a regular basis. Even if all computers were in the desired state at deployment, there's no practical way to maintain a standard across all 21,000 computers—or even 100 computers—without automation.
How do you define the configuration items and attributes so that a tool can automatically perform a configuration health check and tell you if your environment complies with the predefined standard? A first step was made to help automate configuration monitoring for Windows®-based systems with the release of the first Best Practice Analyzer (BPA). Microsoft published a set of CIs inside the tool to check for compliance against a known installation benchmark. Since then, Microsoft has provided tools to analyze and define CIs for a variety of applications and even customized for specific computing environments.
This article introduces a number of Microsoft tools that help automate parts of the configuration management process. It's a fact that defining CIs can be difficult and time-consuming, yet the reward is having a controlled and auditable state where any unplanned changes in configuration automatically trigger alerts, often before those changes cause a service disruption or create a security risk.

Best Practices Analyzer Tools
In September 2004, Microsoft introduced the first tools to help automate configuration monitoring for Windows-based systems with the release of the Exchange Server BPA tool, which looks at an Exchange Server deployment, compares it to a regularly updated repository of Microsoft configuration best practices, then reports its findings. To use the Exchange Server BPA, download the app, install it, and make sure that .NET Framework 1.1 is installed on the target servers. With proper network access, Exchange Server BPA can even diagnose problems with Active Directory® services. The analyzer works with Microsoft® Exchange Server 2000 and 2003 and will work with mixed-node topologies of Exchange Server 5.5 along with later versions. See the TechNet Magazine article "Tune Up Exchange Server with the Best Practices Analyzer" for more information.
Additional BPA tools are available for Internet Security and Acceleration (ISA) Server 2004 and SQL Server™ 2000. The ISA Server BPA checks configuration data from the ISA Server hierarchy of administration COM objects, Windows Management Instrumentation (WMI) classes, the system registry, files on disk, and DNS settings. The SQL Server BPA helps manage databases by allowing you to verify best practices are in place, specifically with the usage and administration of SQL Server databases and making sure that servers are properly managed and operated.

Desired Configuration Monitoring
Building on the success of the BPA tools, the Systems Management Server (SMS) 2003 Desired Configuration Monitoring (DCM) tool lets you store your identified configuration attributes into a file, which can then be consumed by an application to automate configuration checks and define how non-compliance is reported. In the BPA tools, CIs are predefined and not customizable. Even though this is easier than manually combing through your registries and providers, it can fire off alerts regarding configuration items you actually want, and it won't fire off alerts for any custom attributes your environment may have and want to monitor.
SMS 2003 DCM uses the same logic as the BPA tools, but allows you to uncover the XML configuration files and edit, add, or delete rules using the included authoring tool. (The overall process is shown in Figure 1.) Even though this sounds pretty straightforward, anyone who has taken a look at all the CIs and attributes that contribute to a healthy system will know that this is not a quick task. For that reason, Microsoft created baseline CIs for Exchange, ISA, and Windows servers.
Figure 1 Desired Configuration Monitoring Process
Figure 1 Desired Configuration Monitoring Process
Let's walk through a scenario where monitoring configuration is critical and can be accomplished using the DCM solution. Imagine you have an online business that relies on custom applications and services. Any problem in the configuration of these apps could cause a service disruption and effectively stop all transactions.
Three weeks ago you went through a patch cycle on your servers and during this cycle, the credit card authentication service, which is normally set to start automatically, was set to a manual start and simply left running. This server ran fine for three weeks. Then, during an overnight scheduled maintenance window, an update to a custom application required a reboot. On startup, the credit card authentication service did not start automatically (because of the new manual setting) and credit card transactions weren't able to be processed. How long will it take your IT staff to identify and fix the problem? Depending on the size of the business, hours—or even minutes—of service disruption could account for a huge sum of lost revenue.
With the DCM solution, you would define the credit card authentication service autostart as a configuration attribute (see Figure 2). DCM would have alerted the IT department when the autostart setting was set to manual.
Figure 2 DCM Solution Authoring Tool
Figure 2 DCM Solution Authoring Tool

Your Next Steps
The ISA Server baseline configuration available in the DCM Beta Configuration Manifest Program includes several thousand settings. So along with the DCM solution, I recommend that you examine your organization's current configuration management procedures to get the maximum benefit of the tools. Microsoft has a library of content on Configuration Management in its Microsoft Operations Framework (MOF) guidance. The DCM solution automates just part of these configuration management best practices.
As I'm writing this article, the SMS 2003 DCM solution is in the process of being updated to include new key functionality. The update will include desktop configuration monitoring capability and SQL Server functionality. Plans are to include CIs for both desktops and SQL Server, along with releasing the current DCM beta configuration items for Windows Server®, Exchange Server, and ISA Server.
The update will also include a reduced set of predefined SMS 2003 reports for use without SQL Server Reporting Services. Finally, the user interface will add many new features to ease the creation of configuration items. The new user interface will provide a wizard-based experience for definition of simple rules, rule templates for key configuration attributes, and a table view of simple rules. The sum of these changes promises an improved user experience and reduced time to get up and running with the solution.
For further information about change and configuration management and configuration monitoring, you should look into all the resources highlighted in the "Online Resources" sidebar.
Online Resources
If your company is interested in improving the configuration management process, these resources can help you implement a process suited to your needs.
  • SMS 2003 Desired Configuration Monitoring
  • Microsoft Operations Framework: Changing Quadrant
  • Exchange Server Best Practices Analyzer Tool
  • Best Practices Analyzer Tool for Microsoft SQL Server 2000 1.0
  • ISA Server 2004 Best Practices Analyzer Tool
  • BizTalk Server Best Practices Analyzer

Jeremy Chapman is a Senior Product Manager in the Microsoft Core Infrastructure Solutions team, responsible for Solution Accelerators, Reference Architecture, and Microsoft Operations Framework (MOF) guidance. He has worked as a project and operations consultant spanning the past eight years equally in Europe, Asia, and North America.


 From the Editor:
From the Editor

Around the time you read this, the United States Senate likely will be considering a communications bill that may or may not contain guarantees of something called "net neutrality." If you haven’t heard of this yet, now’s the time to look into it because it’s a matter that could change the very nature of the Internet and the broadband apps and services your company uses online.
The issue is simple. The Internet was created as an entity called ARPANet, and its development was funded by the U.S. federal government. It has since been opened up to commercial interests, but a cornerstone of the magnificent growth of the net has been the idea that all content is treated equally, as packets. When you download a Web page, its packets are transmitted at the same priority as e-mail sent across the same lines. Larger transfers are sent at the same speed as tiny ping requests. Service providers have not had the practical ability to discriminate based upon content type. Providers have been able to improve the performance of their offerings and services by investing in local caching or purchasing dedicated, long-haul backbone transport.
The FCC changed these rules just over a year ago, but we haven’t seen any significant change in service. Now, taking advantage of their newfound regulatory position, some broadband companies are considering ways to fast-track some services—like their own streaming video services—potentially for a fee. If one type of content (or one company’s content) is transmitted more quickly, it is not clear that other providers could get a similar deal at any price. Without a net neutrality law, there would not even be a "no blocking" rule; if a service provider wanted to block content from a company like Microsoft, or Google, or yours, it could. Network operators claim that it costs them billions to provide service to large corporations. That’s true, and it’s also true that providers have always paid for their service. As it is, no provider gets a free ride.
What’s at stake if Congress doesn’t pass an "Internet consumer bill of rights?" There will be no legal safeguards to ensure that providers and consumers can continue to enjoy full Internet freedom. If you wanted to use Yahoo Music to download songs, but your ISP made its own ISPSongs in competition, you could inexplicably find that it has become more frustrating to get to Yahoo Music than the new alternative. On the business end, you could see VoIP, sharing of large files, or high-quality video streaming forced onto a "premium tier" of services. We’ve seen signs of this already, where some providers have blocked e-mail sent to subscribers that mentions competitive sites, unions, or whistle-blowing groups.
There are many potential permutations to be concerned about if existing legislation is not modified to improve net neutrality provisions. You can probably imagine some that would directly affect your business. If you have not yet familiarized yourself with the issues relating to net neutrality, don’t put it off any longer. At worst, you’ll be the most knowledgeable person in your office (as if you weren’t already just by reading TechNet Magazine), and at best you can make your views known to your elected representatives.
I’ll stop short of telling you which side we’re coming down on regarding the net issue. (You can probably figure it out.) For more information on Internet neutrality, Microsoft and other companies have created guides to the issue. You can either use your favorite search engine, or go to sites like Microsoft's Freedom to Innovate or Advisory Committee to the Congressional Internet Caucus to find out more.
—J.T.

Thank you to the following Microsoft technical experts: Jon Avner, Tom Daemen, Adam Gordon, George Holman, Jesper Johansson, Robbie McAlpine, Geoff Morris, Michael Murgolo, John Orefice, Greg Stemp, and Carol Troup.


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

Automate Tasks
ManageEngine RobolQ 2
manageengine.adventnet.com
Automation of repetitive tasks can be a life-saver for the IT professional. I have seen far too many instances of an Ops crew being bogged down in a never-ending cycle of simple but time-consuming daily tasks. This kind of activity not only sucks the life from the team, but also has the potential to put the staff in a deadly game of reactive catch-up. Automating repetitive tasks gives the team time to think and plan and helps keep the operational staff working in a proactive mode, saving both the spirit of the team and perhaps the livelihood of the company. One tool that can help you automate those pesky, life-sucking tasks is AdventNet’s ManageEngine RoboIQ 2.
Administration of the application is Web-based and uses the integrated Web server and database supplied with the installer. Automation tasks are grouped into workflows, which are sequences of event triggers with subsequent actions. Designing automation workflows is simple and can be accomplished via a wizard-type interface or through a drag-and-drop Web interface within the Administration Web site.
Triggers for actions can be configured as manual tasks, scheduler-based tasks, or monitor/trigger tasks. Manual and scheduler tasks are user initiated and time based, respectively, whereas the monitor/trigger tasks watch thresholds to determine the course of action to take. RoboIQ allows you to create service, process, event log, Perf Monitor, Windows® Management Instrumentation (WMI) notification, ping, port, or URL system monitor tasks to automate. You can also create file, folder, or disk space-based file system monitor/trigger workflow tasks.
Management of automated tasks can be handled through one central management workstation and from there, the application allows you to remotely install (assuming you have the correct permissions, of course) the RoboIQ service on different hosts in your environment. The Web administration interface will show you all the viewable machines on your network segment and can be filtered to show all those with the RoboIQ service installed or those that do not have the service installed. The application can log all workflow events and can send workflow event e-mails for notification. RoboIQ also supports environments with multiple domains and has support for multiple administrative users.
ManageEngine RoboIQ 2 is available as a free edition that will allow you to automate a single host in a network with all the functionality of the professional edition, but with only two defined workflows.
Price: Professional version starts at $295 a year for one machine.

Manage Virtual Disks
Parallels Compressor
www.parallels.com/en/products/compressor
Server virtualization is becoming part of everyday life for the IT professional. More and more companies are realizing the potential value and potential cost savings of virtualization—from reducing power consumption to creating a diverse QA environment for your software test cycle on a single machine. Toward that end, Parallels Inc. has added a cost-effective tool for managing the virtual disks of your virtual servers to their product portfolio. Parallels Compressor helps you both improve virtual machine performance and manage virtual disk utilization on both the host and the guest operating systems.
The application supports VMWare, Microsoft® Virtual Server, and Virtual PC, and Parallels’ own Workstation virtual disk formats. It can reduce the amount of physical space taken up by your virtual disk and compact the data to help improve disk performance. Compressor also supports all flavors of Windows as your host operating system (in addition to Mac OS X and numerous Linux distributions).
Price: $49.99 for Workstation version, $179 for Server version.

Audit and Analyze Systems
Network Asset Tracker
www.misutilities.com/network-asset-tracker
The WMI interface can be an incredibly powerful gateway to all of the machines on your network. MIS Utilities’ Network Asset Tracker 2.12 utilizes WMI via the DCOM RPC on your computers running Windows to gather detailed system information.
Of course, using WMI via DCOM RPC requires that you are using a Windows account that has the privilege to access the remote machine via RPC, and also that the remote host isn’t blocking RPC via a host-based firewall, which is not always an option for corporate infrastructures. Permission requirements aside, Network Asset Tracker is a quick, easy, and relatively low-cost way of finding out the details of the internals of the boxes on your network for a corporate audit or inventory status report.
The application scans your network segment for machines and adds their information to its XML data repository. It allows you to search for computers in four different ways: across the entire current network segment, by an IP address range, through manual entry of computer names, and by importing text files of computer names. Once you have added your machines to the inventory, you can reach out and gather information individually or for the entire group of machines.
Once you have retrieved the remote system information, the application reports the results as three categories of detailed information: system, software, and processes. The System tab shows you everything from IP addresses to installed service packs to individual memory module types for each system. You can even see current shares, NIC MAC addresses, and a list of all the system hotfixes that have been applied to the machine. This is a great way to see if your patch management solution actually reached out and applied the correct patch sequence to your hosts.
The Software tab shows you every application installed on the system that has an Add/Remove Programs entry, including any Windows patches, hotfixes, or security updates that have been applied (equivalent to clicking the checkbox on your Windows XP Add/Remove Programs list to "Show updates"). Finally, the Processes tab shows you all the currently running processes on the remote machine, which could be a great way to see who’s running what if you are charged with keeping track of such things for your company.
All things considered, MIS Utilities’ Network Asset Tracker is a simple, non-agent-based tool that can be a great help to smaller companies without fortress-like security policies in place.
Price: Starts at $99 for 10 nodes up to $999 for a site license.

Keep Track of Your Time
Working Time Tracker
www.allnetic.com/working-time-tracker
Have you ever wondered how long you really spend on a specific task or project? Whether you are a contractor or a full-time employee, it’s always a good idea to know how much time you spend on various projects and elements of your job. AllNetic Working Time Tracker 2.1 provides a simple way to keep track of that time.
Working Time Tracker has a nice automatic notification feature that monitors your activity and prompts you if you forget to start or stop tracking your time for a project. The application can run minimized in the system tray. Hovering the mouse over the icon gives you a time summary for the current project and task, and also allows you to stop, start, or add a comment to the current task.
The app also includes a customizable, template-based report builder. With this, you can create time sheets or invoice summaries of time spent on a project or task.
Price: $29.95 (direct) for a single license. Volume discounts are available.

Monitor Connections to Your Machine
SessionsMonitor
http://www.skyward-soft.com
Perhaps it is just me, but a certain level of security paranoia comes with being an IT pro. OK, it’s not just me. Every IT professional should be concerned about the security of his systems. The more rights and privileges you have in your environment, the more concerned you should be with protecting the information you have access to. In that regard, if you are worried about who is connecting to the shares on your system, Skyward-Soft has a simple program to give you pop-up notification of when a user connects to a share on your machine.
SessionsMonitor runs in your system tray and shows you who is connected and what they are trying to access on your system. The application allows you to kill sessions and will log all the connection activity on the monitored system. In addition to pop-up notification, you can configure SessionMonitor to send e-mail notifications and generate HTML reports of user activity.
Price: $20.

Book Review
SharePoint 2003 Advanced Concepts
www.awprofessional.com
If you have moved beyond installation of SharePoint® Portal Server and Windows SharePoint Services and are looking to take your document management and portal sites to the next level, SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations (Addison-Wesley Professional, 2006) may give you the insight you need to customize your application to suit your business goals. The book is definitely not the be-all and end-all of SharePoint references, nor is it meant to be. The authors, Jason Nadrowski and Stacy Draper, demonstrate the different components of the inner workings of SharePoint Portal Server and Windows SharePoint Services without getting bogged down in line-by-line details. The 240-plus page book is split into five chapters.
The first, Custom Templates, covers the two general types of templates available to those customizing their SharePoint experience: custom site templates and custom list templates. This brief chapter, gives a basic overview of creation of a custom template and the different parts involved in the task.
The second chapter, Site Definitions, gives a more in-depth view into creating custom site definition templates with examples of how to create and customize the different components. For example, the book shows you how to insert your own custom JavaScript file into all the pages in a site definition, and provides such useful tips as how to specify the site’s default document using the ONET.XML DocumentTemplates definition.
The book then covers the architecture behind and creation of list definitions and the SCHEMA.XML element declarations in the third chapter. Here, the book also shows you how to hook into SharePoint library events with custom code and event sinks.
In Chapter 4, Customizing and Implementing Property Types, the book discusses the 10 different property types that can be created for a list and then shows you how to create custom property types. Another great tidbit for all IT professionals shows up in this chapter: make a copy of the defaults and change the copy instead of messing with the native components that ship with SharePoint.
Finally, in Chapter 5, the book covers global customizations including themes, creating online help, and customizing the automated e-mail functionality inherent in the application. In short, this book won’t be your only reference to SharePoint, but it will give you a good place to start in your quest to satisfy the ever-hungry business consumer in your organization.
Price: $39.99.

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


 Utility Spotlight: Access-Based Enumeration
Utility Spotlight
Access-Based Enumeration
James D. Silliman

As a systems administrator, you've probably had users complain that they can't access certain folders they see in Windows® Explorer. The cause is often simple: the user doesn't have permission to open those resources. That's probably as it should be, but the result is often a frustrated user.
This is a problem that shouldn't exist—you should be able to hide shares the user doesn't have permission to access. Since the release of an add-in called Access-Based Enumeration (ABE) for Windows Server® 2003 (SP1), you can do just that.
ABE also provides better security by preventing users from navigating folders that might contain confidential information and provides increased productivity by directing users to the information they need and filtering out what's irrelevant. Plus you'll receive fewer support calls when users can't try to access files for which they don't have permissions.

How ABE Works
How does ABE perform its magic? Every file share has flags that control its visibility. Windows Server 2003 SP1 includes a new flag called ENFORCE_NAMESPACE_ACCESS, located within the SHARE_INFO_1005 flag. When the flag is set, users see files and folders under a share only if they have proper NTFS rights. (By the way, this process is completely independent of and different from the Hidden File attribute.)
The installation of ABE is straightforward. After downloading and launching the ABEUI.msi file on the target machine running Windows Server 2003 SP1, you'll be presented with a dialog that lets you choose to enable Windows Server 2003 Access-based Enumeration either on all existing shared folders on this computer or manually on individual shared folders. Enabling ABE on individual shared folders is the default during installation. If you choose the default route you'll have to access the server console and enable individual shares one by one. To do so, after the installation completes, navigate to the server shares where filtering is desired. You'll notice a new tab has been added to the properties dialog of a shared folder in Windows Explorer (see Figure 1). You can choose the global or individual ABE setting here and it will be applied to the folder in question.
Figure 1 Choosing ABE Settings
Figure 1 Choosing ABE Settings
It would be a good idea to test the server-wide, global setting in a lab environment first, or after hours. At a minimum, make sure all your data is backed up before you start. However, enabling ABE on one network share is really simple.
If you want to enable ABE through Group Policy so you can manage it globally on many servers at once, there are a number of third-party extensions that enable this functionality.
There are three different versions of ABE, for the x86, x64, and ia64 platforms. You can choose either a graphical or command-line interface, plus there is a Windows API for customizing it further. Downloads for all versions of ABE are available at the Microsoft® Download URL that I mentioned earlier. For detailed information on ABE, read abewhitepaper.doc, which is included with the download.

James D. Silliman, a Senior Systems Engineer at DirectApps, specializes in terminal servers deployments. DirectApps architects .NET solutions for small to medium businesses, and is an Application Service Provider. He holds an MA from Colorado University. All he really needs to know about PCs he learned from Erector sets. You can reach him at jsilliman@ieee.org.


 SQL Q&amp;A: Predicates, Stored Procedures, and More
SQL Q+A
Predicates, Stored Procedures, and More
Edited by Nancy Michell

The Order of Your Predicates
Q I'm having a problem with SQL Server 2000. I am seeing the optimizer reorder the predicates in a query in a random way. Can you tell me what's happening?
A Predicates are indeed moved around and reordered by the query optimizer for many reasons. One typical example would be:
SELECT x FROM t1 JOIN t2 ON t1.p = t2.f
WHERE t1.v = 5 AND t2.u = 10
Depending on various considerations (such as index usage), it is probable that the predicates on each table will be evaluated while the table is scanned before the join. So the order of evaluation of these predicates is not even defined; they might well be evaluated concurrently in different threads.

Running Two Versions of SQL Server
Q Can I run both SQL Server™ 2005 and SQL Server 2000 on the same server? Will there be any major performance degradation when using both versions?

A SQL Server 2005 and SQL Server 2000 are supported side by side. Be sure that SQL Server 2000 is installed prior to installing SQL Server 2005. This will insure that if you were to uninstall one, the other won't break. As for performance, it is possible that if both versions are being used simultaneously and are competing for resources such as disk and CPU, then you could see some performance degradation. But there are things you can do to minimize contention for memory and disk resources. You can set a fixed upper limit on memory usage for each instance. For disk usage, you can configure the data files on separate spindles, if available. This is assuming, of course, that you are planning to run both instances concurrently on an ongoing basis.
You could also use CPU affinity to assign a given collection of processors to a SQL Server instance, but that's not the best solution. While taking this route allows you to guarantee a certain amount of CPU resource to an instance, it also prevents any single instance from fully utilizing all processors on the box, so you'll never get full use of your hardware.
You should read "SQL Server Consolidation on the 64-Bit Platform". It contains sections on one versus multiple instances, CPU affinity, and Windows® System Resource Manager (WSRM). All of these topics are relevant whenever you consider running more than one SQL Server instance on a box.

Restarting SQL Server
Q I no longer want to restart SQL Server every day. Will I have memory problems if I don't?

A The real question here is why you feel you need to restart every day. The erroneous belief that SQL Server has memory leaks and thus must be restarted frequently is still rampant out in the IT world. But leaks really only happen when you run applications on top of SQL Server that don't follow best practices. Anyway, short of running applications that leak, SQL Server just doesn't need to be restarted on a regular basis.
When you do restart often, you increase your chances of hardware failure (since most problems strike on startup). At the very least, you cause unnecessary downtime and are cycling through error logs more quickly, destroying forensic logging information, and reducing an engineer's ability to troubleshoot a real problem.

Executing Stored Procedures
Q I have noticed that at times when there is a heavy load on my server, some stored procedures' execution plans go awry. One of the first things I check when I notice timeouts is whether statistics are current for tables accessed by the stored procedure that times out.
I have also noticed that although a table may have exceeded the threshold that causes auto statistics to update (20 percent of the rows plus 500 have changed), the update wasn't done and therefore I had to do it manually to resolve these timeouts. Could it be that SQL Server did not update the statistics because the server was too busy at the time?
I'm using SQL Server 2000 and the database options for auto statistics update/create are turned on. The database is around 60GB in size and some of the tables involved have roughly 30 million rows.
If I know which stored procedure inserts data into these tables, would it be acceptable to include "update statistics <table name>" in that stored procedure after I insert the rows? When I run the statistics update manually it takes one to two seconds.

A Auto-updating of statistics is not throttled (auto-create is, however). But there are still plenty of reasons why an auto-update might fail. In a heavy load scenario it is most likely that the auto-update can't acquire the required locks. Then it would fail because auto-update never waits for locks; instead it fails immediately if it doesn't get the locks it needs.
If you know the statistics entries you want to refresh and if the overhead of one to two seconds is acceptable, there is nothing wrong with a manual statistics refresh inside a stored procedure. However, the syntax you mentioned will refresh all statistics defined on this table, which might be prohibitively expensive.
Also note that you cannot execute a manual statistics refresh inside an active user transaction. This will fail with error 226: command not allowed within multi-statement transaction.
The auto stats trace event only logs successful auto-updates, but trace flag 8721 generates a bit more information. You get an entry in the error log for any update stats attempted (not just the successes). But auto-update stats is set oriented. The trace output will tell you how many stats entries on a table were refreshed (x >= 0), but it doesn't tell you how many and which ones failed. If the number is 0, you know something failed, but you don't know how many or which ones.

Why Defragment?
Q I have a production database on disks that are badly fragmented, showing lots of red when graphed. What is the procedure for defragmentation? Right now, the performance counter shows the average disk queue length is 50, with a maximum of 140. The database was configured for autogrow at 10 percent. Is that why this is happening?
Also, how do I determine whether the disks are having performance problems? Right now, I consider the performance counter reading average disk queue length of 50 a hint about what is going on.
Finally, I have heard that fragmentation has less of a performance impact on a Storage Area Network (SAN) than on a physical disk. Is that correct?

A The disk defragmenter shows red for all the space occupied by any file in more than one fragment. A 300GB file in two fragments will create a whole lot of red, but that is completely unrelated to performance.
First, you should dig a little deeper into the amount of fragmentation and its impact on performance. Is this drive used only for this database or is it used for other services as well? If it is just this database, you should be wondering why it's so highly fragmented. If it's used for other things such as files, logs, other databases, and autogrow, it would make sense that it is fragmented at the physical level (see Defrag Best Practices Whitepaper).
If you're using average disk queue as a measure of performance, it could be misleading—it should be a maximum of between 2 and 5 per physical spindle, making up the Logical Unit Number (LUN) and assuming dedicated disks to the LUN. This number might also be tricky as you are not looking at average write queue or average read queue to see where you are experiencing problems.
Autogrow is bad when databases are small and they have a lot of potential growth. This is why you should make your best attempt to size databases properly up front. Then, if you accept the 10 percent default autogrow, the database will take a more appropriate share of disk space.
The fragmentation on a SAN may or may not matter. Some SANs are better at moving sectors around to optimize file access, but fragmentation is fragmentation. If more than one database and their associated files live on this LUN, you really should have thought about things like this prior to implementation. Often disks are configured poorly from the beginning, creating problems likes this.

Separating Your Drives
Q Is it a recommended practice to use a separate disk drive for tempdb for SQL Server? If so, why should it be separate from the data drive, log drive, or SQL drive?

A If you're referring only to logical drive separation, then the benefit really comes from the ability to move these components around easily to different physical locations moving forward.
TempDB is a shared resource on the SQL Server instance; placing it on the same spindles containing data files means database users must endure the I/O resource consumption overhead associated with all SQL Server workspace activity (hash joins, cursors, and so on). Placing them on separate physical spindles provides higher throughput because the media is dedicated to serving I/O requests from the database only instead of dealing with both database activity and all TempDB operations.
This case is even more evident with log files that have a different access pattern (sequential versus random); placing log files with data files means there could be I/O stalls writing to the logs while the actuator positions the arm and head on the spindle over the appropriate section depending whether it is performing database activity or log activity (in other words, it'll be bouncing around a lot). You want to avoid any I/O stalling during writes to logs, since a transaction will not commit until the data is flushed to stable media. (See "I/O Basics" for more information. For the benefits of designating a separate disk drive for tempdb, see "Optimizing tempdb Performance".

Monitoring SQL Server Health
Q I need best practices for SQL Server health monitoring, such as the recommended performance counters, the best way to run trace/profile with minimum impact on SQL Server performance, and so forth. Can you point me in the right direction?

A The whitepaper "Troubleshooting Performance Problems in SQL Server 2005" references many of the performance counters you'll want to monitor and, in some cases, provides threshold information for the counter value that indicates a problem (see "Troubleshooting Performance Problems in SQL Server 2005" and "Tips for Using SQL Server Performance Monitor Counters"). The key to running traces in the most efficient manner is to run the traces locally on the machine running SQL Server and pipe the output to a local file. See SQL Server Books Online for details that describe exactly how to do this.
In addition to capturing and analyzing performance counters and profiler information you may want to look into identifying where the engine is spending its time waiting, which tells you if you are I/O constrained, CPU constrained, memory constrained, and so on. For more on this see "How do you measure CPU pressure?".
You should also consider implementing Microsoft® Operations Manager (MOM) 2005 as a part of your SQL Server 2005 monitoring plans. The SQL Server 2005 Management Pack is quite useful. Even without it you can get a good understanding of what's going on with your servers just by using the MOM operator console and warehouse and associated reports that expose counters like CPU, Memory, Disk Queuing, and so on.

Stored Procedure Performance
Q I have a server that is running SQL Server 2005. A stored procedure in one of the databases on this server runs very slowly when executed through managed code (20+ second execution times). When the stored procedure is run in Query Analyzer, however, it's very fast (one second or less). What's even stranger is that if I open the stored procedure and make a small modification to it, the stored procedure will run fast through my managed code again. Eventually however, it reverts back to being slow again. I've determined that it appears SQL Server is choosing a different plan for the sproc in Query Analyzer because SET ARITHABORT is on by default and in my managed code it's set to off.
What I'm trying to determine is why SQL Server is getting confused about the stored procedure's execution plan. That's why changing it (even by adding a dummy return value) will suddenly cause it to speed up again. What I can do to ensure that it maintains a fast execution plan? How does SQL Server choose an execution plan?

A From what you're describing, the procedure has most likely hit upon a poor execution plan and retained it going forward. When SQL Server has an execution plan for a query, it will retain that plan until it's dropped from the cache. The procedure can be dropped from the cache for many reasons including:
  • Aging
  • Altering or Drop/Creating the stored procedure
  • Issuing a sp_recompile command on the stored procedure
When you change a single line of code in the stored procedure you're causing the procedure to recompile. The next time you execute the procedure, it has a better execution plan than it had before you caused the recompile because the new plan is based on the parameters you just provided.
If you were to go into Query Analyzer and choose "Include actual execution plan" when it was performing slowly, and then you opened another window, recompiled the procedure, and executed it again, you would most likely see two different execution plans. The new execution plan is optimal for what you're doing now, but the original execution plan was probably optimal for previous executions where the parameters were significantly different.
To learn more about optimized execution plans take a look at this SQL Server team blog entry.

Updating Your Database Servers
Q I have more than 20 database servers. Most update operations occur on an online transaction processing (OLTP) database, then propagate to other databases using transactional replication. I am thinking about replacing transactional replication with a distributed transaction and doing the update all at once. How will this affect performance?

A This would be a very bad idea from a performance perspective. You need to ask yourself whether you have a real, legitimate business need to have the updates performed in an all-or-nothing fashion on all of your databases at the same time. In other words, can you justify the use of a distributed transaction?
You should really consider using SQL Service Broker. If you need transaction-based, ordered delivery, that might be a much better approach.

Edited by Nancy Michell


 Post Mortem: Self-Service Identity and Access Management
Post Mortem
Self-Service Identity and Access Management
Microsoft IT Showcase and Lana Chin

The Project
Microsoft IT recently released the Easy ID service. This is a fully automated, self-service identity and access management solution that gives each employee the ability to create and use a personalized, easy-to-remember e-mail address that is based on employee name information in the human resources system. Although Easy ID is an internal service that was developed for Microsoft employees, it is a compelling example of a self-service solution that can be implemented in different environments to simplify identity and access management.

Challenges
  • The solution had to be a fully automated and easy to use solution that would give each employee—that's more than 60,000 users—the ability to create a personalized e-mail address.
  • The new e-mail address would have to work in addition to the employee's original alias-based e-mail address, without modifying its functionality.
  • Some level of control had to be maintained over certain criteria in order to ensure integrity and consistency of identity information. This meant we had to integrate the solution with the authoritative source for employee identity information: the SAP HR module.
  • The solution had to offer a flexible address schema so users could create addresses that adhered to the naming preferences in different regions and groups across the enterprise. But, at the same time, the solution had to enforce compliance with account naming standards.

The Plan
The solution was built on Microsoft® Identity Integration Server (MIIS) 2003 Service Pack 1 (SP1). It uses the MIIS enterprise resource planning (ERP) management agent to integrate HR information from the SAP HR module. The MIIS ERP management agent provides a continuous link between HR systems (such as the SAP HR module) and IT systems (such as Active Directory®). This allows identity information to flow directly between systems.
Early on in the project, a pilot program was carried out with a small group of users. After development and testing was completed, Easy ID was deployed to executives. This was followed by a global deployment to all employees in the six Active Directory forests that Microsoft IT manages.

The Players
The Identity Management (IdM) team within Microsoft IT collaborated with the cross-IT (XIT) team and other internal teams to deliver Easy ID. The IdM team, as business owner, compiled the business requirements. They identified the name-related attributes that need to be imported from SAP, established the business rules that govern how Easy ID integrates identity information from multiple identity stores, and established how Easy ID manages e-mail addresses. The XIT team took care of design, development, testing, and deployment of all Easy ID components except the MIIS ERP management agent. The XIT team also worked with the Messaging team to substantiate messaging-related aspects of Easy ID.
The MIIS product group partnered with an independent software vendor to drive development of the MIIS ERP management agent, in collaboration with the IdM, XIT, and Enterprise Application (EAS) teams. (The MIIS ERP management agent is currently in prerelease and will be available as an MIIS 2003 product offering.)

Background
Microsoft e-mail addresses are formatted as alias@microsoft.com. The alias matches the user logon name that was configured in Active Directory when the account was first created in the account provisioning system. The user logon name, which has to be unique across all Active Directory and Microsoft Exchange Server accounts, is limited to eight characters to maintain compatibility with certain internal business systems.
Due to these constraints, the way a logon name and e-mail alias is determined does not follow a standard format. The e-mail alias is based on substrings of a user's first and last name, but the substrings are not based on any consistent pattern. For example, the e-mail alias can be made up of the first letter of the first name and a substring of the last name, a substring of the first name and the first letter of the last name, or substrings of both the first and last names.
As a result, Microsoft e-mail addresses are sometimes unintuitive and hard to remember. This lack of consistency creates a business problem that is most evident when it comes to communicating with external customers and partners. Before rolling out Easy ID, external people who wanted to send a message to a Microsoft employee had to have explicit knowledge of that employee's alias. And even when an employee did give her e-mail address to an external contact, it was easily forgotten. Thus, a common request from employees has been for more intuitive e-mail addresses. Easy ID now allows each user to create a more predictable and more memorable e-mail address.
(In addition, a system built on alias-based e-mail addresses creates a potential security risk when each user's logon name—one half of the user's network credentials—is exposed to non-employees.)

Using Easy ID
Easy ID presents employees with an internal, self-service Web site that allows them to quickly and easily create a new, more intuitive e-mail address. Easy ID e-mail addresses are formatted as EasyIDAlias@microsoft.com, where EasyIDAlias can be a maximum of 26 characters based on a combination of the following name attributes: first name, last name, preferred first name, and middle initial.
The address may also include a differentiator. This is text that appears in parenthesis at the end of certain user names in the Global Address List (GAL). It is used to tell the difference between two or more employees who have the same name. A common differentiator is the business unit or group that a user belongs to. For example, a member of the XIT team might use (XIT) as a differentiator in his Easy ID address.
Format, consistency, uniqueness, and accuracy are enforced by a set of business rules that reflect account naming standards and business requirements. To accommodate differences in regional naming preferences and to provide alternative e-mail address options to employees who have the same or similar names, 120 different attribute combinations are available. The address must contain at least two of the attributes, not including the differentiator. Some examples include FirstName.LastName, LastName.FirstName, PreferredFirstName.MiddleInitial.LastName, and LastName.PreferredFirstName.Differentiator.
Easy ID e-mail addresses are available on a first-come, first-served basis. To create an Easy ID e-mail address, an employee can either pick one from a list of recommended e-mail addresses that are automatically generated by Easy ID, or he can build his own based on the list of available attributes (see Figure 1). Addresses that are already taken (by another employee with a similar name) or reserved for administrative purposes are simply not available.
Figure 1 Easy ID User Interface
Figure 1 Easy ID User Interface
It takes only about five minutes to configure an Easy ID e-mail address. After that, the address is ready to use within six hours and visible in the GAL within 24 hours. And if necessary, an employee can return to the site to update or remove his existing Easy ID e-mail address.
The two e-mail addresses—the original alias-based address and the new Easy ID address—work together to send and receive e-mail messages. Messages that are sent to either of these e-mail addresses are delivered to the same mailbox the user has always used. When an employee sends an e-mail message—either to an external or internal recipient—that message is sent from the employee's Easy ID e-mail address. Note that when the recipient is internal, Microsoft Outlook® shows the display name of the employee (not the Easy ID e-mail address) as the sender.

Solution Architecture
Core components of Easy ID include the self-service Web site, the Easy ID application database, management agents, and custom business logic. The self-service Web site sits on top of the Easy ID application database and acts as the front-end user interface. The application connects to SAP through the MIIS ERP management agent and imports the name-related attributes directly from SAP into the metaverse (the MIIS 2003 database). Identity information that's been aggregated from all connected data sources is stored in a Microsoft SQL Server™ database, providing a single, global, integrated view of all objects. From the metaverse, the name-related attributes are pushed to the Easy ID application database (also a SQL Server database). This database, which acts as the back end for the self-service Web site, stores attributes and Easy ID e-mail addresses and also contains a subset of information from the metaverse. SAP, the Easy ID application database, and Active Directory are all connected data sources with identity information that is integrated with MIIS 2003.
When an employee visits the self-service Web site and creates an Easy ID e-mail address, the following events take place:
  • The Easy ID application database updates the employee's user record to include the Easy ID e-mail address.
  • MIIS 2003 detects this change and updates the corresponding user record in the metaverse.
  • MIIS 2003 then modifies the user account attributes of the employee in Active Directory. In the proxyAddresses attribute, the Easy ID e-mail address becomes the primary SMTP address and the alias-based e-mail address becomes the secondary SMTP proxy address. And the Automatically update e-mail address based on recipient policy option is turned off to ensure the primary SMTP proxy address is not overridden.
  • From Active Directory, the user account attributes are replicated to Exchange Server.
That's about all there is to the process. The employee can send and receive e-mail messages using the new e-mail address, as well as continue to receive messages sent to the alias-based address. Figure 2 gives an overview of the data flow.
Figure 2 Flow of Data in the Easy ID Solution
Figure 2 Flow of Data in the Easy ID Solution
MIIS 2003 uses management agents and synchronization rules to control attribute flow between the connected data sources and the metaverse. To implement the business rules that direct attribute flow, the XIT team extended the management agents using rules extensions that store custom business logic. The rules extensions are implemented within a Microsoft .NET Framework assembly that is saved as a DLL file. The XIT team used Microsoft Visual C#® .NET 2003 and the Microsoft Visual Studio® .NET 2003 development system to build these rules extensions. Figure 3 shows the basic architecture of Easy ID.
Figure 3 Easy ID Architecture
Figure 3 Easy ID Architecture
The XIT team deployed the MIIS component of Easy ID on a server running MIIS 2003 Enterprise Edition SP1, SQL Server 2000, and Windows Server® 2003 Enterprise Edition. The team developed the self-service Web site, which hosts the business rules that enforce how Easy ID manages e-mail addresses, as an ASP.NET Web application. This app was deployed on a separate server running IIS version 6.0 and Windows Server 2003 Enterprise Edition.
Easy ID was built on top of an earlier deployment of another MIIS 2003–based identity and access management solution, AutoConsistency Manager. Using MIIS 2003 as a platform for developing custom functionality, the XIT team extended AutoConsistency Manager to accommodate Easy ID components on the same instance of MIIS 2003 on which AutoConsistency Manager was deployed. For more information about AutoConsistency Manager, see the IT Showcase technical case study, "Ensuring Identity Consistency at Microsoft".

Observations and Best Practices
The IdM and XIT teams embraced certain best practices and made some important observations during the course of this project. These points may be useful to others implementing a similar self-service identity and access management solution.
The phase of the project that took the most time was establishing the set of business rules to determine how Easy ID would manage e-mail addresses. This task involved identifying the attributes that would be used in the new addresses, developing naming standards, determining appropriate attribute combinations, recognizing regional naming preferences, and deciding on access-related characteristics. The IdM team was careful not to rush through this phase. They made it a priority to thoroughly understand and validate each business requirement and rule.
Best Practice: Making sure that business rules are solid and well defined is imperative from a technology and usability perspective, as well as for the purposes of user education.
The XIT team implemented a pilot program that ran in parallel to the design phase. They rounded up a group of employees (based on name, business group, and geographic location) who volunteered to participate. To mimic Easy ID e-mail addresses, the XIT team manually changed the user account attributes of the employees in Active Directory. This pilot program was critical to the success of the project because it enabled the XIT team to identify, investigate, and better understand the impact to downstream line-of-business (LOB) applications. As it turned out, some interoperability issues were uncovered and several LOB applications had to be recoded or reconfigured. Additionally, based on information discovered during the pilot program, the XIT team was able to fine-tune the design of Easy ID before starting development.
Best Practice: By implementing a pilot program early in a project, you can help make sure that changes are incorporated in a timely manner and also help reduce development costs by discovering issues and addressing them early on, rather than discovering them later in the project and having to redo work.
The IdM team discovered that it is important to set expectations and make sure that instructions to users are clear and concise. They noticed that many users assumed that the alias in an e-mail address would always match the user logon name. To drive a cultural shift, the team found it necessary to promote user education and build awareness. This helped employees understand what an Easy ID e-mail address is, what it's for, how it works, and how it affects the way they communicate.
Best Practice: A self-service solution such as Easy ID enables employees to manage their own information. However, employees must be informed and ready to take on such a responsibility.

Wrap Up
Easy ID is an opt-in or opt-out service. Employees decide for themselves whether they want to sign up for an Easy ID e-mail address. Each employee who opts in can customize her own e-mail identity by choosing the combination of attributes that works best for her.
Since its release in September 2005, Easy ID has been very popular. More than 6,500 employees signed up for an Easy ID e-mail address during the first 24 hours of its availability. Currently, more than 20,000 employees at Microsoft use an Easy ID e-mail address for external mail.
Microsoft IT has seen multiple benefits resulting from the Easy ID service. The most significant benefits include easier communication with external customers and partners, increased security, and a reusable platform that can be used for future development of service automation and self-service functionality. In fact, Microsoft IT already has plans for a future project that will make use of this reusable platform. Microsoft IT is working on an approach to use the platform in conjunction with the MIIS ERP management agent (which provides the ability to automate access to HR information) to further streamline identity and access management for the company. The goal is to replace the current account provisioning system (which relies on manual processes) with a fully automated, end-to-end account provisioning system that has self-service management features.
Online Resources
To read more about Easy ID, visit these online resources.
  • Microsoft IT Showcase Technical Case Study: “Empowering Users with Self-Service Identity and Access Management Solutions: An Overview of Easy ID”
  • TechNet Webcast: “How Microsoft Delivers Self-Service Identity and Access Management Solutions”
For more information about MIIS 2003, visit these resources.
  • Microsoft Identity Integration Server 2003
  • Microsoft Identity Integration Server 2003 Scenarios
  • Microsoft Identity Integration Server 2003: Technical Resources for IT Pros

Microsoft IT Showcase presents an inside view of the Microsoft IT process for developing, deploying, and managing Microsoft solutions—from Microsoft IT professionals to IT professionals—peer to peer. The resources they provide reveal how Microsoft uses technology to solve specific business problems. Find out more at Microsoft IT: Showcase.
Lana Chin is a technical writer and instructional designer who is based in British Columbia, Canada. She holds an MCSE certification and a Bachelor of Science degree.


 Business of IT: Understanding Regulatory Compliance
Business of IT
Understanding Regulatory Compliance
Tony Noblett

In the last few years, governments the world over have taken up the job of protecting consumers and companies against poor management of sensitive information. Unfortunately, this has led to a steady stream of confusing laws and regulations coming from all directions. In this column I'll look at these laws, go into depth on a few of them, and discuss how you, as an IT pro charged with making your company compliant, can approach the issue.

Laws and Regulations
Depending on the industry you're in, your organization may be used to regulations or completely new to them. The late 1990s and early 2000s ushered in the era of laws governing information security, privacy, and accountability, thanks in part to companies like Enron and in part due to the sheer volume of personal and sensitive information stored in and transmitted though vulnerable channels.
At the heart of most regulations is the intention of protecting the confidentiality, integrity, and availability of information that impacts a corporation's stakeholders. These laws can be distilled down to their essential goals:
  • Establish and implement controls
  • Maintain, protect, and assess compliance issues
  • Identify and remediate vulnerabilities and deviations
  • Provide reporting that can prove your organization's compliance
So let's take a quick look at the laws and regulations that have immediate impact on IT pros, in just enough detail to understand what each law is about. But don't assume this list represents all of the laws and regulations that may apply to your business. There are a number of others both in the United States and across the globe you may or may not need to deal with, depending on your situation.

New Laws and Regulations Affecting IT Pros
Sarbanes-Oxley The Sarbanes-Oxley Act of 2002 (SOX) was a response to corporate scandals. Its most prominent aspect, from an IT perspective, is Section 404, which requires that the annual reports of public companies include an end-of-fiscal-year assessment of the effectiveness of internal control over financial reporting. Section 404 also requires that the company's independent auditors attest to, and report on, this assessment. The assessment of financial controls has been extended into the IT space by the opinion of the Public Company Accounting Oversight Board (PCAOB), a private-sector, non-profit entity created by SOX to oversee the auditors of public companies. This extension of financial controls into the IT space provides most of the current impetus for IT controls.
Gramm-Leach-Bliley Act The Financial Services Modernization Act of 1999, better known as the Gramm-Leach-Bliley Act (GLBA), protects the privacy and security of individually identifiable financial information collected, held, and processed by financial institutions. The privacy component requires financial institutions to provide their customers with an annual notice of their privacy practices and to allow customers to choose not to share such information. The safeguards component requires that financial institutions establish a comprehensive security program to protect the confidentiality and integrity of the private financial information in their records. Recommendations for audit were produced by the Federal Financial Institutions Examination Council (FFIEC), an interagency group comprised of five of the eight major financial regulatory agencies.
Health Insurance Portability and Accountability Act The Health Insurance Portability and Accountability Act (HIPAA) includes, among its various components, privacy and security rules. These rules focus on Protected Health Information (PHI) and electronic PHI (ePHI) gathered in the healthcare process and mandate the standardization of electronic transactions, code sets, and identifiers. The privacy and security rules are detailed and prescriptive. Although the regulation focuses on the healthcare industry, other companies can be impacted if they engage in certain activities, such as the management of employee group health plans, or if they provide services to companies that are directly impacted by the regulation.
European Union Data Protection Directive The European Union Data Protection Directive (EUDPD) standardizes the protection of data privacy for citizens throughout the European Union (EU) by providing baseline requirements that all EU member states must achieve in national regulations. The EUDPD has a strong influence on international regulations due to the limitations it puts on sending EU citizens' personal information outside of the European Union to areas that are deemed to have less than adequate standards for data security. Example of specific laws in countries representing EU member states are the Finnish Personal Data Act (523/1999) and Amendment (986/2000), the Danish Act on Processing of Personal Data (Act No. 429) of May 31, 2000, and the Austrian Federal Act concerning the Protection of Personal Data (Datenschutzgesetz 2000 - DSG 2000). The EUDPD, member state transpositions of the Directive, and the regulations enacted pursuant to it impact companies that do business in the EU or that handle the data of EU citizens.
Bank Secrecy Act The Bank Secrecy Act (BSA), is one of the oldest laws on this list, having been passed into law by the United States in 1970. The BSA is sometimes referred to as an Anti Money-Laundering law (AML) or as BSA/AML. Several anti-money-laundering acts, including provisions of the USA PATRIOT Act, were subsequently enacted to amend the BSA. (See 31 USC 5311–5330 and 31 CFR 103.) The BSA requires banks and other financial institutions to report certain transactions to government agencies and to withhold from clients that such reports were filed about them. These transactions include deposits or withdrawals of more than $10,000 in cash in a day, or purchase of monetary instruments (money orders, cashier's checks, traveler's checks) worth more than $3,000. For such transactions, banks must supply information about the person doing the transaction, such as address and occupation, to the Internal Revenue Service in a currency transaction report (CTR). If it appears the person is in any way attempting to circumvent the report, the Bank must file a suspicious activity report (SAR) with the Financial Crimes Enforcement Network (FINCEN). There are stiff penalties for individuals and institutions that fail to file CTRs, or SARs, or that disclose to a client that it has filed a SAR about the client. Very complex monitoring of accounts has grown up around this law, which also illustrates that compliance is not new.
USA PATRIOT Act The USA PATRIOT Act (Public Law 107–56) is federal legislation in the U.S. Passed soon after the September 11, 2001 terrorist attacks, the Act expands the authority of U.S. law enforcement for the stated purpose of fighting terrorist acts in the U.S. and abroad. This expanded legal authority is also used to detect and prosecute other alleged crimes. The portion of the Act that relates to IT is called the Financial Anti-Terrorism Act and deals with money laundering. This item works in conjunction with the BSA/AML just mentioned.
The Federal Information Security Management Act The Federal Information Security Management Act of 2002 (FISMA) was enacted to bolster computer and network security within the U.S. federal government and affiliated parties (such as government contractors) by mandating yearly audits. FISMA has brought attention within the federal government to the previously neglected area of cyber security. At the time of this writing, however, many government agencies have received extremely poor marks in this area on their official report cards. The average grade of 67.3 percent for 2004 was an improvement of only 2.3 percentage points over 2003, and experts warn that this average must increase for the federal government to truly protect itself and its citizens.
Payment Card Industry Data Security Standard The Cardholder Information Security Program (CISP) was instituted by Visa USA and MasterCard International. Mandated since June 2001, the program is intended to protect cardholder data—wherever it resides—ensuring that members, merchants, and service providers maintain the highest information security standard. Using the Payment Card Industry (PCI) Data Security Standard as its framework, CISP provides the tools and measurements needed to protect against cardholder data exposure and compromise across the entire payment industry. The PCI Data Security Standard consists of 12 basic requirements supported by more detailed subconditions.
California Senate Bill 1386 (CA SB 1386) was introduced in July 2003 as a first attempt by a state legislature to address the problem of identity theft. In short, the bill introduces stiff disclosure requirements for businesses and government agencies that experience security breaches that might endanger the personal information of California residents. It is expected that many organizations in the Unites States are subject to these requirements. In addition, many other states since have, or are planning to, enact similar legislation.
International Convergence of Capital Measurement and Capital Standards—A Revised Framework is also called Basel II or the New Accord and it represents recommendations by bank supervisors and central bankers from the 13 countries making up the Basel Committee on Banking Supervision for revising the international standards for measuring the adequacy of a bank's capital. This agreement was created in order to promote greater consistency in the way that banks and regulators approach risk management across national borders.
Personal Information Protection and Electronic Documents Act (PIPEDA) is a Canadian federal regulation that governs the collection, use, and disclosure of personally identifiable information in the course of commercial transactions. The act was created in response to European Union data protection directives that limit trade with nations whose privacy protection does not meet EU standards. PIPEDA incorporates and makes mandatory provisions of the Canadian Standards Association's Model Privacy Code of 1995. The act covers all of Canada except those provinces that have "substantially similar" legislation (namely British Columbia, Alberta, and Québec) and covers all inter-provincial trade.

Making Your Organization Compliant
For better or worse, IT is in the spotlight with regard to compliance. Suddenly, IT departments everywhere have been charged by the CEO, CFO, and Audit Committee with making the company compliant, because many of the laws carry personal liability penalties for officers and directors of corporations. So where do you go to get the information and support you need? A whole host of software vendors have created point solutions for compliance issues, but sorting through the effectiveness of these offerings can be daunting.
To date, most of the interpretation surrounding compliance has been done by specialists in auditing and IT security. When it comes to complying with SOX in large enterprises, for example, the large accounting firms supply almost all of the expert opinion, while smaller organizations tend to use IT security consultants. Unfortunately, the two groups view the problem differently, so you'll have to choose the practices that work best for your organizations. The good news is that both groups agree that using best practices can provide a host of benefits to IT. Let's explore the available best practices, which, for convenience, can be divided into one of two orientations: process or technology. Figure 1 shows some best practices in compliance.
Figure 1 Best Practices (Close Figure 1)

Practice | Orientation | Developed By | Description
Turnbull Report | Process Guidance | Institute of Chartered Accountants of England and Wales | The combined code on corporate governance for the UK. (www.icaew.co.uk/internalcontrol)
CobiT | Process Control and Management | Information Systems Audit and Control Association/ IT Governance Institute (ISACA/ITGI) | A process standard for Public Company Accounting Oversight Board (PCAOB). (www.isaca.org)
COSO | Process Enterprise Risk Management | Committee of Sponsoring Organizations of the Treadway Commission | Used by the Public Company Accounting Oversight Board (PCAOB) as a guide for SOX. (www.coso.org)
ITIL | IT Service Process | UK Office of Government Commerce | Detailed process-oriented approach to IT services management. (www.itil.co.uk)
ISACA/ITGI Harmonization Document | Process and Technology Mapping | ISACA/ITGI | Maps CObiT to ITIL and ISO 17799. (www.isaca.org)
ISO 17799 | Technology | ISO / BSA | Shows how to create an IT security program. (www.iso.org)
NIST SP 800 Series | Technology | National Institute of Standards, U.S. Government | Detailed implementations by technology or process in IT security. Adopted by FISMA and the FIPS standards. (csrc.nist.gov)
Common Criteria (ISO 15408) | Technology | ISO | Detailed technical best practice that has suffered from issues of enforcement and recognition. It is now being overseen by a group of nations to provide a more level interpretation.
If, for example, your enterprise is embroiled in SOX compliance issues, the best approach would be to use a combination of CobiT and ISO 17799 as represented by the ISACA/ITGI Harmonization document. If your organization is a financial services enterprise trying to meet the requirements of BSA/AML, USA PATRIOT Act, and GLBA, a best approach would be to use ISO 17799 since the FFIEC audit criteria align most closely with it. If your company is working to comply with HIPAA, a blended approach would be the best, with elements of ISO 17799 and the direct requirements of the HIPAA Final Rule from the U.S. Office of Health and Human Services.
If you're not an expert yourself, it isn't easy to figure out which best practice is right for you. That's where IT Security and Compliance specialists can help, by providing you with the least costly method for compliance. The cost reductions come from a deep understanding of all components of all best practices and how they match the requirements of the law or regulation you must comply with.

Just Give Me a Solution
Probably the most appealing approach is to acquire a ready-made solution. As part of a six-month long effort funded by Microsoft Security Solutions, a group of experts mapped the requirements of the laws to best practices and ultimately to solutions. The solutions were then grouped by function and Microsoft products and services were mapped to these groups. Unfortunately, this mapping has not yet been released, so you'll have to wait. Meanwhile, Figure 2 describes some of the more general business solutions that are available while Figure 3 lists security-related solutions.
Figure 3 Security Solutions (Close Figure 3)

Name | Description | Examples
Application Security Solutions | A combination of good development practices and specific software security solutions. | Radware, CSS
Data Encryption and Transmission Solutions | Deals with protecting data that is at rest or in transmission. | Windows Server 2003, PGP
Identity Management Solutions | Tools used to manage the digital identities of users and their digital entitlements. Controls the privileges assigned to both identities and resources. | MIIS, Oblix, Tivioli, Sun, BMC
Network Security Solutions | Addresses the security of all parts of the network including firewalls, servers, clients, routers, switches, and access points. | Windows Server, SMS, MOM
Security and Compliance Training Delivery | Provides the critical link between people, processes, and technologies that make a security program work. | Kronos, Contexxa, Ascentis
Malicious Software Prevention | Antivirus, anti-spyware, anti-spam, and anti-rootkit solutions. | Microsoft Antispyware beta, WebRoot, Symantec
Security Integration Solutions | The integration of security to data at rest or in transmission. | Consulting: HP, IBM, Microsoft, Avanade, Accenture
Authentication, Authorization, and Access Control Solutions | User name and password, smart card, retina scan, voice recognition, or fingerprints. Access can be granted or denied based on a variety of criteria. | Windows XP, Windows Server 2003, IBM, Sun
Physical Security Solutions | Provides solutions for physical access, control, and security of systems and workstations. | Consulting
Figure 2 General Solutions (Close Figure 2)

Name | Description | Examples
Document Management Solutions | A combination of software and processes that help manage unstructured information in an enterprise. | SharePoint products, Documentum, FileNET
Project Management Solutions | Tools used in the implementation, ongoing operation, and maintenance of compliance programs by providing control and feedback to project managers and teams. | Microsoft Office Project
Change Management Solutions | A structured process that causes proposed changes to be reviewed for technical and business readiness in a consistent manner that can adjust to business needs. | SharePoint, SMS, Remedy, Serena
Host Control Solutions | Solutions that control the OS in servers and workstations. | Windows Server 2003, Windows XP
Vulnerability Identification Solutions | Tools for finding vulnerabilities within information systems. | ISS, Core Impact, Retina, GFI Languard
Disaster Recovery and Failover | Application that brings enterprise information back to an operational state as quickly as possible. | Data Protection Manager
Business Process Management Solutions | Applications that provide end-to-end visibility and control over all parts of a long-lived, multistep information requests or transactions. | BizTalk, SAP
Risk Assessment Solutions | A systematic method for identifying the assets of an information-processing system, threats to those assets, and the vulnerability of the system to those threats. | Usually a consulting engagement combined with assessment tools
E-Mail and Collaboration Solutions | Tools ranging from integrated document programs such as Microsoft Office, portals, instant messaging, online-presentation software, and peer-to-peer apps. | Exchange, SharePoint, Enterprise, Symantec
Audit and Logging Solutions | Audit and logging solutions collect and audit logs that result from authentication and access to systems. | MOM, ACS, Novell, Tivoli, Altiris
Incident Management and Trouble-Tracking | Systems that manage a specific business process from beginning to end, customized for incidents or trouble-tracking. | Intuit, SAP, many CRM vendors
These solutions still require experienced implementation with firewalls and good network design and may require vulnerability assessment and intrusion detection applications to be complete. They also require complete and usable documentation that includes security policies and overall document management methods. My intention here is to suggest how these solutions can provide compliance coverage, not provide a specific solution.

One Final Note
The effects of regulatory compliance on the IT pro are complex, but you have to face them. You can save a lot of precious time and effort by becoming familiar with the laws and by bringing in specialists who can work the confluence of regulatory compliance and IT security. Most importantly, regulatory compliance translates into plain old good IT security practices.

Tony Noblett has spent the last five years consulting with enterprises on IT Security Compliance for GLBA, HIPAA, and Sarbanes-Oxley. Tony has over 20 years experience with process engineering, engineering management, technology marketing, and technical consulting. Tony holds an undergraduate degree in Metallurgical Engineering, an MBA, and an MS in IT as well as the CISSP and CISA certification. Reach him at tnoblett@socair.com.


 TechNet Radio: An Interview with Alan Levine of Alcoa
TechNet Radio
An Interview with Alan Levine of Alcoa

Every week, TechNet Radio covers the latest trends and technologies in the world of IT, and provides interviews with real IT professionals who work in the field. Alan Levine, Chief Security Information Officer for Alcoa Inc., the largest aluminum producer in the world, recently sat down with TechNet Radio to discuss digital identity and malicious software.

Host: Alan, why don’t we begin by you introducing yourself?
AL: I’ve been with Alcoa for nine years. I was invited in to create a global structure for information security for the company. It was a bright choice at that time to globalize its security efforts, given how global we were becoming. We now have manufacturing locations in 40 countries and we employ well over 100,000 people.
Host: What are the hot topics today?
AL: One of the hottest topics is digital identity—whether it’s the function of digital provisioning, automated request processing, direct URL processing, or the workflow around all of that so the approval is properly signed off on. The notion that I know who you are or I can determine what you should be able to do or not do—that’s an evolving science. It’s not just a science, it’s an art.
Host: Do you feel like you’re fighting the same issues you were fighting 10 years ago or have you put those to bed and are you now facing new issues?
AL: Absolutely put those to bed. The first time I thought of myself as a security person was back in 1985 when IBM rolled this thing into a machine room called "Rack F" and said here’s the new way you’re going to manage the mainframe. Then the questions were very, very different. They were about managing the integrity and availability of a particular box, a particular set of data that was sitting on that box, and a very finite collection of applications. Today, everybody is connected to everybody. In 1985 spam was something in a can; there was no such thing as spyware unless the KGB or the CIA was inventing it, and a virus was something that gave you a cold. These things have all changed over the years.
Host: How do you manage the new technology? Do you evaluate it in isolation or against the environment as a whole? I mean, yours is a very complex environment.
AL: That’s an excellent question, and I will be the first to tell you that for myself and for the colleagues I know who are information security folks, this has caused a lot of angst. Over time, as threats have risen, we have created solutions to identify these threats. The next threat came along, and we created the next solution for that threat. And so we ended up with a lot of siloed solutions for what are now in a sense integrated threats. My ideal state is that we reevaluate what we do with those silos and find ways to integrate them—not to address a new threat, but to simplify how we address existing threats.
Host: What about your personal approach to things everybody else complains about? You’re putting out fires constantly, not really thinking of the big picture. How do you manage that?
AL: My experience has been that you put out some fires and they teach you the lessons that you need to come up with the next tactical response, which then leads you to the lessons that you need for the next strategic response. Fighting fires in a vacuum without having a Monday morning meeting to figure out the root cause of what happened and whether you approached the situation properly—maybe that’s the wrong way to fight the fire. But to fight the fire and then to learn from the experience, extrapolating it to a tactic, to a strategy—I think it’s all directly related. You can make the opposite mistake, doing strategy in a vacuum, creating this wonderful nirvana of technology and security that does not enable you to put out the next fire.
Host: Or isn’t relevant to fires?
AL: Not relevant to relevancy. I think they have to be connected. You have to see everything that you do everyday as a building block to everything you need to do over time. In information security, you can’t succeed or prosper unless you’re constantly learning.
Host: So learn to love your pager?
AL: Well, learn to love to turn it off.

This interview is adapted from TechNet Radio. For the complete audio of the interview, visit Microsoft TechNet Radio.


 Hey, Scripting Guy!: Late-Night Scripting
Hey, Scripting Guy!
Late-Night Scripting
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2006_09.exe (150KB)

If you’ve ever watched a so-called B movie on late night TV, you’re probably familiar with the following scene. Our heroes are looking for something and, just minutes into the film, they find it. "Man, that was easy!" exclaims one of our heroes, usually the expendable one whose screen time is just about up. "Yeah," says the smarter hero, staring off into the darkness. "A little too easy...."
Needless to say, it’s right about this time that our heroes discover they’ve been set up and the whole thing is a trap. As they try to fight their way to safety to regroup and continue with the rest of the movie, the moral of the story becomes clear: if something seems too good to be true, it probably is too good to be true.
Fortunately, script writers don’t have to worry about such things. For example, suppose you want to create a new group in Active Directory®. Sounds hard, doesn’t it? Pshaw! For example, here’s a script—four whole lines of code—that creates a group named Managers in the Finance OU in fabrikam.com:
Set objOU = GetObject _
    ("LDAP://ou=Finance,dc=fabrikam,dc=com")

Set objGroup = _
    objOU.Create("Group", "cn=Managers")

objGroup.Put "samAccountName", "Managers"
objGroup.SetInfo
As you can see, the script starts out by binding to the Finance OU in Active Directory. Once that connection is made it then uses the Create method to create a new group. The Create method requires two parameters: Group (which simply specifies the type of object you want to create) and cn=Managers (which is required because cn happens to be one of the two mandatory attributes that all groups must have).
Of course, when you call the Create method you initially create the group in local memory only; the new account is not automatically written to Active Directory. To do that you need to assign a value to the sAMAccountName attribute; this is the second of the two mandatory attributes that each group must have. Following that, simply call the SetInfo method, which creates the new group and its attributes in Active Directory. If you open up Active Directory Users and Computers you’ll see your new group in all its glory.
Man, that was easy! A little too easy....
If this really was a B movie, now would be the time when the bad guys, a giant ant, or a bunch of crazy people armed with Macintoshes would spring out of the bushes, causing everyone in the theater to jump with fright. Without a budget for special effects, the best we can do here to scare you is pose the following scenario. When you ran your script, you created a global security group. Good for you. But what if we wanted a domain local security group, or a universal security group, or maybe even a global distribution group? What then?
Cue the ominous music. Hold on!
Listen, we apologize for giving you such a fright. Would it help if we told you that all you need to do is add a little bitwise logic to your script and then you can create any kind of group you want? That’s OK. We give that advice to lots of people and they all have pretty much the same reaction. We’re used to it.
Of course, most of the time the people we give that advice to are asking for help fixing a flat tire or carrying a load of heavy boxes. In this case, though, our advice actually makes sense. Or at least it will once we finish explaining it to you.
Before we launch into lecture mode, however, let’s do a quick review of Active Directory groups. To begin with, there are two broad categories of groups in Active Directory: security groups and distribution groups. The difference between the two? Security groups can be granted access to resources; distribution groups cannot. In other words, you can give a security group, say, read/write access to an object; a distribution group cannot be given access of any kind to an object. Period. (In case you’re wondering, distribution groups are typically used as e-mail mailing lists.)
Within each of these broad categories you can create three types of groups:
Global Groups All the users must come from the same domain.
Domain Local Groups Members can be drawn from any domain in the forest, but permissions can be granted to only the local domain (that is, the domain where the group account resides).
Universal Groups Members can be drawn from any domain in the forest and they can be granted permissions anywhere in the forest.
If you have only a single domain in your Active Directory then the different group types don’t really matter much (although you still need to be concerned with security groups versus distribution groups). In a multi-domain forest, however, group types become very important. Suppose the Managers group we created a little while ago is for all the managers in our forest, managers from the Europe and Asia domains as well as from the North America domain. That’s a problem—after all, our script created a global security group, and in a global group all the members must come from the same domain.
Uh-oh. There’s that music again. Trust us—in a B movie, that’s never a good sign. But wait, don’t panic. Remember, B movies always have happy endings. As it turns out we can use a script to create any type of group we want. All we need to do is set the value of the groupType parameter. And to do that we just need to add a little bitwise logic to our script.
See? We told you that this advice would make sense!
For example, suppose we wanted to create a universal security group. Let’s take a look at the code, shown in Figure 1, that does this and then we’ll explain how it all works.
Figure 1 Creating a Universal Security Group (Close Figure 1)
Const ADS_GROUP_TYPE_UNIVERSAL_GROUP = &H8
Const ADS_GROUP_TYPE_SECURITY_ENABLED = &H80000000

Set objOU = GetObject("LDAP://ou=Finance,dc=fabrikam,dc=com")

Set objGroup = objOU.Create("Group", "cn=Managers")
objGroup.Put "samAccountName", "Managers"

objGroup.Put "groupType", ADS_GROUP_TYPE_UNIVERSAL_GROUP _
    OR ADS_GROUP_TYPE_SECURITY_ENABLED

objGroup.SetInfo
To begin with, we define a pair of constants: ADS_GROUP_TYPE_UNIVERSAL_GROUP and ADS_GROUP_TYPE_SECURITY_ENABLED. The names we give to these constants aren’t particularly important; we use the same names found in the Active Directory Service Interfaces (ADSI) SDK. The values, however, are very important. To show you what we mean, the different values we can assign to groupType are shown in Figure 2.
Figure 2 Possible Group Type Values (Close Figure 2)

Group Type | Constant | Value
Global Group | ADS_GROUP_TYPE_GLOBAL_GROUP | &H2
Domain Local Group | ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP | &H4
Universal Group | ADS_GROUP_TYPE_UNIVERSAL_GROUP | &H8
Security Group | ADS_GROUP_TYPE_SECURITY_ENABLED | &H80000000
Got that? If we want to create a universal security group then all we need to do is set the value of the groupType property to &H8. Oh, and we need to set the value of the groupType property to &H80000000.
Next we—what’s that? Do you have a question? Oh, right: how can we set the value of a property to &H8 and set the value of a property to &H80000000? Looks like we better take a quick side trip into the wonderful world of bitwise attributes.

Bitwise and Pound-Foolish
To begin with, we should note that bitwise attributes were not designed to drive you crazy; they were designed to allow a single attribute to hold multiple values. (The fact that they do drive people crazy should be considered a minor side effect.) When dealing with bitwise attributes we find it useful to visualize a bitwise attribute (such as groupType) as being like a control panel with a series of switches. In the case of groupType those switches will equate to the allowed values:
Now, suppose we have a universal security group. To be a universal security group two things must be true: the &H8 switch must be on and the &H80000000 switch must be on. In other words, our control panel needs to look like this:
See how that works? What kind of group do we have here?
Exactly. The &H80000000 switch is on, which means we have a security group rather than a distribution group. And because the &H4 switch is on, we know that this is a domain local group. Our final answer: a domain local security group.
You’re right: this is more fun than working, isn’t it? OK, one more:
Excellent. The &H80000000 switch is off, therefore this is not a security group. Meanwhile, the &H8 switch is on. There’s only one possible answer: this is a universal distribution group.
Now that we know how multiple values can be stored in a single bitwise attribute all we have to do is figure out how to actually assign two different values to a single attribute. That’s something we’ll talk about as we resume explaining the script in full.

And Now for the Exciting Conclusion
After defining the two constants, our script then binds to the OU where we want the new group created. That’s what happens here:
Set objOU = GetObject _
    ("LDAP://ou=Finance,dc=fabrikam,dc=com")
Once the connection is made we call the Create method, passing two parameters: group (the type of object we want to create) and cn=Managers, the cn for the new group. Following that we use the Put method to assign a value to the sAMAccountName attribute:
objGroup.Put "samAccountName", "Managers"
That should look familiar to you; if it doesn’t, simply rewind this column back to paragraph 5 or so. But now comes the tricky part. Here’s the code that sets the group type to a universal security group:
objGroup.Put "groupType", _
    ADS_GROUP_TYPE_UNIVERSAL_GROUP _
        OR ADS_GROUP_TYPE_SECURITY_ENABLED
This is bitwise logic (and, as you might expect, there really isn’t anything particularly logical about it). The first part of the code is pretty straightforward: we call the Put method followed by the attribute (groupType) that we want to assign a value to. However, the second parameter—the actual value being assigned to groupType—is a bit unusual, to say the least:
ADS_GROUP_TYPE_UNIVERSAL_GROUP _
    OR ADS_GROUP_TYPE_SECURITY_ENABLED
As we already determined, in order to make a universal security group two switches must be set: &H8 and &H80000000. At the beginning of the script we created a pair of constants to represent those two values. Now we’re using bitwise logic to enable both of those switches for this attribute. To do that we have to specify both constants, joining the two using a logical OR.
Yes, common sense would suggest that you should join these constants together using AND. But, for better or worse, AND has a different meaning in bitwise logic.
Hey, it’s a grade-B movie; you can’t expect everything to make sense!
See how that works? Suppose we wanted to make this into a universal distribution group. A universal distribution group has only a single switch enabled: &H8. Hence we use code that assigns only a single value (again using the constant ADS_GROUP_TYPE_UNIVERSAL_GROUP) to the groupType attribute:
objGroup.Put "groupType", _
    ADS_GROUP_TYPE_UNIVERSAL_GROUP
What if we wanted to make a domain local security group? That requires two switches: &H4 and &H80000000. Assuming we’ve defined a constant named ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP (with a value of &H4) our code would look like the following:
objGroup.Put "groupType", _
    ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP _
        OR ADS_GROUP_TYPE_SECURITY_ENABLED
We’re not saying it isn’t a little weird. But it works, and as long as you squint your eyes a little and tilt your head sideways, it even makes sense. Sort of.
On the bright side, once you understand how the groupType attribute works (and what the acceptable values are) you can do other things, such as determine the group type for an existing group, or even change the type of an existing group (subject to certain Active Directory limitations, that is). For sample scripts that carry out these tasks, take a look at the Hey, Scripting Guy! archive in the TechNet Script Center. And while you’re at it, there’s a lot more to check out at the Script Center. You’ll find not only our old columns, but also tools, puzzles, language references, even a sweepstakes! And lots of scripts. For help in finding what you need, see "Your Search is Over" on this page.
As for the Scripting Guys, we’re well aware that as stars of a B movie any moment now we’ll be whisked off into the sunset with our breathtakingly beautiful new true love. Yep, any moment now. Sorry we can’t talk more about group types, but we’ll be leaving here soon. Any second now. You know, the traffic can get kind of bad around Seattle this time of night, so it might take a few minutes. But pretty soon we’ll be on our way. Yep, pretty soon....
Your Search is Over
Script Center Audio Tour
You’re wandering through a maze, every passageway leading into many others. There’s no end, never a way out, and you don’t seem to ever find what you’re looking for. Does this sound like a nightmare? Or does it just sound like your most recent foray into a typical Web site?
Well, we sympathize. And we have something that can help—at least for when you’re at the Script Center. The next time you come to the Script Center, simply download the new audio tour and transcript. Your friendly tour guide will help you navigate the maze of Web pages and seemingly endless treasure trove of information. Who knows, you might finally find that piece of cheese at the end of the maze.

Browse by Category
Do you need to do a search on Active Directory, but don’t know where to look for more information? Try looking under Active Directory on the Script Center. But what if you aren’t looking for info on Active Directory? What if instead you want to watch a webcast that will teach you how to script Microsoft Office? Then just look under Office in the Script Center.
Seems pretty obvious, doesn’t it? The Script Center lets you browse by category, making it much easier to find what you’re looking for. So check out the Browse by Category section of the Script Center and things just might become a lot more obvious. And more categories are being added all the time.

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


 Beta Box: System Center Operations Manager 2007
Beta Box
System Center Operations Manager 2007
Stewart Cawthray

Managing and monitoring the IT infrastructure is essential to maintaining a healthy environment. But while IT departments have tools in place and deal with these tasks on a daily basis, the strategy for managing and monitoring continues to challenge IT departments as they look for more efficient ways to deal with ever-changing and growing environments.
How do you monitor several hundred or thousand servers and ten times as many client computers, let alone all the applications that run on those servers and clients? And how do you determine whether critical apps, which are spread across multiple servers, are running optimally? You need an effective management solution that provides event and performance monitoring of your hardware, software, and operating systems. You need deep reference materials to help your IT staff react to problems as they arise. And you need robust reporting that provides relevant and accurate information to decision makers. Microsoft® System Center Operations Manager 2007 aims to address these needs.
Microsoft System Center Operations Manager 2007, which is expected to be released near the end of 2006, is the next version of Microsoft Operations Manager (MOM). It is a key component in the System Center family and will present a shift in management strategy, moving away from monitoring only individual servers and applications to holistically monitoring services and clients. Operations Manager functionality can be broken down into four main categories: end-to-end service monitoring, Microsoft knowledge, reliability and security, and operational efficiency. Let's take a look at the new features as they fit into these four areas.

End-to-End Service Monitoring
Most common management tools can handle monitoring a simple application that runs on a single server. But today's infrastructure is far more complex than this. Services are typically made up of many applications running on many devices. One problem anywhere in the chain of infrastructure that connects a distributed application can impact productivity. This model requires a sophisticated approach to monitoring. Operations Manager 2007 offers several new features that address this challenge by providing a more comprehensive approach to monitoring distributed services.
The new Distributed Application Designer tool lets you build IT service models that Operations Manager uses to monitor end-to-end services. Basically, the tool provides an intuitive graphical interface for defining the various components and relationships that make up a particular service (see Figure 1). You then associate devices being monitored with the components shown in the service model. Any object being monitored by Operations Manager can be added to a distributed application model. This allows Operations Manager to monitor a service and all of the components it relies on as a whole. The level of granularity is quite fine and makes for a very accurate representation of the actual service.
Figure 1 Distributed Application Designer
Figure 1 Distributed Application Designer
The included Distributed Application Templates can help you quickly build these models. The templates, which can also be designed by third parties or internally by your own IT administrators, provide base models, or starting points, with the key components and relationships already in place. IT administrators then need only associate the monitored objects with the correct components and save the model. The templates are fully customizable so you can extend or subtract from them as needed.
Models are saved using the System Definition Model (SDM) language. SDM is an industry-standard SOAP-based XML modeling language that is used by many Microsoft applications—such as Visual Studio®—to describe application and service models. The Distributed Application Designer allows IT administrators to build highly descriptive SDM models without specific knowledge of the underlying SDM language; they can simply drag and drop objects into components and the designer converts this to SDM in the background.
End-to-end service modeling also addresses monitoring from a client perspective to offer a more realistic perspective of whether a service is accessible. The problem is that a service may be running and it may be available to the servers that support it, but this does not guarantee that the service is available to clients. To incorporate the client perspective into monitoring, Operations Manager 2007 will support the ability to build synthetic transactions. Watcher nodes, which are client computers designated to run these transactions, can execute a predefined sequence of events and report the results back to the Operations Manager agent for rules processing and gathering of performance statistics.
Once defined, an end-to-end service can be monitored like any other single device. Health information will flow across the defined relationships and allow for state views and alerts to be performed on the service as a whole, rather than on individual objects.
Operations Manager 2007 also introduces Agentless Exception Monitoring (AEM), which captures, aggregates, and reports on application crashes across the entire enterprise. This will give IT administrators a view of which applications and systems in an enterprise suffer the most crashes.

Microsoft Knowledge
One of the most useful features in Operations Manager 2007 is the knowledge it includes about monitored objects. Each item you are able to monitor is defined in a Management Pack, which contains the rules and monitor definitions for the object being monitored. The Management Pack also contains SDM models, health models, predefined views, reports, and best practices information relevant to the object being monitored. Management Packs for Microsoft products are developed by the same teams who create the software for which the pack is responsible. This means that the developers who code an application also define how to monitor that application.
The best practices are gathered from the internal Microsoft IT department and from the Product Support Services group that helps thousands of customers every day. Meanwhile, Microsoft partners are producing Management Packs for non-Microsoft devices and software. And, of course, IT departments can build their own Management Packs and modify existing Management Packs for software they've written in-house.
Management Packs are based in XML, allowing for easier development and inclusion of new features. Now when an IT administrator reviews the knowledge about an event, he can execute the recommended tasks directly from the knowledge pane instead of moving to another area of the console.
Reporting has been upgraded to use the SQL Server™ 2005 version of Reporting Services. This update makes it much easier to define and share reports. In addition, several new reporting controls have been included to enhance Operations Manager reports. A number of predefined reports are included in Management Packs for the most commonly reported DataSets, and all reports shipped in Management Packs are fully customizable.

Reliability and Security
Operations Manager 2007 includes a number of valuable security features that help protect your environment. For instance, it includes authentication and encryption of network communications between management server and agent. It also lets you prevent manually installed agents from being discovered.
IT administrators can define custom user roles to enable members of groups associated with the role to see only the events and views that have been assigned by the role. They can also control which tasks will be available to the role. This granularity allows the Operations Manager Console to be safely deployed to more users in the IT environment, since it can be given to users who only need access to certain types of information and their access privileges can be limited to just that information. Read-only access can be granted as well.
The audit collection service can collect and consolidate Windows® Security Log entries from across the entire enterprise. This should prove to make compliance and security solutions easier to implement.
Operations Manager has also been made more reliable, with improved self-monitoring of the management server and agents. You can utilize Windows and SQL Server clustering, as well as automatic failover agents, to make the management infrastructure more redundant. And it has been made more scalable, allowing it to run more reliably in organizations with hundreds of IT administrators, tens of thousands of servers, and hundreds or thousands of managed clients. This is done through an architecture of highly scalable management servers that can be tiered to provided consolidated views of the entire enterprise.

Operational Efficiency
Using the guidance offered in the included Management Packs, IT generalists can solve more events. This frees up the specialists from the reactionary fire fighting, allowing them to act in a more proactive manner. This means they can focus on implementing new technologies and refining the environment.
Operations Manager 2007 has introduced several new features to further augment efficiency. For example, it supports deeper integration with Active Directory®. Operations Manager now uses Active Directory in discovering managed devices. You can define Active Directory organization units (OUs) to be managed by Operations Manager so that when new devices are added to the OU, Operations Manager automatically deploys the agent and configures it to be monitored by the correct management group.
The Discovery Wizard, which also makes great use of the integration with Active Directory, offers both automatic and advanced search capabilities. With the Discovery Wizard, administrators can control what types of devices they want to find and then deploy the agents automatically.
The new consolidated Operator and Administration console utilizes role-based security to enable access to Operations Manager from a Web browser (see Figure 2), making it easier for support staff to access events and guidance.
Figure 2 Operator and Administration Console
Figure 2 Operator and Administration Console
Client monitoring lets you aggregate performance data and events for a group of clients, a handy tool for department and enterprise level reporting. You can, for example, create a report of overall availability of Microsoft Outlook® across all clients in the enterprise, or you can report on which OS version requires the most reboots. And the Microsoft Connector Framework is still supported, so you can integrate other management tools with your Operations Manager deployment.

Stewart Cawthray is a Product Manager with the Windows Enterprise Management Division at Microsoft. He holds various IT certifications including the ITIL Service Manager, Certified Information Systems Security Professional (CISSP), MCSE, and MCDBA.


 Inside Microsoft.com: Release Management
Inside Microsoft.com
Release Management
Jim Scardelis

Have you ever wondered how applications and content get developed and deployed to Microsoft.com? Are you curious about what development methodologies and processes are used and how Microsoft ensures that policies and standards are followed?
The Microsoft.com Release Management team is responsible for maintaining the policies and processes used to develop software for the site. Working within the development project teams, release managers hold these teams accountable for fulfilling their responsibilities and act as an interface between operations and the project teams. With a multi-project, multi-team view, they are often counted on to provide a strategic viewpoint and identify and manage cross-team dependencies, while also being responsible for the main deliverables in the deployment phase of the software development life cycle—creating the release plan and overseeing the deployment into the operational environment.
Each quarter, the Microsoft.com Release Management team deploys nearly 200 software releases into the various environments that make up Microsoft.com. Put another way, this means that each of our six release managers is responsible for managing the deployment of a project into one of the operational environments just about every other day. These releases are from a family of groups within Microsoft that do the bulk of the development work for sites such as microsoft.com, msdn.microsoft.com, profile.microsoft.com, technet.microsoft.com, and members.microsoft.com, which are each housed within the Microsoft.com operational environment. If you've ever visited Microsoft.com or any of the related Microsoft sites, registered a product, bought a product from the Microsoft Web site directly, looked up information on a Microsoft Official Curriculum training course, or even used the link in the Windows® Event Viewer that lets you get more details about an event message online, you've used something we've worked on.

Release Management Goals
A successful project release is one that releases at the right time, does not negatively impact customers and users, delivers the business value it was designed to address, and does not cause an inordinate impact on user support teams.
The goal of the Release Management team is to act as an extension of management, providing the necessary project oversight and guidance to ensure a successful release. To be able to do this, release managers must be involved in projects from the very beginning, not just at deployment. This lets us provide guidance (in the form of supportability and process requirements) during the envisioning and design phases of the projects, as well as participate in requirements and design reviews, to help make sure the project is set up to be successful from the very beginning and through all phases of its development. We also work with the development and operations teams when creating the release plan, which is used to guide and coordinate the deployment into the operational environment.

Setting Expectations Early
One of the keys to a successful project release is ensuring that expectations are set correctly, both within the project team and externally with stakeholders and management. We utilize a project release checklist to drive early agreements on who will fulfill the various required tasks and deliverables associated with the project, as well as which, if any, of the optional deliverables and tasks will be included in the project. The choice of checklist depends on which of the approved development methodologies the team agrees will be used
As this column is being written, there are several methodologies in use at Microsoft.com, including Waterfall, Agile, and SCRUM. Waterfall and Agile use the same checklist, an excerpt of which is shown in Figure 1. Agile is basically multiple Waterfall iterations in one project. (Some people, myself included, would argue that Waterfall is really iterative too, since almost no project except the very smallest make it from start to finish without at least one design change request occurring sometime in the build phase). SCRUM is a very different methodology, emphasizing face-to-face communication among team members and stakeholders, so we have developed a separate checklist for it. Both checklists are available from the Microsoft Download Center.
Figure 1 Waterfall Checklist Excerpt
Figure 1 Waterfall Checklist Excerpt
By setting expectations and obtaining agreements early in the project lifecycle, the team avoids last-minute surprises. It is particularly important to ensure that both representatives of the development and operations engineering teams participate in these discussions. Operations teams need to understand the project's goals and be able to perform capacity planning around expected customer traffic volume. This helps them determine whether the operational environment can support the release at the current time or whether, for example, additional capacity is needed, with an associated increase in budget. Waiting until the project's design phase—or even worse, until the developers have already started coding—could result in the team building a solution that cannot be deployed because it exceeds the ability of the current infrastructure to handle it.

Policies and Standards
The Release Management team works with various other teams at Microsoft to obtain agreement on, and put into effect, standards, policies and best practices that provide governance and direction for developing successful projects for the Microsoft.com environment. Many of these guidelines are very specific to our environment—for example, there is a policy and a standard for where the project files for a particular release are stored and what the folder structure for every release must be. Having policies and standards, and holding teams accountable for following them, has very clear benefits to the projects—and to the teams. There are many advantages, but I'd like to focus on two.
First, following policies and standards increases the predictability of the project, which means that team members know what to expect. Using a predictable location for project files, for example, means that the release manager knows in advance, even before the first line of code is written, where to get the bits for deployment to production. This enables him to begin writing the release plan early, rather than having to scramble to find the bits after the Test team signs off. It means that years later, if a new server is being built and someone needs to install a service onto it, he will know exactly where to go to find the files and documentation.
The second benefit is that having policies and standards reduces the number of decisions that must be made on things that are common to many projects to a small set—or sometimes even just one. This enables the project teams to focus their energies on what's really important—the features that will deliver on the original goals of the projects, rather than reinventing the wheel. Of course, if a policy or standard really doesn't meet a team's needs, there are processes for changing them or adding new ones. In general, though, most project teams simply agree to follow the existing policies and standards because of the clear benefit.

SDLC and Ops/RM Controls
The mandatory controls that are placed on the software development lifecycle (SDLC) by Microsoft corporate policy, along with the additional project criteria that the operations team requires of any project releasing into the operational environment are key policies that the Release Management team is responsible for holding teams accountable for. These controls are designed to ensure project success by requiring that various key deliverables and tasks take place, and then by documenting them in standard locations. In the project checklists, the corporate SDLC mandatory controls are the items color-coded in green, while the Ops/RM project criteria are color-coded in yellow.
For example, one SLDC mandatory control is a Responsible, Accountable, Consult, Inform (RACI) matrix that indicates the following for each deliverable and task:
  • Who is Responsible (person or team that actually does the work)
  • Who is Accountable (person or team responsible for making sure the work is done)
  • Who to Consult (provides input, feedback, and support)
  • Who to Inform (receives information about the project)
At the Microsoft corporate IT level, the RACI matrix is a complex template that is designed to account for any possible variation of project type and team. In Microsoft.com, the Release Management and Operations teams worked together to develop the project checklists, which contain the RACI information in a simplified matrix—because we also developed policies and standards around project release types, limiting them to only four (shown in Figure 2), which are denoted by the release version ID number. The sidebar "Version Numbers" explains the numbering process.
Figure 2 Release Terminology (Close Figure 2)

Release | Description
Major | A major release contains several significant features or an architectural change.
Minor | A minor release contains one significant feature or several small ones.
Service Pack | A service pack contains two or more bug fixes. It may not contain new features.
Hotfix | A hotfix is a single bug fix.
Service packs and hotfixes must meet certain impact criteria in order to be considered.
The SDLC process, which is based on the publicly available Microsoft Solution Framework (MSF), divides each project into six distinct phases: envision, design, build, stabilize, deploy, and production.
At the end of each of the phases (except production), the release manager conducts a phase review in which the list of deliverables and tasks (exit criteria) are reviewed and two decisions are made by the team: Have all the exit criteria for this phase been met successfully? Should we continue to the next phase?
The first question determines whether the team has met its goals for the phase. If not, a discussion about the reasons takes place, and the team either decides to do more work in this phase or communicates to the stakeholders and sponsors that it is unable to continue (usually because more resources are needed).
Once the team has determined that the goals of the current phase have been met, a go/no-go decision is made for the next phase. Asking this question can be one of the more difficult tasks a release manager faces, because everyone on a project team (including the RM) usually wants to see the project go into production. However, sometimes the right thing to do is to stop.
There are many reasons a project might not continue on to its next phase. For example, a project might have been planned as a three-month effort to add a feature to an existing project with a particular team working on it. After going through the envisioning and design phases of the project, it might become apparent that in order to actually build the proposed feature, six months and twice the team might be needed. The team would then, at the design-phase review meeting, make a no-go decision and provide documentation to the project sponsor that additional time and resources are needed.
By following the project release checklist and conducting phase reviews, issues that might prevent a project from being successful can be found and mitigated as early as possible.

Releasing to the Environments
In addition to the project release checklist, through which we hold other team members accountable for deliverables, release managers are responsible and accountable for a successful release and for the key document that helps ensure success: the release plan.
Release plans vary in form according to the project type, but they all contain several significant points of information, as listed in Figure 3.
Operational Environments
We have defined several types of operational environments based on their purposes. For the preproduction and staging environments, only operations and release management have read/write access, and only operations has access to the production environment. This ensures that control is maintained over the versions of software that are actually deployed. Figure A describes the various environments.

Releases are normally deployed to the preproduction and staging environments before being deployed to production. This gives an opportunity for smoke tests to verify that the release performs as expected in a production-like environment. It also provides operations with the chance to execute the release plan prior to propping the bits into production.
Many of our services are adopted by other teams. For example, one of the services provided by Microsoft.com is an internal Web service that enables content providers to publish Web page content to www.microsoft.com. Teams in several other development organizations have written clients that run against this Web service. So that they can test their clients without actually publishing to the live Web site, we offer a version of the service that runs in the pre-production environment, but otherwise mirrors the production setup. We typically release a new version of a service to its pre-production environment for a week prior to releasing to the staging environment so that adopters can make sure their clients work correctly with the new version.

Minimizing Negative Impact
One of our main goals when releasing any new version is to minimize the negative impact to customers and users. We strive for zero downtime—in other words, maintaining constant availability of the customer-facing system throughout the release period.
This is one of the most important reasons why release management must be involved throughout the entire project lifecycle. During the envision phase, we provide supportability requirements, including zero downtime, to make sure that the business goals and metrics include minimizing negative impact. In the design phase, we work with the core team to design the project in a way that fulfills those goals. One way we do that is to design projects that can be deployed in a side-by-side mode, in which the new version and current version of a system can exist in an environment at the same time. This enables the team to smoke-test the new version in place and have a final activation step that puts the new version into service. Side-by-side deployments simplify roll back plans as well, since the old version can be maintained in production for a period of time until the team agrees that keeping the rollback contingency available is no longer necessary.

Learning from Experience
The final task for release management on a project is to schedule and run the postmortem meeting. This is a nonconfrontational meeting at which the project team discusses both the things that went well on the project and the things that did not. The goal is not to place blame (in fact, the RM enforces rules at the meeting that prevent finger-pointing and blame), but rather to gather learning that can be used to improve future projects. Many times, something that went well (or even an approach to avoid or mitigate something that did not) gets documented as a best practice. Over time, best practices become standards and when that happens, everyone benefits.
Version Numbers
At Microsoft.com, we use a standard scheme by which anyone can tell the release type simply by looking at the version number:

x.0.0.0—The first number signifies major version release of the product.
0.x.0.0—The second number signifies the minor version release of the product.
0.0.x.0—The third number signifies the service pack release of the product.
0.0.0.x—The fourth number signifies the hotfix release of the product.

Jim Scardelis has been a Release Manager in various Microsoft.com groups since the turn of the century. Prior to joining Microsoft in 1997, he was the author of several books under the pseudonym "Jim Blakely" and a former contributing editor for MCP Magazine (now Redmond Magazine).


 Security Watch: Lock Up Your Domain Controllers
Security Watch
Lock Up Your Domain Controllers
Steve Riley

Recently I seem to have had the same conversation over and over again, in places as far apart as Jakarta, Winnipeg, and Berlin. It starts with a question, usually worded like this:
"What happens if someone steals one of my domain controllers?"
There is only one correct answer:
"You flatten and then rebuild the entire forest."
Not very comforting, I know. Consider this example. A customer once liked to display all of the company's shiny computer gear behind a large plate-glass window that faced the street (complete with labels indicating the telephone numbers of all the modems, but that's a different problem). One day, some thugs decided to help themselves to a computer, so they smashed their pickup truck through the window, snatched the first computer they saw, threw it into the back of the truck, and sped away. It just so happened that this computer was... a domain controller! The customer called the police and described the truck and the theft. The police found the thieves, recovered the computer, and returned it to the customer, who proceeded to reconnect it to the network. Alas, a very unwise decision.
Think about it for a moment: a bad guy had physical access to the system that is the source of authority for every security principal in your forest. Who knows what he's done? Here are some possibilities:
  • Extract password hashes from the Active Directory® database (no need to crack the passwords themselves now—see "Frequently Asked Questions About Passwords" for more information).
  • Install a malicious self-replicating virus or other malware.
  • Add rogue user, service, and administrator accounts.
  • Create or modify logon scripts.
Honestly, this is a machine you can no longer trust. And if the bad guy still possesses the computer, manages to reconnect that Typhoid Mary of a domain controller (DC) back to your network, and forces a replication to the other DCs in the forest... well, it frightens me to think of the possible ramifications.
Back in the days of Windows® 2000, Microsoft published some best practices for securing DCs. Part 2 contains a section called "Recovering from the physical breach of a domain controller." Ten thickly worded pages guide you through numerous manual and time-consuming (read: potentially error-prone) steps for working the bad guy out of your forest. I suppose all that might succeed, but you really can't trust that forest anymore. Rebuilding it from the ground up is your only practical choice. Yes, FDISK is your friend.

Managing Risk
Regular readers of my articles and attendees at conferences where I've presented know the point I'm making here. In the case of DC physical security, the question usually arises when customers begin placing DCs in locations outside the central headquarters. In the United States, where connectivity is amazingly cheap and highly reliable, we rarely need to bother with placing DCs in far-flung offices with only three people, two cats, and a creaky vending machine disgorging year-old pretzels (when it's in the mood).
But in other areas of the world—areas where bureaucracy-laden telcos, often remnants of governments now long gone, dispense bandwidth as if it were a glittering emerald encased in pure platinum (with stratospheric monthly charges to match)—organizations must make a security-versus-usability trade-off. Security prefers that all DCs remain safe in a central datacenter and all authentication traffic traverse the WAN; usability demands that DCs be placed where the people log on because WAN links die so frequently. In this scenario, I hope you agree with me that usability wins. If the people can't log on, they probably can't do their jobs; secure environments are useless if idle workers can't access them.
Therefore, you have to accept the risk and situate domain controllers as close to the people and resources as possible. I have four suggestions for mitigating risk.
Cage that beast. Numerous manufacturers offer steel cages in which you can encase your remote DCs (See MSN Search results). Limit your selection to those that include some form of physical anchoring, such as a large heavy chain attaching the cage to a bolt or eye screwed deep into a concrete floor. Be sure the cage includes a decent lock—an electronic lock is best, one that can audit all access. Remember, you're protecting not only the hard drive but the whole computer.
Consider multiple forests and selective authentication. Surely you've learned that Microsoft stopped recommending single forest/single domain Active Directory designs long ago. Yes, we were wrong about that. Because the forest is the true security boundary, implementing multiple forests helps contain the spread of any compromise, but to make multiple forests useful, you need to implement trusts. Typically, those are unidirectional: central corporate resource forests trust distributed user forests. There is the potential that the central forests might be trusting a compromised forest—at least for a period of time—and therefore could themselves become compromised.
A feature known as selective authentication lessens the risk. It's an authentication permission set on the security descriptor of the resource computer object located in Active Directory, not on the security descriptor physically located on the resource computer itself. Controlling authentication in this way provides an extra layer of protection to shared resources by preventing them from being randomly accessed by any authenticated user in the trusted distributed user forests. Now, if one of these user forests is attacked and requires a rebuild, you don't have to rebuild the entire trusting forest also—only the machines in that forest enabled with selective authentication of principals in the attacked trusted forest. See the second article I've highlighted in the "Security Resources" sidebar, Security Considerations for Trusts, for more information on selective authentication.
Deploy read-only domain controllers. A third alternative, scheduled to be available in the forthcoming release of Windows Server®, code-named "Longhorn," is to use read-only domain controllers in branch offices. The unattended version of the DC promotion utility gives you the option. A DC promoted this way contains a read-only replica of the Active Directory database. When users log on, they are authenticated via Kerberos referral from a full DC; the read-only DC caches password hashes only for those users in the branch office. This somewhat reduces the scope of the threat to a forest—if someone steals a read-only DC, then only the branch-office user accounts will need to have passwords reset.
Consider Active Directory designs that contain threats and mitigate risk. Perhaps my 60-second Active Directory design will work for you:
  • Forests and domains represent geography (geography is stable and doesn't move—much).
  • Organizational units mirror your administrative model (types of machines and people).
  • Security groups follow your organizational chart.
  • Selective authentication, not mere trusts, controls and limits access.
This design is simple, it's effective, it removes the politics from the design, and you don't need to pay an army of too-smart-for-school suits—er, I mean consultants—to pretend to labor over a customized design "just for you" that's really the same thing they did for the previous 1,000 customers, but still costs you dearly.
So protect those domain controllers! No, they don't store your company secrets, and yes, they're pretty much just plumbing in your network. But when you recall the painful inconvenience and overwhelming urgency associated with malfunctioning plumbing, I'm sure you'll agree that repeating such an experience is certainly something to avoid.
Security Resources
  • Best Practice Guide for Securing Active Directory installations and Day-To-Day Operations: Part II
  • Security Considerations for Trusts

Laws of Security
Law #3: If a bad guy has unrestricted physical access to your computer, it isn’t your computer anymore.
The 10 Immutable Laws of Security

Steve Riley, a senior security strategist in the Microsoft Security Technology Unit and contributing editor for TechNet Magazine, jets around the world to speak at conferences and spend time with customers to help them get and stay secure. His latest book is Protect Your Windows Network (Addison-Wesley, 2005). You can reach him at steve.riley@microsoft.com.


 Field Notes: The Job Candidate’s Job
Field Notes
The Job Candidate’s Job
Glenn Wasserman

I’m trying to hire you. I manage a big team of IT consultants at Microsoft that needs to get bigger. Our business is growing and we need experienced professionals who are passionate about technology and can make our team better. One of my key responsibilities is growing my team as our business grows, but my recruiting efforts have been frustrated by a problem that keeps cropping up.
My problem is this: I can’t find you. Oh, I’m sure you’re out there, and I may have even interviewed you. But ask yourself: did you effectively communicate your skills, your passion for technology, and how you would make my team better? Did you leave the interview confident that you did your job as a candidate, which is to make the interviewer understand why you are the best candidate for the job?
As a hiring manager, I view a job interview as a great opportunity to get to know a candidate who ostensibly is motivated to work for me. The problem occurs when I see people who don’t appear to be motivated to work here. If they have that kind of passion about my team, it doesn’t come across during the interview. This happens all too frequently.
Folks, you need to keep this in mind: after my team grills all the candidates, we frequently discuss them at length and debate the pros and cons of each one. And you can bet we discuss who wants the job more. It is only logical to assume that those who want the job the most are the ones who will be the most committed to success after they get hired. I haven’t regretted walking away from a candidate who didn’t appear to really want the job, and those who wanted it the most have given the most of themselves after coming on board.
Giving something of yourself during the interview is another important point. Some people are so guarded and so professional in their communication style that few elements of their personality are communicated to the interviewer. This is a huge problem. Ask yourself, what kind of person do I want to work with? You can bet that the interviewer has an idea of what she values in a coworker. If you don’t offer some insight into your personality, then the interviewer can’t determine if you will mesh well with the team and if you’ll work well with customers.
As an interviewer, it is my job to evaluate what I see and to probe for the qualities I value in an employee. As a candidate, it is your job to make sure the interviewer understands why you are an excellent choice for the position. Do your job! If you believe in yourself, then the act of communicating your strengths comes down to an effective job of selling.
Ah, there’s that word that always seems to come up: selling. Chances are there is a selling component to whatever job you seek. Even if you are developer locked in a datacenter in a corner, at some point you need to sell your results to the people who’ve requested the work. Since the selling process generally involves an understanding of what the buyer is looking for, it stands to reason that you may have questions about the specifics of the position. This is not a bad thing! In fact, asking questions about the position is a good way to show that you are very interested in the job. Most interviewers see this as a positive point of the interview. It’s another component of being open and sharing some of your personality—what you are asking can be a clear indication of what you are interested in.
Looking at the situation from another angle, keep in mind that a good IT professional needs to have more than just strong technical skills. She needs to communicate effectively with a wide range of people and personalities, think strategically, influence others in order to drive consensus, and possess sales skills as well.
The quietest candidates leave all kinds of judgments open to interpretation. If an interviewer doesn’t hear your opinion on something important, then he is forced to guess and, in that case, the guess is generally a conservative one. Remember, hiring managers are usually averse to taking what they perceive to be risks when they make a hire. The more that manager knows about you, the better chance you have of getting a job offer.
In summary, remember what your job is as a candidate. You need to make sure that the interviewer knows what you are capable of and why you are a great candidate for the job. The person interviewing you could be looking for someone just like you with exactly your skills. Don’t lose the opportunity because another candidate appears to want the job more than you do!

Glenn Wasserman is a consulting manager for Microsoft Services in the New York/New Jersey area. He has been working in the consulting field for over 10 years and in IT for over 15 years.


 What is TechNet?: Resources for the IT Professional
What is TechNet?
Resources for the IT Professional

The complete Microsoft TechNet Program provides comprehensive tools and authoritative information to help IT professionals get the most out of Microsoft products and technologies. It’s where you turn for the latest security alerts, live discussions, virtual testing labs, free tools, and in-depth articles that allow you to be more responsive, more informed, and more effective. Take a look at all the resources that Microsoft TechNet has to offer.

TechNet Online
The TechNet Web site is the place for IT professionals to get the information they need to plan, deploy, troubleshoot, maintain, secure, and support their Microsoft technology investments. You can access the latest security bulletins, tools, product documentation, TechCenters, Microsoft Knowledge Base articles, the Security Center, and the Script Center. You can also find learning resources, including e-learning, virtual labs, webcasts, and classroom training information, all at TechNet Online.

TechNet Flash
The biweekly TechNet Flash newsletter delivers the latest IT news, security bulletins, software updates, and event announcements right to your inbox—making it easy for you to stay up-to-date with the latest technological developments from Microsoft. You can customize your own version to receive the information that’s most important to you. Register at TechNet Flash.

TechNet Magazine
Improve SQL Server™ performance, tune up your Windows servers, simplify your life with scripts, and learn how to best protect your environment against the latest security threats. TechNet Magazine is a monthly print publication, also available online, that features in-depth articles from experts to help you do all this and more. But don’t just take our word for it. Flip through this issue and see for yourself, or read online at TechNet Magazine.

TechNet Events
Microsoft TechNet Events are free local events for IT professionals that explain how to use Microsoft products and technologies. You’ll see live demos and hear directly from specialists who live with real-world implementations of Microsoft products and technologies every day. Schedule and registration are available at TechNet Events.

TechNet Webcasts
TechNet webcasts are live broadcasts that feature interactive technical presentations, product demonstrations, and question-and-answer sessions. Up to 30 new webcasts are broadcast every month, each presented by an expert in their field. All content is also recorded and made available on demand. TechNet Support webcasts focus on support issues like troubleshooting, configuration, diagnostics, and fixes. Schedule and registration are available at TechNet Webcasts.

TechNet Virtual Labs
TechNet Virtual Labs let you evaluate Microsoft software in a risk-free environment. You can explore apps through guided tours that highlight new features, without the hassle of downloads or complicated installations. You can gain real-world insight into business issues by working hands-on with Microsoft products, including Windows Server™ 2003, Exchange Server, and SQL Server 2005. TechNet Virtual Labs are free at TechNet Virtual Labs.

TechNet Radio
TechNet Radio features interviews and commentary from Microsoft insiders and industry luminaries, as well as profiles of leading companies. We bring you the trends and technologies that are shaping the industry, and offer perspectives from your peers. Take a listen at TechNet Radio.

TechNet Plus Subscriptions
With a TechNet Plus Subscription, you get two free professional support incidents to use on any Microsoft technology, access to full-version software with no time limits for evaluation purposes, early access to beta software, newsgroups monitored by support professionals (guaranteeing next-business day responses to your technical questions), free training, and much more. Sign up at TechNet Plus Subscriptions


 Windows Confidential: Why are Shortcuts Files?
Windows Confidential
Why are Shortcuts Files?
Raymond Chen

Shortcuts are files. Many people, however, think that shortcuts should have been handled differently. People have suggested that they should have been implemented as hard links, symbolic links, object tracking, or any number of other possibilities. So why was it decided that they would be files? To understand this, remember what the working constraints were back 10 or 12 years ago:
  1. The mechanism had to run on a machine with only 4MB of RAM.
  2. Shortcuts had to be supported on all file systems—especially FAT, since that was the only file system Windows® 95 supported natively. The mechanism also had to work on Novell, Lantastic, Banyan, LAN Manager, Samba, and other networking systems without requiring a new networking protocol (since that would have required network vendors to release new drivers and people to install them on their file servers).
  3. It had to be possible to copy a shortcut to a floppy disk or send it to a colleague as an e-mail attachment.
  4. Backup programs had to be able to back up and restore shortcuts.
  5. A shortcut had to contain information that allowed a user to customize its appearance and other properties, such as its hotkey.
  6. It had to be possible to create shortcuts to objects on different volumes, across file systems, as well as to items that weren't files, such as control panel programs and dial-up networking connections.
The first constraint is pretty straightforward. Basically, it says that we had to keep it simple. Anything fancy would have taxed a poor machine with only 4MB of memory.
Constraints two and three required that shortcuts be plain files rather than special file system objects. Once something has been sent as an e-mail attachment, you've pretty much lost everything other than a plain octet-stream.
Permitting existing backup programs to operate on shortcuts was an argument against inventing a new type of file system object, because existing backup programs wouldn't know how to deal with these new files. Therefore, the inability of backup programs to back up shortcuts wasn't a deal-breaker, but it certainly biased the decision in favor of using plain files. Even the introduction of long file names on FAT drives didn't break backup programs. Backup utilities could still back up the short names; and Windows 95 included the LFNBK utility that allowed you to back up and restore the long names manually.
The fifth requirement could have been satisfied by NTFS alternate streams, except for the fact that Windows 95 didn't support NTFS. (Even if it did, this would have required people to reformat their drives as NTFS in order to upgrade to Windows 95.) In the absence of alternate streams, the information must be stored elsewhere in Windows in order to present the rich user interface we desired.
Finally, the need to create shortcuts that span volumes and point to things that aren't even files meant that shortcuts could not be purely a file system feature, since the target of the shortcut might live outside the file system.
Given these constraints, the most reasonable option was for a shortcut to be a file that contained the necessary information about what it pointed to and any supplementary information, such as its icon and hotkey. This design has proven very flexible. Subsequent versions of Windows have added more functionality. For example, a shortcut can now represent a program that hasn't even been installed yet, but one which your domain administrator has made available. Or you can have shortcuts to files whose paths are relative to environment variables.
Some people have suggested that shortcuts could have operated like the Apple Macintosh Alias Manager. Indeed, on Windows NT®, shortcuts do operate similarly, and take the concept several steps further. If you create a shortcut to an object on an NTFS volume, the object's unique NTFS identifier is recorded in the shortcut and the Distributed Link Tracking Service is used to hunt down that object later on. The Distributed Link Tracking Service can locate the object in relatively straightforward cases where it has been renamed or moved to another directory on the same volume, and it can even track files in more complex scenarios when they have moved from one computer to another—even when a hard drive has been taken out of one computer and installed into another! Let's see you try that with a symbolic link.

Raymond Chen's Web site, The Old New Thing, deals with Windows history and Win32 programming. He still has trouble telling which of the sprouting things in his garden are weeds.