Aaron Czechowski, MCS

Moving on

2012-06-08T19:50:24Z

A long overdue post...

In April I changed roles within the company, leaving Microsoft Consulting Services and joining the Windows Intune product team as a program manager.

This blog will remain, but I currently have no plans to make any further posts. I am continually re-evaluating the latter part of that statement....

Using Windows PowerShell to convert collection membership rules

2012-02-07T17:30:40Z

I developed some automation for a customer to help them manage the lifecycle of collections used for assignment of DCM baselines as they are revised. Part of this required the ability to convert a collection from query-based membership to direct membership rules and vice versa. I realize this is a very niche piece of automation, but perhaps someone else can gain some benefit from these functions.

I used Michael Niehaus’ Windows PowerShell module for Configuration Manager to provide supporting functions and even derived several of the code blocks from his very handy functions. SCCM.psm1 is not technically required for these functions, but I assume it was used to create the connection to the site so that variables such as $sccmServer and $sccmNamespace are available.

There are three functions:

Add-SCCMCollectionDirectRule: this is a helper function used by both of the following. It takes two parameters: a collection object and an array of collection members. (It is a simplification of Michael’s related function.)
Convert-SCCMCollectionToDirect: as the name suggests this will take any collection, capture the current membership, remove the rule and then add the members as direct membership rules. It assumes there is only one query rule and does not refresh the collection membership.
Convert-SCCMCollectionToQuery: the converse of the above; it removes all direct membership rules and then adds the given query rule. It is adapted from Michael’s code with fewer parameters (which could easily be added back for increased functionality).

Function Add-SCCMCollectionDirectRule {

    Param (
        # SMS_Collection object, such as returned from Get-SCCMCollection function of SCCM.psm1
        [Parameter()] $Collection,
        # Array of SMS_CollectionMembers from MemberClassName WMI Class
        [Parameter()] $Members
    )

    # (derived from Add-SCCMCollectionRule in SCCM.psm1 by Michael Niehaus)
    $ruleClass = [wmiclass]"\\$sccmServer\$($sccmNamespace):SMS_CollectionRuleDirect"
    ForEach ( $member in $Members ) {
        $newRule = $ruleClass.CreateInstance()
        $newRule.RuleName = $member.Name
        $newRule.ResourceClassName = "SMS_R_System"
        $newRule.ResourceID = $member.ResourceID

$Collection.AddMembershipRule($newRule) | Out-Null
} # end foreach

} # end Add-SCCMCollectionDirectRule function

Function Convert-SCCMCollectionToDirect {

    Param (
        # SMS_Collection object, such as returned from Get-SCCMCollection function of SCCM.psm1
        [Parameter()] $Collection
    )

# Refresh to make sure we have all of the lazy properties
$Collection.Get()

    # Change the schedule from periodic (2) to manual (1)
    $Collection.RefreshType = 1
    $Collection.Put() | Out-Null

# Get the collection members
$collMembers = Get-WmiObject -Class $Collection.MemberClassName -Namespace $sccmNamespace -ComputerName $sccmServer

# Get the existing query rule, assuming there is only one
$rule = $Collection.CollectionRules[0]

# Delete the query rule
$Collection.DeleteMembershipRule($rule) | Out-Null

# Add members back as direct membership rules
Add-SCCMCollectionDirectRule -Collection $Collection -Members $collMembers

} # end Convert-SCCMCollectionToDirect function

Function Convert-SCCMCollectionToQuery {

    Param (
        # SMS_Collection object, such as returned from Get-SCCMCollection function of SCCM.psm1
        [Parameter()] $Collection,
        [Parameter()] $QueryName,
        [Parameter()] $Query,
        [Parameter()] [ValidateRange(0, 31)] [int] $RefreshDays
    )

# Get all lazy properties
$Collection.Get()

    #Set schedule
    $intervalClass = [wmiclass]"\\$sccmServer\$($sccmNamespace):SMS_ST_RecurInterval"
    $interval = $intervalClass.CreateInstance()
    $interval.DaySpan = $refreshDays
    $Collection.RefreshSchedule = $interval
    $Collection.RefreshType = 2    # periodic (2) vs manual (1)
    $Collection.Put() | Out-Null

    # Delete all direct membership rules
    ForEach ( $rule in $Collection.CollectionRules ) {
        $Collection.DeleteMembershipRule($rule) | Out-Null
    }

# Add query
Add-SCCMCollectionRule -collectionID $Collection.CollectionID -queryRuleNameb $queryName -queryExpression $query

# refresh the collection
$Collection.RequestRefresh() | Out-Null

} # end Convert-SCCMCollectionToQuery function

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

USGCB Policy Bug: Turn off desktop gadgets

2012-01-24T04:26:14Z

The US Government Configuration Baseline (USGCB) group policy object (GPO) for Windows 7 Computer Settings includes the setting:

Computer Configuration\Administrative Templates\Windows Components\Desktop Gadgets
Turn off desktop gadgets = Enabled

This setting is not included in the settings spreadsheet or the associated SCAP content. It was mistakenly included in the GPO and is expected to be removed in a future release. If desired, agencies can safely deviate this setting since the SCAP content does not include it.

NOTE: the three other settings in this policy section are still enabled to control the use of Desktop Gadgets.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation.

Verifying Configuration Manager Backup Task with Windows PowerShell

2012-01-24T03:44:06Z

A seemingly simple requirement for a Desired Configuration Management configuration item is to verify that the Configuration Manager 2007 site backup maintenance task is enabled. What became the difficult part of this was tracking down the specific location in WMI that this data exists. I have to give credit to Jamie Moyer for pointing me in the right direction.

Function Get-SccmBackupEnabled {

    # Refresh the site control file
    Invoke-WmiMethod -Path SMS_SiteControlFile -Name RefreshSCF -ArgumentList $sccmSiteCode -Computername $sccmServer -Namespace $sccmNamespace | Out-Null

    # Get the backup task object for this site
    $bkTask = Get-WmiObject -Query "SELECT * FROM SMS_SCI_SQLTask WHERE SiteCode = '$sccmSiteCode' AND ItemName = 'Backup SMS Site Server'" -Computername $sccmServer -Namespace $sccmNamespace

    If ( -not $bkTask ) { $False }
    ElseIf ( $bkTask.On -eq 'True' ) { $True }
    Else { $False }
}

The key here is the SMS_SCI_SQLTask WMI class, not SMS_SCI_MaintenanceTask as I originally suspected.

