January, 2012

Now that Configuration Manager 2012 RC2 is available, people will certainly start updating their labs – and finding out that the SQL version check in the ConfigMgr installer is looking for some very specific SQL maintenance levels.  (I’ve pulled out plenty of my own hair doing this recently.)  The release notes cover the supported versions:

Supported versions of SQL Server 2008 for RC2:

• SQL Server 2008 SP2 Standard and Enterprise CU7
• SQL Server 2008 R2 SP1 and CU4
• SQL Server Express 2008 R2 and CU4

If you are running SQL 2008 SP2, install CU7 from http://support.microsoft.com/kb/2617148. If you are running SQL Server 2008 R2 SP1, use CU4 from http://support.microsoft.com/kb/2633146.  If you aren’t yet on the needed service pack levels, upgrade now, then install the cumulative updates :-)

Many of you have customized the MDT 2010 wizards, and I expect that will be fairly common with MDT 2012 as well – after all, one of the design goals with having HTA-based wizards is to enable customization by creative IT pros.  But the process is going to be slightly different with MDT 2012.

First, let’s review the basic process most of you would go through with MDT 2010:

• Download the MDT Wizard Editor from http://mdtwizardeditor.codeplex.com/.  This makes editing the wizard simpler (although not necessarily trivial – there can still be a fair amount of work to do, depending on the extent of the changes that you intend to make).
• Open the “DeployWiz_Definition_ENU.xml” file and make the necessary changes:  Adding new panes, changing the HTML and properties of existing pane, etc.
• Using Notepad or any other text editor, add any custom scripting to DeployWiz_Initialization.vbs or DeployWiz_Validation.vbs.
• Test out all the changes using the MDT Wizard Editor, or if this isn’t possible (due to conditions on the wizard pane or logic contained in the pane itself) drop the changed files into the deployment share and try a deployment.

So it’s quite reasonable for you to try the same thing with MDT 2012.  But you’ll quickly discover that you can’t get very far.  You can open the file, but as soon as you click on one of the wizard panes in the left-hand column, you get this exception:

So what causes this?  Well, if you look at the files in the deployment share, you’ll notice that there are quite a few more that start with “DeployWiz”.  That’s because the entire wizard has been restructured.  Instead of having one set of large files (DeployWiz_Definition_ENU.xml, DeployWiz_Initialization.vbs, DeployWiz_Validation.vbs), there are now separate files for each wizard pane (e.g. DeployWiz_ComputerName.xml and DeployWiz_ComputerName.vbs).  The original files (DeployWiz_Definition_ENU.xml, etc.) are still around, but are much smaller – the bulk of the content has been separated out.

Why was this done?  Mainly because it makes the wizard code much easier to maintain.  It’s now much more obvious what script pieces are used for which wizard panes.  Additionally, it makes the wizard easier to test, as you can work on a single pane at a time without worrying about breaking another unrelated pane.

The individual panes are then tied together by the DeployWiz_Definiton_ENU.xml file.  If you look at this file, you’ll see that it’s pretty short, with entries like this:

<Pane id="SelectTaskSequence" reference="DeployWiz_SelectTS.xml">
    <Condition><![CDATA[UCASE(Property("SkipTaskSequence"))<>"YES" ]]></Condition>
</Pane>

All that is there is a reference (or link) to the separate files for each wizard pane, along with the conditions for when each wizard pane should be displayed.  (This helps with the testing as well:  By keeping the conditions in the DeployWiz_Definition_ENU.xml file instead of in the individual wizard files, those conditions don’t get in the way of “offline testing”, e.g. running just that one single wizard pane without going through a full deployment.)

So why does that cause problems with the Wizard Editor?  Simple:  It doesn’t understand that the wizard pane body is in a separate file.  It can’t follow the reference link (highlighted in yellow above) to the separate wizard pieces.  So does that mean the Wizard Editor is no longer useful?  Not at all – you can still use it to work on (and test) individual pages like DeployWiz_ComputerName.xml:

But you’ll need to edit the DeployWiz_Definition_ENU.xml file by hand.

I’m working on a new version of the Wizard Editor in my “free time” so that it learns how to follow these links (with other improvements added in too), but it might take a while before I can complete that work.

