Partager via

Creating the ConfigMgr “System Management” Container with PowerShell

  • Article

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.

SystemManagement.zip

Comments

  • Anonymous
    January 01, 2003
    Here is a 1-liner for firewall pre-reqs: netsh advfirewall firewall add rule name="SQL / SQL Replication" dir=in protocol=tcp localport="1433,4022"  action=Allow

  • Anonymous
    January 01, 2003
    Nice one! This is the best alternative I saw until now, thanks. But I think: Why the Product Team don't put something like that on Installation Wizard? Then, this is a mistery :)

  • Anonymous
    January 01, 2003
    Celeber, the SCCM PG didn't have time to add this script into their code, because they were too busy making sure the product shipped on time... err, I mean, they were working on an OS prerequsite installer... err, I mean SCCM cmdlets... err, I mean ensuring they wouldn't need a hotfix within 1 week of launch... err I mean...

  • Anonymous
    January 01, 2003
    Hi Michael, thanks for that great script. I would like to initiate this script from my SCCM 2012 Server (during MDT deployment). Is this possible or does the Server need to be a DC in order to have the Active Directory Powershell Module available?

  • Anonymous
    January 01, 2003
    Doing this on Server Core 2012 in preparation for SCVMM 2012 SP1 (clustered instance), I found that I had to be more specific with the class constructor to ActiveDirectoryAccessRule: $identity = [System.Security.Principal.IdentityReference] $svcacct.SID $adRights = [System.DirectoryServices.ActiveDirectoryRights] "GenericAll" $type = [System.Security.AccessControl.AccessControlType] "Allow" $inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance] "All" $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $identity,$adRights,$type,$inheritanceType Before this, I couldn't get over the "Cannot find an overload for..." error. I don't know if this is a change in the .NET 4.5 class, or if this is related to .NET classes taking named parameters now.

  • Anonymous
    January 01, 2003
    Nice script! Very handy! Cheers, Peter