This cannot be used as-is in DCM; it must be paired with some code to first create the connection to the site server and then call this function. I use Michael Niehaus’ PowerShell module which works very nicely for many common Configuration Manager automation tasks including the initial connection (New-SCCMConnection).

Using SMBIOS GUID to import computer information for VMware guest

2012-01-04T23:34:00Z

To import computer information into Configuration Manager for OS deployment you have to enter the computer name and then one or both of the following unique identifiers: MAC address or SMBIOS GUID, aka UUID. Many customers use the MAC address because it is shorter and typically more accessible. However, if the UUID is required this can seem difficult to obtain especially when the target systems are VMware guests. When the guest is initially created it is assigned a UUID which is stored in the VMX configuration file as the uuid.bios property. Here is an example line from the VMX file:

uuid.bios = “42 38 d4 b6 00 90 3e 75-94 06 b3 10 ea fa 2b 1e”

This does not look like a usual SMBIOS GUID in the standard (8)-(4)-(4)-(4)-(12) format. When the system boots and attempts to PXE boot, the same UUID is visible although formatted differently, for example:

Network boot from Intel E1000
Copyright (C) 2003-2008 VMware, Inc.
Copyright (C) 1997-2000 Intel Corporation

CLIENT MAC ADDR: 00 50 56 B8 00 14 GUID 4238D4B6-0090-3E75-9406-B310EAFA2B1E
CLIENT IP: 192.168.1.100 MASK: 255.255.255.0 DHCP IP: 192.168.1.10
GATEWAY IP: 192.168.1.1
…

Looking at the actual SMBIOS GUID via the UUID property of the Win32_ComputerSystemProduct WMI class (or the comparable System UUID property on the ConfigMgr System Resource), it appears as:

UUID = “B6D43842-9000-753E-9406-B310EAFA2B1E”

The difference between these two (uuid.bios up above and UUID directly above), which are identical except for formatting, is explained in an older Remote Installation Services article on TechNet. The VMware VMX uses the “raw byte order” format while Windows and Configuration Manager use the “pretty print” format. (Thanks to Michael Kelley for that nugget of information.)

So taking a UUID from a VMware VMX to import into Configuration Manager for OS deployment requires some conversion. The attached script does a simple conversion; there may be a more elegant method relying upon the underlying mathematics of the UUID, but that’s beyond my current knowledge.

The script usage is as follows:

.\Convert-UUID.ps1 -rawUUID "<uuid>"

where <uuid> is formatted as follows:

01 23 45 67 89 ab cd ef-fe dc ba 98 76 54 32 10

such as used in the uuid.bios property of a VMX file. For example, the above rawUUID yields the following output:

67452301-ab89-efcd-fedc-ba9876543210

How to create a bootable ISO

2012-01-04T23:19:52Z

I know this information exists elsewhere in the world and I really dislike redundant posts. But I’m always hard-pressed to find this so am posting it here more as a reminder to myself. If it is of use to anyone else, all the better.

When you update a MDT 2010 Update 1 distribution share that includes the option to create a bootable ISO, the OSCDIMG command (in RunCmd.cmd), as well as a log of the output (PEManager.log), is located at %Temp%\PEManager.####, for example, C:\Users\Aaron\AppData\Local\Temp\PEManager.4336.

RunCmd.cmd contains the following (reformatted for easier readability):

“C:\Program Files\Windows AIK\Tools\AMD64\OSCDIMG.EXE”

-u2
-udfver102
-m
-o
-h
-yo”C:\Program Files\Microsoft Deployment Toolkit\Templates\BootOrder.txt”
-bootdata:2#p0,e,b”C:\Program Files\Windows AIK\Tools\PETools\amd64\boot\ETFSBOOT.COM”#pEF,e,b”C:\Program Files\Windows AIK\Tools\PETools\amd64\boot\EFISYS.BIN”
”C:\Users\Aaron\AppData\Local\Temp\MDTUpdate.4336\ISO”
”C:\Users\Aaron\AppData\Local\Temp\MDTUpdate.4336\LiteTouchPE_x64.iso”
> “C:\Users\Aaron\AppData\Local\Temp\PEManager.4336\PEManager.log” 2>&1

See [some website] for details on the various OSCDIMG parameters.

Disk Cleanup in a MDT Task Sequence

2012-01-04T23:18:00Z

While using MDT to remaster an existing Windows 7 image I added tasks to apply Windows 7 Service Pack 1 and a slew of other updates to the image (so that deployed workstations are up to date out of the gate instead of waiting for updates to come down to each system across the network). Unfortunately this bloated the end product WIM by almost 2 GB. I started to look into ways I could cleanup any unnecessary files on the hard drive before capturing the image. Instead of just hacking away at the disk, deleting temporary files and other caches, I decided to try to integrate the built-in Disk Cleanup utility.

Disk Cleanup, cleanmgr.exe, has command line parameters that are well documented but there is little to nothing on how to automate this, especially in the context of a MDT task sequence. The typical process is to run cleanmgr.exe /sageset:n (where n is an arbitrary integer) and set the files to delete in the interface. This then configures a cleanup profile in the registry so that when running cleanmgr.exe /sagerun:n it has a preset configuration to use.

To automate this for the task sequence I made the decision that every cache type (aka handler) is to be deleted in this scenario, including the one most important to me: Service Pack Backup Files. I wrote the attached MDT-style script that loops through each subkey under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches and sets the StateFlags0042 value to DWORD 2 (in this example, n = 42). There is an article on MSDN that includes an excellent description of the StateFlags value. The script then runs cleanmgr.exe /sagerun:42 to do the needful.

I added this cleanup task to the end of the Custom Tasks group of the State Restore phase (for those of you using the Standard Client Task Sequence). It cleaned almost 3 GB of data from the system, which resulted in the final WIM only growing by 575 MB from the starting custom image (instead of almost 2 GB without the cleanup).

Deploying Windows 7 Language Packs via ConfigMgr

2011-12-19T01:31:15Z

During a Windows 7 64-bit deployment project the customer gave me a requirement to allow users to install a variety of language packs without adding all of them to the baseline image to keep the size down. They are already using ConfigMgr to advertise applications for user self-service so this seemed the most logical method to provide this capability.

Windows 7 language pack setup, lpksetup, includes parameters to support a managed installation. I successfully tested the following from the command prompt:

lpksetup.exe /i de-DE /p . /r /s

I advertised a program with this command line, but it quickly failed. The test system returned an error status message, ID 10003: “An error occurred while preparing to run the program for advertisement…. The operating system reported error 2147942402: The system cannot find the file specified.”

Execmgr.log contained the following:

