Creating an Orchestrator Runbook for AD Account/Mailbox Creation

I had a deliverable at a client once to create an Orchestrator runbook to provision new users in AD. Sounded pretty simple since it’s a built-in Orchestrator task; however, after a meeting with the Admin, I found out he not only wanted an account created, but also:

 

  • the ability to copy a current user account
  • create an Exchange 2013 mailbox
  • specify the mailbox database
  • specify the mailbox Address Book Policy
  • move the user account to the proper AD OU based on office location
  • create the user’s Home Drive on the local file server with proper permissions
  • Initiate and track all the above from a System Center Service Manager (SCSM) Service Request (SR) in the SharePoint portal.

 

I searched the internet for some starting points and really only found one article that helped me at all and it was about cloning current users. I incorporated the overall idea into my framework but had to tweak it to my client’s needs. I also found that there were things I could not do with runbook activities, so I resorted to PowerShell scripts. This ended up working nicely for me. Check out the runbook below.

runbook

Here’s a step-by-step breakdown of the runbook:

 

  1. Get Data from Service Manager – Initialize Data runbook activity that pulls in information entered into the SR in SCSM.
  2. The two separate paths check for data assigned to a variable by user entry. If a username is entered, then we go to Clone User. If not, it goes to the Create New User activity.
  3. Clone User – Get User runbook activity that pulls user info from the username specified in the SR
  4. Create Cloned User/Create New User – Create Mailbox runbook activity that creates a User and Mailbox using variables from entry points and drop-down menus that specify the name, username, database, Address Book Policy, and any other specifics from the cloned user if a user is being cloned.
  5. User Group Membership – Run .NET Script runbook activity – PowerShell script to get user membership from the cloned user account and apply them to the newly created user.
  6. Update User – Update User runbook activity sets attributes of newly created user to that of the cloned user.
  7. Create Home Drive – Run .NET Script runbook activity – PowerShell script to create the user’s home drive and set proper permissions for users, system, and admins.
  8. Move to Proper OU – Run .NET Script runbook activity – PowerShell script that moves newly created user to Proper OU based on Location chosen in SR.
  9. Get New User Info – Get User runbook activity to get information on new user to pass back to the SR.

 

The next five activities deal with updating the SR in SCSM as to the success or failure of the runbook and then sends a notification email to the AD admins that the action is complete. That’s a different post….

 

First of all (just so you know) here’s what I’m pulling in from the SCSM Service Request –

SR

 

 

The First, Last, username, and Clone fields are entry fields while the Database, ADBpolicy, and location fields are selectable lists in the SCSM Service Request. I used these variables in the runbook activities to create the user and mailbox, as well as for the PowerShell Scripts below.

 

The first five lines of the script create a remote session to a domain controller where we will execute the script. I used this in every script because I ran into multiple permissions issues trying to make sure my runbook servers were set up with the proper tools to remotely execute these scripts. The SName and DName variables have to be entered in the scriptblock in the runbook activity to get the proper values. In all cases, take out the brackets {} as well as the descriptive text contained therein.

 

User Group Membership

 

##create a PS Session on remote domain controller

 

$remoteuser = “{domain\username with rights to DC}”

 

$remotepassword = ConvertTo-SecureString “{password for above account}” -AsPlainText -Force

 

$remoteCred = New-Object System.Management.Automation.PSCredential -ArgumentList ($remoteuser,$remotepassword)

 

$session = New-PSsession -ComputerName {NetBIOS name of DC} -cred $remoteCred

 

Invoke-Command -Session $session -scriptblock {

 

## Script to copy group membership

 

Import-Module ActiveDirectory

 

$SName = “{variable of group source ad account}”

 

$DName = “{variable of target account}”

 

 $K = Get-ADUser -Identity $SName -Properties memberOf

 

foreach($group in $K.memberof) 

 

 

Add-ADGroupMember -Identity $group -Member $DName

 

}

 

}

 

Remove-PSsession $session

 

 

 

Here, once again, the first five lines set up the remote session to the domain controller. In the next two scripts, notice the lines where it says “location value from list”. In this space, you’ll type the value they have chosen from the actual list in the Service Request. This is not a variable in Orchestrator. The loc and username variables have to be entered in the scriptblock in the runbook activity to get the proper values. In all cases, take out the brackets {} as well as the descriptive text contained therein.

 

Create a Home Drive with explicit permissions

 

##create a PS Session on remote domain controller

 

$remoteuser = “{domain\username with rights to DC}”

 

$remotepassword = ConvertTo-SecureString “{password for above account}” -AsPlainText -Force

 

$remoteCred = New-Object System.Management.Automation.PSCredential -ArgumentList ($remoteuser,$remotepassword)

 

$session = New-PSsession -ComputerName {NetBIOS name of DC} -cred $remoteCred

 

