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.
Here’s a step-by-step breakdown of the runbook:
- Get Data from Service Manager – Initialize Data runbook activity that pulls in information entered into the SR in SCSM.
- 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.
- Clone User – Get User runbook activity that pulls user info from the username specified in the SR
- 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.
- 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.
- Update User – Update User runbook activity sets attributes of newly created user to that of the cloned user.
- 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.
- 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.
- 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 –
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….
System Center Stuff 