File C:\Windows\SysWOW64\CCM\Cache\…\lpksetup.exe is not a valid executable file
Invalid executable file lpksetup.exe

I altered the program command line to directly reference the executable at %WinDir%\System32\lpksetup.exe with the same result.

Since ConfigMgr executes from a 32-bit process I launched a 32-bit command prompt (C:\Windows\SysWOW64\cmd.exe) to manually try the lpksetup command line.

C:\Windows\SysWOW64>C:\Windows\System32\lpksetup.exe /?
'C:\Windows\System32\lpksetup.exe' is not recognized as an internal or external command, operable program or batch file.

C:\Windows\SysWOW64>dir C:\Windows\System32\lpksetup.exe
Volume in drive C is OSDisk
Volume Serial Number is 1234-5678

Directory of C:\Windows\System32

File Not Found

It turns out that lpksetup.exe on Windows 7 64-bit is a 64-bit-only process so with WOW file redirection in a 32-bit process C:\Windows\System32 redirects to C:\Windows\SysWOW64, which does not contain lpksetup.exe. So I altered the ConfigMgr program command line to:

%WinDir%\SysNative\lpksetup.exe /i de-DE /p . /r /s

Using the SysNative alias allowed the language pack to be successfully installed on Windows 7 64-bit from a ConfigMgr advertised program.

Windows XP Remote Assistance and DontDisplayLastUserName

2011-12-19T00:57:50Z

While implementing Remote Assistance during a Windows 7 deployment I found that a RA connection to older Windows XP workstations would behave like a Remote Desktop connection: the user would not be prompted to allow the administrator to connect, and the administrator would be prompted to logon. I eventually traced the issue to the presence of the DontDisplayLastUserName value, set to 1, at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. These specific Windows XP workstations were upgraded from earlier versions of Windows, persisting this setting which is deprecated in Windows XP, but causing this problem with Remote Assistance. I applied a custom administrative template to modify this older registry value and RA started to work as expected.

The necessary functionality historically provided by this registry value is applied by enabling the group policy setting “Interactive logon: Do not display last user name” at Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. This policy setting configures the DontDisplayLastUserName value at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Remote Assistance is not affected by the presence of this setting.

Microsoft Support article KB306045 has more detail on this issue.

ConfigMgr query for blocked or approved clients

2011-12-09T01:58:01Z

This is nothing new; I’m typically not one to repost information that can be found elsewhere online. This is just so that I have an easy place to find it in the future!

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_CM_RES_COLL_SMS00001
on SMS_CM_RES_COLL_SMS00001.ResourceId = SMS_R_System.ResourceId
where SMS_CM_RES_COLL_SMS00001.IsBlocked = '1'

Replace IsBlocked with IsApproved to query for approved clients.

Generating a random password with PowerShell

2011-12-09T01:47:50Z

Instead of bashing on the keyboard, I’m a proponent of using a tool to generate a random password, such as when creating a service account or new user accounts. A colleague of mine recently discovered that this is doable with Windows PowerShell, in only two lines!

Add-Type -Assembly System.Web
[Web.Security.Membership]::GeneratePassword($length,$numberOfNonAlphanumericCharacters)

This will return a string using the provided parameters. For example, setting $length = 15 and $numberOfNonAlphanumericCharacters = 6 the output is

uC@#H=}S&K$C!RP