Invoke-Command -Session $session -scriptblock {

 

 

 

$loc  = “{location variable from SR}”

 

if ($loc -eq “{value from list in SR}”){ $server = “{location file server name}” }

 

if ($loc -eq “{value from list in SR}”){ $server = “{location file server name}” }

 

$homedrive = “\\$server\users

 

$newuser = “{username from SR}”

 

 

 

# If the folder for the user does not exist, make a new one and set the correct permissions.

 

if (-not (Test-Path “$homedrive\$newuser”))

 

{

 

    $acl = Get-Acl (New-Item -Path $homedrive -Name $newuser -ItemType Directory)

 

 

 

    # Make sure access rules are not inherited from parent folders.

 

    $acl.SetAccessRuleProtection($true, $false)

 

 

 

    $ace = “domain\$newuser”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”

 

    $objACE = New-Object System.Security.AccessControl.FileSystemAccessRule($ace)

 

    $acl.AddAccessRule($objACE)

 

    Set-ACL -Path “$homedrive\$newuser” -AclObject $acl

 

 

 

    $ace2 = “domain\domain admins”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”

 

    $objACE2 = New-Object System.Security.AccessControl.FileSystemAccessRule($ace2)

 

    $acl.AddAccessRule($objACE2)

 

    Set-ACL -Path “$homedrive\$newuser” -AclObject $acl

 

 

 

    $ace3 = “SYSTEM”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”

 

    $objACE3 = New-Object System.Security.AccessControl.FileSystemAccessRule($ace3)

 

    $acl.AddAccessRule($objACE3)

 

    Set-ACL -Path “$homedrive\$newuser” -AclObject $acl

 

 

 

    $ace4 = “Builtin\Administrators”,”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”

 

    $objACE4 = New-Object System.Security.AccessControl.FileSystemAccessRule($ace4)

 

    $acl.AddAccessRule($objACE4)

 

    Set-ACL -Path “$homedrive\$newuser” -AclObject $acl

 

}

 

}

 

Remove-PSsession $session

 

 

 

Move to Proper OU

 

##create a PS Session on remote domain controller

 

$remoteuser = “{domain\username with rights to DC}”

 

$remotepassword = ConvertTo-SecureString “{password for above account}” -AsPlainText -Force

 

$remoteCred = New-Object System.Management.Automation.PSCredential -ArgumentList ($remoteuser,$remotepassword)

 

$session = New-PSsession -ComputerName {NetBIOS name of DC} -cred $remoteCred

 

Invoke-Command -Session $session -scriptblock {

 

Import-Module ActiveDirectory

 

$loc  = “{location variable from SR}”

 

if ($loc -eq “{location value from list}”){ $OU = “OU=Users,OU=City,DC=domain,DC=local” }

 

if ($loc -eq “{location value from list}”){ $OU = “OU=Users,OU=City,DC=domain,DC=local” }

 

Get-ADUser {username variable from SR} | Move-ADObject -TargetPath $OU

 

}

 

Remove-PSsession $session

 

That’s it!

 

Good luck to all of you and remember – there are multiple ways to get the best result for your client. Use this as a framework and adapt to your particular needs! As always, security requirements are always the first concern as you decide how to run your PowerShell scripts and configure remote execution policies.

 

There are plenty of Blog Posts on creating a Service Request in SCSM, but I may do my own for the next one. ‘Til then….

 

Advertisements

A little Consultant Fun…..

My friend, Cameron Fuller, has a blog where he’s ran several great posts about being a consultant. He came to me with an idea for a song about “what not to say on a client site” so I recorded it for him!

Check out Cameron’s bog and our song here: http://blogs.catapultsystems.com/cfuller/archive/2015/01/30/these-are-the-some-things-you-don’t-say-on-a-client-site.aspx

Building a Test Lab in Azure? Here’s how….

Here’s some handy links if you haven’t found them already. All you need is a free trial with your MS account and you’re on your way. It’s a great primer if you’re new to Azure.

Quick Start – Dive right in? Here’s the Link with general steps:

http://azure.microsoft.com/en-us/documentation/articles/active-directory-new-forest-virtual-machine/

Like Whitepapers? Here you go!

http://www.microsoft.com/en-us/download/details.aspx?id=41684

Thanks, Microsoft!

Having your reports prompt for a collection

Once again….. just more great stuff I found. Building a report in SCCM can be simple – but that doesn’t mean it’s easy. Here’s a great Blog Post about how to get your reports to prompt for a collection to run against.

http://asithadesilva.wordpress.com/2013/04/01/how-to-prompt-collection-to-a-report-in-sccm-2012/

 

Report Builder 3.0 Unable to connect to Dataset

So, I had an issues with Report Builder not wanting to connect to the Database due to a certificate chain error in the prelogon handshake. I found this great post on TechNet Forums about the issue and it fixed it for me. There are detailed instructions on how to import the SCCM Database server’s certificate into your trusted root.

http://social.technet.microsoft.com/Forums/en-US/add3e017-6166-4443-b9f2-9898e4e0c843/report-builder-unable-to-connect-to-data-source?forum=configmanagergeneral

Start>run>mmc>file>add/remove snapins>certificate>Computer Account>Local Computer>Certificates>Personal>Certificates>Issued to: Name of server

 Look at each cert.  On the 3<sup style=”color:#1f497d;”>rd</sup> tab (Certification Path) it should say “ConfigMgr SQL Server Identification Certificate”.  Export that cert.

Then on the machine running report builder, import the certificate to the local computer trusted root.

SCCM Query Builder results limited to 2000

SCCM Query Builder results limited to 2000

While building Queries in SCCM Query Builder, you will sooner or later run into an issue where it will only return 2000 items. This is a legacy setting that goes back to SMS 2.0 where the server/PC would literally run out of memory to return more than that. Head over to Peter Daalmans’s Blog for the complete answer, but here’s a snippet in case his blog goes down….

For 32bits ConfigMgr 2012 Consoles on 64bits go to the following registry key:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ConfigMgr10\AdminUI\QueryProcessors

Otherwise go to the following registry key:

  • HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\ConfigMgr10\AdminUI\QueryProcessors

Add a DWORD value for ValueLimit and set it to a, for you appropriate value. (eg. decimal value 10000)

After adding and changing the value and restarting the ConfigMgr Console you are able to see all values.