So what does the recommended workflow look like if you wanted to add a new wizard pane to MDT 2012?  Here are the basics:

• Download the MDT Wizard Editor from http://mdtwizardeditor.codeplex.com/.
• Make a copy of files for one of the wizard pane files.  For example, copy DeployWiz_AdminPassword.xml as “MyPane.xml” and DeployWiz_AdminPassword.vbs as “MyPane.vbs”.
• Use the Wizard Editor to customize and test the new wizard pane.
• When you are happy with the functionality of the new wizard pane, add an entry for it into DeployWiz_Definition_ENU.xml (just like all the others, with any conditions that you might need), then test it out as part of a normal deployment.

This new flow has another advantage too:  It makes it much easier to integrate a new wizard pane into MDT.  You don’t have to worry about reintegrating your changes into the “big” XML file each time you upgrade MDT – your separate files will continue to exist, untouched, so all you will need to do is add the “link” into DeployWiz_Definition_ENU.xml again and you’re good to go.

One of the steps in the Configuration Manager installation process is to manually create the “System Management” container in Active Directory, then give the ConfigMgr computer account the ability to create objects in it.  Yes, even with Configuration Manager 2012, this is still something that needs to be done manually.

So that was this evening’s challenge:  Automating that seemingly simple task.  As with all automation tasks, you always hope that someone has already solved the problem.  But even with searching multiple search engines (something that always pains me), I didn’t really find what I was looking for.  (No executables, no third-party tools, no ugly ADSI code, and ideally no VBScript – PowerShell is the future.)  So I created a new PowerShell script, incorporating bits and pieces from several other scripts.  The basic steps:

• Import the “ActiveDirectory” PowerShell module (which only exists in Windows Server 2008 R2, so that is required).
• Figure out our domain name (so we don’t have to hard-code a value in the script).
• Create the “System Management” container if it doesn’t already exist.
• Get the computer account (from the environment, so we don’t need to hard-code that either).
• Add the computer account to the “System Management” container’s access control list, giving it full access.

Sounds simple enough, and except for the ACL part, it is.  The complete script:

#Requires -version 2.0

# ***************************************************************************
#
# File:      SystemManagement.ps1
#
# Version:   1.0
#
# Author:    Michael Niehaus
#
# Purpose:   Create the AD "System Management" container needed for
#            ConfigMgr 2007 and 2012, and grant access to the current
#            computer account.
#
#            This requires PowerShell 2.0 and Windows Server 2008 R2.
#
# Usage:     Run this script as a domain administrator, from the ConfigMgr
#            server.  No parameters are required.
#
# ------------- DISCLAIMER -------------------------------------------------
# This script code is provided as is with no guarantee or waranty concerning
# the usability or impact on systems and may be used, distributed, and
# modified in any way provided the parties agree and acknowledge the
# Microsoft or Microsoft Partners have neither accountabilty or
# responsibility for results produced by use of this script.
#
# Microsoft will not provide any support through any means.
# ------------- DISCLAIMER -------------------------------------------------
#
# ***************************************************************************

# Load the AD module

Import-Module ActiveDirectory

# Figure out our domain

$root = (Get-ADRootDSE).defaultNamingContext

# Get or create the System Management container

$ou = $null
try
{
    $ou = Get-ADObject "CN=System Management,CN=System,$root"
}
catch
{
    Write-Verbose "System Management container does not currently exist."
}

if ($ou -eq $null)
{
    $ou = New-ADObject -Type Container -name "System Management" -Path "CN=System,$root" -Passthru
}

# Get the current ACL for the OU

$acl = get-acl "ad:CN=System Management,CN=System,$root"

# Get the computer's SID

$computer = get-adcomputer $env:ComputerName
$sid = [System.Security.Principal.SecurityIdentifier] $computer.SID

# Create a new access control entry to allow access to the OU

$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule $sid, "GenericAll", "Allow", "All"

# Add the ACE to the ACL, then set the ACL to save the changes

$acl.AddAccessRule($ace)
Set-acl -aclobject $acl "ad:CN=System Management,CN=System,$root"

The same script is attached.