1P*]v)PL99T{$y;

%H2|kK5J{D=(-kl

(You get the idea.)

MSDN provides more detail on the GeneratePassword method. Sadly it only allows up to 128 characters in length.

Identifying a system deployed via OSD

2011-12-09T01:46:55Z

I’m starting a DCM project for a customer and one of the requirements is to determine whether a system was deployed via a ConfigMgr task sequence. This seemed like a simple request but initially stymied me as to how to best implement it with a significant level of authority that cannot be easily circumvented. I came up with the following options, along with input from colleagues:

Key off of a registry or environment variable tattoo. This was rejected as too easy to circumvent making a hand-built system appear compliant. But that could be paired with a WMI tattoo as well, making it slightly more complicated to get around. The MDT Tattoo task could potentially fit the bill for both the registry and WMI branding.
Use a script to parse HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History for entries where _ProgramID = [char]42 (aka “*”), where and then potentially comparing the _RunStateTime with the InstallDate attribute from Win32_OperatingSystem (to within a timeframe such as 12 hours). A bit more complicated to circumvent, but can cause issues when non-OSD task sequences are used, unless the specific package ID is included in the query.
Parse smsts.log.

From this discussion I received an interesting tidbit from Nate Bachmeier, a ConfigMgr SDET, to look for a registry key named CM_DSLID. A quick search on a Windows 7 64-bit workstation yielded the following:

HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion
CM_DSLID = P01:C0100123

HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion
MC_DSLID = C0100045

In this example, P01 is the primary site to which the system is assigned, C0100123 is the task sequence ID (C01 is the central site) and C0100045 is the OS image package ID.

Michael Niehaus pointed out that MDT has some logic in ZTITatoo.wsf to create the second key if _SMSTSPackageID is populated.

Throw more logs on the fire

2011-10-18T03:00:19Z

I was recently having a conversation with a coworker about ways to troubleshoot an automated installation process and describing how to inject further logging into the process. Instead of running the command line setup.exe, I suggested he run a simple command file (setup.cmd) with something like the following:

@echo off
echo %date% %time% > "%temp%\setup.log"
setup.exe /q
echo %errorlevel% >> "%temp%\setup.log"
echo %date% %time% >> "%temp%\setup.log"

The problem was that setup.exe was not generating its usual log files as it would when successfully executing, so this is a simple way to add additional logging to the process to see a timestamp for when setup.exe was called and when it completed. (There are obviously many different ways to add further logging, this is just one simple example.)

The point of this post is that we were standing in the hallway talking about logging and creating more logs. One of our sales guys walked by and jokingly asked, "throw more logs on the fire?" We laughed at his misunderstanding of the conversation, but then it occurred to me that this is a great catch phrase for adding more debug logging.

So the next time you're debugging a tough script or piece of automation, shout it out: "throw more logs on the fire!" You heard it here first.

DCM Error for Invalid or Inconsistent Data

2011-10-18T02:47:22Z

I created a relatively simple Configuration Manager 2007 Desired Configuration Management (DCM) configuration baseline with twenty configuration items (CIs) each with a handful of settings. In trying to move it from a development environment into production, the baseline would fail to import on the first page of the wizard with the following error:

The following file(s) contain invalid or inconsistent data.
Possible causes could be:
    Malformed xml data.
    Invalid schema.
    References to items not in the system or cab file.
    Circular references among items in the cab file.
MyBaseline.cab - The cab file references missing content or contains a circular reference.

I found some other references to this error when using truly custom XML, but this content was generated using the DCM interface. Both development and production environments are assumed to be identical (more on that later).

I extracted the XML from the cabinet and used the DCM Model Verification Tool from the ConfigMgr Toolkit. Two of the twenty CIs contained the following fatal error:

<Error Severity="6" Fatal="True" Path="/tns:DesiredConfigurationDigest[1]/tns:BusinessPolicy[1]/tns:Parts[1]/tns:File[4]/tns:PropertyRules[1]/tns:DateModified[1]/tns:Rule[1]">[ValidRuleSemantics] This rule only takes 1 argument.</Error>

and four of them had non-fatal warnings similar to the following:

<Warning Severity="1" Fatal="False" Path="/tns:DesiredConfigurationDigest[1]/tns:BusinessPolicy[1]/tns:Parts[1]/tns:File[4]/tns:PropertyRules[1]/tns:ProductName[1]/tns:Rule[1]">[ValidRuleSemantics] Potential list operand specified with unary operator.</Warning>

I tried modifying the CI XML in an effort to remove the errors and warnings, but the validity of the XML turned out to be a red herring. On a tip from Kevin Myrup, I removed the software update CIs in the baseline, exported it again and was then able to import with no errors. As it turned out the two environments were not identical, the specified software updates were not synchronized and available in the production environment, thus the errors. According to Kevin if the updates are available at the target site then the baseline will import with the software update CIs included.

An interesting side note: while troubleshooting this I discovered that when importing a baseline the ConfigMgr Console will cache the .CAB at %AppData%\Local\Microsoft\SCCM\DCM\Import\{<GUID>}-CabCache\<ImportFile>.cab and extract all of the .XML and .RESX files contained within at %AppData%\Local\Microsoft\SCCM\DCM\Import\{<GUID>}\<ImportFile>.cab\*.

DCM and Two's Complement

2011-08-25T01:18:48Z

My mathematics and computer science lesson for the day came when creating a Desired Configuration Management (DCM) configuration item (CI) setting for the TCP/IP v6 DisabledComponents registry value. (See Microsoft Support Article ID: 929852, How to disable certain Internet Protocol version 6 [IPv6] components in Windows Vista, Windows 7, and Windows Server 2008 for more information.) With the appropriate group policy settings applied to the target Windows 7 workstations, HKLM\SYSTEM\CurrentControlSet\Services\TCPIPv6\Parameters\DisabledComponents was set to REG_DWORD 0xffffffff, which the Registry Editor so kindly translated to the decimal value 4294967295.

In the DCM CI I created a new registry setting with the validation for this value. With the data type set to Integer, entering this large value resulted in the text validation error (red exclamation point next to the field), "Invalid integer value." So I changed the data type to Floating Point, which allowed it to accept 4294967295.

However, when I tested this against a target system it evaluated non-compliant. The current value of the setting showed to be -1, which obviously is not equal to 4294967295. I modified the CI setting to validate the registry value as an Integer data type, value -1, and the client then evaluated this as compliant.

Perplexed, I sought the reason behind why the REG_DWORD value 0xffffffff is interpreted as -1. I discovered the computer arithmetic concept of two's complement. Pulling up the Windows 7 Calculator in Programmer mode, I switched to Hex and Dword, typed FFFF FFFF, and then switched to Dec mode, which translates to -1.

While the mathematics behind this is still a bit over my head (a math major friend from college commented, "Two's complement rears its elegant ugly head") I thought I would share this for the fun (albeit dorky) lesson and yet another interesting quirk with DCM.

Windows PowerShell Script Library for MDT

2011-06-29T19:23:00Z

At the Microsoft Management Summit 2011 in March I presented session BF21, Accelerated Scripting with the MDT Framework. The session focused on using the VBScript libraries built-in to MDT to reduce the amount of time to write custom scripts and using a common framework and best practices for more lasting scripts. Some of the advantages of using the MDT framework are a common logging format and location, shared environment variables, and a whole library of helper functions for common deployment scripting activities.

The MDT 2010 scripting framework is VBScript-only so that it will function in all supported operating system versions, including WinPE. Windows PowerShell requires the .NET Framework, which unfortunately is not currently in WinPE. There are still many scenarios in which Windows PowerShell could be quite advantageous when integrated with the MDT scripting framework. You can execute powershell.exe with a .ps1 script from a task sequence, but you then lose all of the advantages offered by the MDT scripting framework.

So I started work on a Windows PowerShell library in the same vein as the ZTIUtility.vbs script library in MDT. The goal was to recreate some of the functions, objects and properties in the same spirit, not just explicitly rewriting the VBScript in Windows PowerShell. Due to limited resources I had to prioritize the scope: first focusing on common logging, then the shared environment variables, and finally building the library of helper functions.

(NOTE: I had hoped to release this right after MMS, possibly with some additional revision to the script, but unfortunately that was not possible. So I'm posting this now as-is. It is still a work-in-progress; but I hope by making this available others can benefit from it and/or build upon it.)

The method that I used to integrate the library with a custom Windows PowerShell script is by simply dot-sourcing the library at the top of the custom script. Other methods (e.g., Windows PowerShell module) may achieve better results.

# // ...Script Header...

# // Load Library
$LocalPath = split-path -parent $MyInvocation.MyCommand.Definition
. $LocalPath\Z-Utility.ps1

# // Another brilliant PoSh script goes here!

Z-Utility.ps1 v1.0 Alpha Features

Common logging

Standard log format for easy viewing in Trace32
Location is the task sequence log path (_SMSTSLogPath) if it exists, otherwise the current TEMP directory
Handles standard log entry types: Info, Warning, Error, Verbose
Strings with passwords are masked (except when DEBUG = TRUE)

Common environment

If running from a task sequence, convert the task sequence variables to Windows PowerShell variables. For example, $Architecture = X64, $IsLaptop = True, $Make = Dell Inc., $SerialNumber = G3YGTF2, etc.

Helper functions

RunWithHeartbeat: Execute a command with the provided arguments, log the full command, log a message at a defined "heartbeat" interval, and log and return the exit code.

The library will function via a Windows PowerShell script executed directly or via a task sequence, but currently it works best when called from a task sequence (to leverage the existing log path and environment variables). To execute the script from within a task sequence, create a Run Command Line task with the following example Command line:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%ScriptRoot%\Custom\CustomScript.ps1"

Attached to this post are two files, the Z-Utility.ps1 (v1.0 Alpha) script library, and CustomScript.ps1, which simply demonstrates the current functionality of the script library.

Maximizing Security in Configuration Manager

2011-06-29T03:18:00Z

This post details my experience and lessons learned with hardening a System Center Configuration Manager system. I'll review the risks and then describe the various technical components of a ConfigMgr system: Windows Server host, Internet Information Service (IIS), SQL Server and ConfigMgr itself. Make sure to review the current product documentation on Security for Configuration Manager 2007 before continuing.

First let's look at some of the risks inherent to ConfigMgr.

Scope of management: What types of systems are to be managed? Is it just workstations? IT administrators, accounting, HR, mobile users? Is the system managing servers as well? Domain controllers, Exchange, SharePoint, SQL?
Data collection: There is an enormous wealth of data that can be collected from ConfigMgr clients with hardware and software inventory, much of which could be very useful to a malicious user planning an attack. However also consider that software inventory provides the ability to obtain any file by name from the client and pull that back centrally.
Software distribution: Most folks think of software distribution in terms of installing software on the managed clients. But an administrator could package external utilities such as the SysInternals Suite or custom scripts, or use it to execute command lines built-in to Windows, all under the context of the Local System.
OS deployment: You have to be very careful about the scope of management and the scope of deployment with OSD. For example, I would expect that Windows 7 probably screams when running on server hardware.
Vulnerability reports: There is extremely valuable information to an attacker in the default reports. Update and configuration compliance can be used to find vulnerable systems on the network.
Network consumption: ConfigMgr could be misused for a massive denial of service by flooding the network with data and consuming all bandwidth between sites by simultaneously updating all distribution points or pushing multiple large packages to all clients.

Windows Server Host General Security Considerations

Make sure the latest service pack is applied (as supported by the SQL and ConfigMgr product teams!), and that the security and critical updates are current.
Use the Security Compliance Manager (SCM) Solution Accelerator to leverage a standard security baseline, such as the Specialized Security - Limited Functionality (SSLF), and then create delta policies to relax settings as necessary (see more on this below).
Use the Security Configuration Wizard (SCW) local utility to create a local configuration policy, to include lockdown of services, file permissions, firewall rules, and registry configurations. The ConfigMgr Toolkit includes a SCW template to provide ConfigMgr role-specific settings into the wizard. On Server 2008 and later you will need to use the updated SCW template.

Windows Server: User Rights Assignment

These were determined through analysis of the system during installation as well as review of the product documentation. The SQL Server documentation in particular has excellent details on the specific security rights and permissions that are required for service accounts.

Adjust memory quotas for a process (SQL 2008)
Bypass traverse checking (SQL 2008)
Impersonate a client after authentication (IIS 7)
Log on as a batch job (IIS 7)
Log on as a service (SQL 2008)
Replace a process level token (SQL 2008)

The following two rights are not typically required with ConfigMgr on Server 2008 R2. Debug programs is not required for installation or runtime, but you can’t upgrade or uninstall any ConfigMgr components unless the logged on user has this right. The Server 2003 SSLF Member Server baseline removed this right from the local Administrators, but that is no longer the case with the Server 2008 R2 SSLF member server baseline. IIS 7 changes the way in which it allows anonymous access so the right, Deny access to this computer from the network, is no longer necessary either.

Windows Server: System Services

The SSLF baseline does not enforce any system service restrictions, so I developed additions to the delta policy based upon analysis of the system, output of the Security Configuration Wizard, and information from the Threats and Countermeasures documentation for Windows Server. The ConfigMgr SCW template can help with the services configuration for product-added services that are required. Careful analysis is required of the various components in the specific customer environment to determine whether individual services are required or not. Disabling default system services may reduce the attack footprint of the server, but is not recommended due to the likelihood of system instability and establishment of an unsupported state.

Service configuration can also be used to block additional components that may be inadvertently added. For example, the policy can include explicit settings to disable services like Active Directory Domain Services, Client for NFS, FTP Server, Remote Desktop License Server, or Windows SharePoint Services so that even if a system administrator attempts to add the component in the future, it cannot run due to policy.

Windows Server: Security Options

There are a few additional settings that may need to be included with the ConfigMgr delta policy.

MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames
ConfigMgr 2007 requires that NTFS 8.3 name creation is enabled due to an issue with Windows Installer and the ConfigMgr Administrator Console. The Server 2003 SSLF member server baseline enables this setting which disables short file name creation, but this is no longer the case with newer baselines.
MSS: (AutoShareWks) Enable Administrative Shares
MSS: (AutoShareServer) Enable Administrative Shares
ConfigMgr clients must have the Windows administrative shares, such as admin$, enabled in order to be properly managed. While these two settings are not included with the SSLF baseline, other security guidance may recommend the use of these settings.
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
FIPS is one of the most commonly deviated settings because it will quickly break many products that do not use FIPS-compliant algorithms. I have yet to find any aspect of a ConfigMgr system that is significantly affected by enabling FIPS, with one (optional) exception: SQL Server 2008 Reporting Services (see below).

Windows Server: Windows Firewall

Windows Server 2008 R2 SSLF Member Server baseline requires the use of the Windows Firewall and blocks all incoming connections. While there are good in-box rules to allow common functions such as file sharing and remote administration, custom rules will need to be defined to allow ConfigMgr clients and other site systems to access the site server. This is best configured via the delta group policy for ConfigMgr so that the connection rules are centralized and enforced. The ConfigMgr documentation has a very thorough data flow diagram for all necessary network connections: Ports Used by Configuration Manager.

SQL Server

With SQL for ConfigMgr the only requirement is the Database Engine and nothing else. Unless of course you’re using a Reporting Services Point in which case you’ll also need to add Reporting Services. Ideally you just install the database and then components such as the Tools and Docs can be installed on a workstation for remote administrative use. I typically add the Tools and Docs along with the Database Engine simply for convenience. As with Windows, make sure SQL is patched (as supported by ConfigMgr!) and apply the latest cumulative update. The Best Practices Analyzer is useful to review your configuration settings against known SQL best practices.

I always disable the SQL Browser service as part of the SQL hardening, which can make it difficult to connect to the database from a remote system, such as a child site server or proxy management point. By installing the SQL Native Client on the remote system and configuring a SQL connection alias, this will provide a pathway to the SQL database engine on the ConfigMgr site server. This maintains the SQL hardening so that it is not discoverable on the network but provides the same functionality for the remote endpoint.

The use of service accounts is a SQL best practice instead of local system or other built-in service accounts. A domain service account is required for ConfigMgr in order to provide Kerberos authentication. So then you have to ensure that the service principle names (SPNs) are set correctly for both the NetBIOS and Fully Qualified Domain Name of the server with the correct TCP port. Alternatively, you can assign the Write Public Information permission to Self on the SQL service account.

Note that it is not supported to change the SQL listening port for SQL Server instances hosting Configuration Manager site databases. Use of a named instance is recommended for a variety of reasons, namely a non-standard configuration and the associated non-standard port. The following Microsoft Support article should be used to set a static port for named instances: How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port. This is needed for static configuration of Windows Firewall rules and SQL Native Client connection aliases.

Since the delta policy has to deviate several user rights assignments for SQL to function, a large environment with multiple sites will need multiple SQL service accounts for each site. Instead of requiring a modification to the security policy when a new SQL service account is needed, I recommend the use of a local security group on each server. The domain SQL service accounts are added to the local group, and the local group is specified by name in the delta policy for each of the necessary user rights assignments.

Finally, there is a security configuration inside the SQL Server Configuration Manager on the network configuration for the instance where you can add a certificate (the same one used by IIS if desired) and then force encryption for connections to the server. See Encrypting Connections to SQL Server for details on configuring this. This configuration option can also prevent the SQL Server Browser service from making the instance known to client computers, which is good to specify even if the SQL Browser service is disabled. As ConfigMgr typically uses a dedicated SQL server there is no need for any system on the network to be able to discover the instance without previous knowledge of its existence.

There are two modifications that need to be made to for this configuration to function with ConfigMgr. First, the domain SQL service account needs rights to the private key. Previously with Windows Server 2003 you needed to use the winhttpcertcfg utility. With Windows Server 2008 R2 it's as simple as opening the Certificates console for the Local Computer, right-clicking the certificate, selecting All Tasks and selecting the Manage Private Keys option. By default SYSTEM and Administrators have Full Control, so the domain SQL service account should be added with Read permission.

The second modification is in the SQL Server Management Studio. In the Security node, open the properties of the NT AUTHORITY\SYSTEM context, select User Mapping, select the master database and add the db_owner role. This may be overly generous, but does allow remote client connections, for example from a child site server, to automatically raise the encryption level during the connection negotiation.

SQL Server 2008 Reporting Services

For SSRS to function with FIPS-compliant algorithms, ASP.NET must be configured to use 3DES:

Edit <Drive>:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportManager\Web.config.
Navigate to the <system.web> section and add the following:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
Save and close Web.config.

(These steps are from Xiao Min Tan.)

Internet Information Services

First review the Best Practices for Securing Site Systems for general guidance but also specific to IIS. The primary guidance is to use role separation so that IIS is only installed for site systems that require it.

IIS 7 on Server 2008 or IIS 7.5 on Server 2008 R2 requires a custom script run after installation to move the Inetpub directory. After the installation of IIS it’s easy enough to run a configuration script to create the custom website and port for use by ConfigMgr, which must be named SMSWEB.

Remove the default content so that when accessing the base server URL it does not return the default, sample “Welcome to IIS” content. This default content is not needed; it can be safely deleted without impacting ConfigMgr or WSUS. The websites can also be configured to disable default content so that another administrator can’t drop an index.htm file into a directory that will be the first page to load. While SSL is the default for Native Mode sites, if possible, SSL should be enabled and enforced for reporting in Mixed Mode sites.

Some will argue whether these sorts of customizations are necessary and can be considered a security feature. Every customer security team with which I’ve worked prefers non-standard configurations. While "security by obscurity" is not going to stop a determined attacker from accessing the system, multiple layers of these configurations can deter some attackers and slow down others.

Configuration Manager

Leverage the custom website and custom port defined during the IIS configuration. During configuration of the ConfigMgr site, there’s a checkbox in the Site settings that allows the data to be encrypted between the client and management point. It’s a very simple thing, which does add some overhead because both the client and the server are now encrypting the data, but it definitely adds a significant additional layer of security. See How to Encrypt Client to Management Point Data in Mixed Mode for details.

Block console access to TechNet, similar to the Internet Communication Management settings in group policy. Add a DWORD value named DisableHomePage in the registry key HKLM\Software\Microsoft\ConfigMgr\AdminUI. (See How to Prevent the Home Page from Downloading the TechCenter Page on Microsoft.com).

Use Native Mode security when possible, but when using Mixed Mode security ensure it is Active Directory-integrated for centralized trust.

Use the advertisement option to Download...and run locally. While you have to ensure you properly configure and manage the client cache, the client will checksum the content after it is downloaded and compare against the hash of the original package source, not just what’s on the distribution point. This helps protect against a man-in-the-middle attack by ensuring the content is valid prior to execution.

I recommend the use of what I call an installation service account. This is just a normal user account in Active Directory with no additional rights at first. You can assign the specific rights that are necessary in the environment, such as administrative rights to the site server, sysadmin rights to SQL, etc. Then all of the product installation and configuration is done under the context of this service account. When all is done the rights are taken away and the account is either deleted or disabled for potential future use. The idea is that this is a well-scoped security context during installation. If you use the administrative account of a member of the implementation team, they may have other permissions elsewhere that may affect the outcome of the installation. If you have control over the scope of the installation then you know exactly what it can and cannot do.

The Network Access and Domain Join accounts are typical service accounts that are often required. The Network Access service account is a very low rights user in Active Directory, used purely for authentication to the server when other methods of authentication are not available (such as in Windows PE during OS deployment). The Domain Join account will need additional permissions in Active Directory to allow computers to be automatically joined to the domain during OS deployment, but those permissions can be carefully scoped to a specific OU.

I recommend avoiding Client Push Installation. This is one area where the concept of security versus functionality really comes out. From a functional standpoint, client push is great: right-click, install client. From a security standpoint, however, it requires storing administrative credentials, of either a named administrative user or a generic service account with administrative rights. I don’t think either of these options is worth the functional gain, especially when there are many other methods by which the client can be installed.

Finally, Active Directory security groups should be used for various roles that are required to access the system: Administrators, Operators, Reporting Users, Auditors. This is just an example of a few; a large environment will probably have many more roles, especially of the operational type: this group installs software, this group installs updates, etc. With ConfigMgr 2012 these can be easily assigned to specific roles in the console, whereas with ConfigMgr 2007 you have to assign the specific rights for each class to the security group.

The Auditors group can be added to the SMS Admins local group on the site server, but no additional rights in the ConfigMgr 2007 console. This will allow an auditor to open the console, see all of the nodes and the security of each, but no other content in the console. It’s a great way to give the auditing team or security team access to view the rights in the ConfigMgr console without granting rights to see anything else.

Other Security Considerations

IPsec between site servers to ensure that intersite communication is secure and/or encrypted
Additional WSUS lockdown to enforce SSL and requiring mutual authentication
Additional SSRS lockdown
WDS/PXE security
DCM for component configuration compliance

In planning for a secure ConfigMgr implementation make sure to look at each component individually. The product teams for Windows, IIS, SQL, WSUS, etc., have provided some great documentation on how to secure that component. They must be kept in the context of the integrated ConfigMgr system, however, as they all must work together for a secure and functional system.

There are a lot of best practices and security standards from both Microsoft and other parties. Standard baselines should be used whenever possible as they have already undergone some level of testing so will help accelerate your work.

Even in environments that don’t have rigorous corporate, government or regulatory requirements for security, these configurations can be implemented to raise the security level of the ConfigMgr system and its components. There are risks with every ConfigMgr implementation and these are practical methods that can be used in any environment to help secure the system.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation.

MMS 2011 Labs powered by Hyper-V, System Center & HP...

2011-03-30T00:32:54Z

I usually don't cross-post, but this is just too cool.

http://blogs.technet.com/b/virtualization/archive/2011/03/29/mms-2011-labs-powered-by-hyper-v-system-center-amp-hp.aspx

Error starting RemoteFX VM with unsupported GPU

2011-03-14T01:00:07Z

A bit off-topic for most of the posts on this blog...I didn't see this posted anywhere else in this context so I thought I'd share. I'm working on a RemoteFX prototype for a customer and have a HP Z600 Workstation with a Nvidia Quadro NVS 450 video adapter that I'm using as the server running Windows Server 2008 R2 SP1 with Hyper-V and RemoteFX. When trying to start the virtual machine Hyper-V Manager returns the following error.

An error occurred while attempting to start the selected virtual machine(s).
'rfx01' failed to start.
Microsoft Synthetic 3D Display Controller (Instance ID {GUID}): Failed to Power on with Error 'Insufficient system resources exist to complete the requested service.' (0x800705AA)

I examined the Applications and Services Logs\Microsoft\Windows\RemoteDesktopServices-RemoteFX-SessionManager\Admin log and found the following:

Event ID: 14
Level: Error
Description: The GPU named NVIDIA Quadro NVS 450 does not meet the minimum requirements for RemoteFX. This GPU will not be used for Remote FX. GPU: NVIDIA Quadro NVS 450.

Event ID: 3
Level: Critical
Description: The GPU or system resources are insufficient for this server to run as a RemoteFX host. Verify this server's hardware against the requirements. Status Code: 10.

While the error when starting the VM is a bit cryptic the others are fairly self-explanatory.

Nvidia has a blog post that lists their current GPUs that support RemoteFX; the Quadro NVS 450 did not make the cut.

MMS 2011 Session

2011-03-14T00:32:26Z

A little self-promotion....

BF21 Accelerated Scripting with the MDT Framework

Speaker(s): Aaron Czechowski
Track(s): Server Management Technologies, Solution Accelerators, Systems Management
Session Type: Breakout Session
Product(s): Configuration Manager 2007 R2 & R3, Microsoft Deployment Toolkit, Solution Accelerators, Windows PowerShell

This session will help you accelerate and standardize your VBScript or Windows PowerShell scripts using a proven framework. We will demonstrate helper functions from the Microsoft Deployment Toolkit script library as well as a new Windows PowerShell library, and how you can incorporate your custom scripts. Topics include simplified logging, a shared variable environment, common functions, accessing INI/XML files, use within MDT and ConfigMgr task sequences, and general best practices.

WSF whatif parameter

2011-01-12T01:03:24Z

Writing custom scripts for MDT and/or MDT-integrated ConfigMgr task sequences should leverage the common scripting framework in MDT (WSF script referencing ZTIUtility.vbs) to take advantage of the provided features, such as:

centralized logging (e.g, C:\MININT\SMSOSD\OSDLOGS)
shared environment variables
helper functions for common tasks

When using this scripting framework it can be complicated to test a script and/or entire task sequence without having it actually perform what it is intended to do. The /debug:true command-line parameter will enable any oLogging.CreateEntry commmands of type LogTypeVerbose which can be used to provide more detailed logging output, but the script will still execute the desired commands. PowerShell provides a standard -whatif parameter that describes what would happen if you executed the command without actually executing the command, so I developed the following add-ons for WSF scripts and task sequences to provide a similar functionality.

This is done by creation of a new command line parameter, /whatif:#. This parameter accepts an integer value (#) which is used during script execution as the return code from any command that would be executed. For example:

cscript %DeployRoot%\Scripts\Custom\INSTALL-ReportViewer.wsf /debug:true /whatif:0

In this example the INSTALL-ReportViewer.wsf script will be run with debug enabled (so all LogTypeVerbose entries will be written), whatif processing will occur, and the sample return code will be 0 (success).

The WSF script must be modified such that any line that performs any modification to the system is configured to handle the whatif parameter. Consider the following sample lines from the original INSTALL-ReportViewer.wsf:

sFile = oUtility.ScriptDir & "\source\reportviewer.exe"
iRetVal = oShell.Run("""" & sFile & """ /q:u /c:""install /qb""", 0, True)

This needs to be modified as such to handle the new whatif parameter:

sFile = oUtility.ScriptDir & "\source\reportviewer.exe"
sCmd = """" & sFile & """ /q:u /c:""install /qb"""
If Not oEnvironment.Exists("whatif") Then
    oLogging.CreateEntry "INSTALL ReportViewer: about to run the command: ", & sCmd, LogTypeInfo
    iRetVal = oShell.Run(sCmd,0,true)
Else
    oLogging.CreateEntry "INSTALL Report Viewer: **DEBUG** WhatIf command: " & sCmd, LogTypeVerbose
    iRetVal = oEnvironment.Item("whatif")
End If

It results in more lines of code in the script, but allows for greater functionality when running the script.

To add this functionality into a task sequence for tasks that do not execute a WSF script (e.g., Add Role or Feature), the following condition can be set to skip the task when whatif is enabled:

If none of the conditions are true
Task sequence variable whatif exists

(This logic is for the MDT task sequence engine, the ConfigMgr task sequence engine logic may be slightly different.)

If the whatif environment variable is set before or during execution of the task sequence, then a task with the above condition will be skipped.

The whatif parameter, along with /debug:true, allows for detailed testing of the script and task sequence without "arming" either with a destructive payload. Since no changes will be made to the system the script or task sequence can be quickly run repeatedly to test functionality during development. The real benefit of this is gained by adding detailed LogTypeVerbose log entries to the script so that the log file can be analyzed to trace the script.

Texts with my wife

2010-09-03T01:55:11Z

This is probably the only place where I can post these and get some level of appreciation. While I was at TechReady in July, I sent texts to my wife who sent back some witty replies. I must note that while she might come off quite dim, it's all meant in jest.

A: Ok, I'll be fresh out of a session on Opalis. :)

D: I didn't realize this was a gem show! Do they have rubies? I much prefer those over opals.

D: R u lrng about sapphires today?

A: Not today - office volume activation right now - woot!

D: I cld teach this one. The more volume in a room the more active it is. Noise volume that is.

A: I need to go learn about SQL Replication

D: I thought squirrels replicated themselves quite well-a lot like bunnies. I think you should be learning about computer thinga ma bobs and not squirrels. First it is gems and now rodents-something is amiss.

D: Hope u r having a good day-no squirrel duplications today?

A: Not today. Highlight so far was vNext migration lab with wally always a fun time. User data virtualization was insightful too. DCM right now.

D: I hope it is a good concert. Dcm is not as well know as their brother band dmb!

A: Just one more session on driver deployment, then i'm done!

D: Alright now i really know this is not a business trip. Driver deployment sounds like a handy name for a golf game or what the dmv shld call their lisc dept.

Running netsh in ConfigMgr task sequence on x64 client

2010-07-09T21:04:00Z

In deploying Windows 7 x64 via a ConfigMgr 2007 SP2 task sequence I have a custom script to change the TCP Global Receive Window Auto-Tuning Level. The command that is executed via the script is:

cmd /c netsh interface tcp set global autotuning=highlyrestricted

This unfortunately returned the following error:

Set global command failed on IPv4 The parameter is incorrect

Since ConfigMgr 2007 task sequences execute as a 32-bit process, and by default use 64-bit file redirection, the shell process in use is C:\Windows\SysWOW64\cmd.exe (which is the 32-bit version on a 64-bit client). By setting the option Disable 64-bit file system redirection on the Run Command Line task, the shell process used is C:\Windows\System32\cmd.exe (the 64-bit process). When the same command is executed in this context, it simply returns the expected, "Ok."

See the Windows Core Networking post, Receive Window Auto-Tuning on Vista, for more information about this setting and why you may need to change it in some circumstances.

The attached file includes my custom WSF script for this.

Failure on invalid user context with DCM permission evaluation

2010-05-26T03:20:04Z

I’m a huge fan of the Desired Configuration Management (DCM) feature of ConfigMgr. However, I found that it can be quite literal with the input data, and the result is not always very user friendly. For example, I created a new General Configuration Item (CI) with a single object rule to evaluate just the exclusive permissions on %WinDir%\System32\cmd.exe (no instance count or attribute verification). The expected permissions were that Administrators and SYSTEM have Full Control, but nothing else.

The interface enforces entry of the user or group prefaced with the context (e.g., domain\username), but doesn’t provide any additional guidance. The available documentation notes that, "If you are specifying the name of a built in group or user, use the form BUILTIN\USER." So I added two entries: BUILTIN\Administrators and BUILTIN\SYSTEM. I then added the CI to a baseline, assigned it to a target collection, and updated policy to receive and evaluate the configuration.

The evaluation report from the client control panel showed an evaluation failure:

Source: /system/schema/ScopeID_2DF32CAA-6275-4EFD-98D4-1A1C4B24B826_BusinessPolicy_8092b0b8-27e6-4696-a33c-7b5262e4a0e1_2
Category: RuleProcessingError
Severity: ERROR
Message: Exception 'System.Xml.Xpath.XpathException' occurred while evaluating the expression 'mssmltrans:sdEquals(@RealSD,concat('D:',mssmltrans:sdTranslate('(A;;0x1F01FF;;;{BUILTIN\Administrators})'),mssmltrans:sdTranslate('(A;;0x1F01FF;;;{BUILTIN\SYSTEM})')), 'Access', 'ocsj')': Function 'mssmltrans:sdEquals()' has failed.

The Application event log on the client shows an error of event ID 11864 from source SmsClient with the description: "Baseline content ScopeID_..., version 2 has model violations." The same message appears as a status message from the client on the primary site server.

All of this had me quite stumped, but some of the text inside of the error (A;;0x1F01FF;;;) looked like security descriptor definition language (SDDL), and with the names of functions like sdTranslate and sdEquals, I decided to take a look at the security descriptors on the file.

I ran the following command on the client to display the SDDL

cacls c:\windows\system32\cmd.exe /s

which yielded:

"D:(A;;0x1200a9;;;IU)(A;;0x1200a9;;;SU)(A;;FA;;;BA)(A;;FA;;;SY)(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-2037546026-41271002)"

So I knew I was on the right track. As I was working with this I happened to run cacls without the /s parameter, which yielded:

NT AUTHORITY\INTERACTIVE:R
NT AUTHORITY\SERVICE:R
BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
BUILTIN\Administrators:F
SRV03\TelnetClients:R

It was at this point that I smacked my forehead. I revised the CI replacing "BUILTIN\SYSTEM" with "NT AUTHORITY\SYSTEM" and upon re-evaluation, no more failures. (The client was non-compliant with the CI, but at least was able to successfully evaluate the setting.)

This was most certainly user error; I should have known better to use the NT AUTHORITY context for SYSTEM instead of BUILTIN. However, in my opinion, the client did not do a good job of reporting the error, the CI interface did not do a good job of providing context-sensitive help, and the product documentation did not provide a broader scope of available options. The client reporting an error such as, "User BUILTIN\SYSTEM not found" (perhaps with the additional debugging detail) would have been more useful.

DCM Multiline Operators

2010-05-03T00:32:00Z

I recently had the opportunity to use the One of operator on a CI validation of a registry integer value. While trying to input the multiple values (1, 3, 4 or 5) using a variety of delimiters (space, comma, semi-colon, etc.), I kept getting a UI error: "Invalid integer. Specify one value per line." The UI does not appear to provide the ability to enter multiple lines in the text control field, but I was able to copy/paste from Notepad and make it work. I later discovered that you can type the first value and then press CTRL + Enter to insert a new line for the next value. Once multiple lines are present, the scroll arrows on the text field are enabled. The Expression field will display the values with what appears to be a space between each, for example:

[TestSetting] One of 1 3 4 5

This should also hold true for the None of operator.