New User Automation. How do you do it?
In my role of Solutions Architect for Cireson I often get asked for blog posts or copies of Runbooks and scripts to kick off automation in organisations and the most popular automation task by far is automation new user account creation.
As there is little end-to-end advice out there for people starting down this path I thought I'd kick off this discussion to see what other people are doing in their organisations and how well it is working for them.
What Automation Should I Use?
There are several choices when it comes to automation solutions and which one you choose is up to you and what is best for your organisation. If you have a strong Powershell ability level in your organisation then stick with code. If not, maybe a visual style, like Orchestrator, is more relevant to you.
Here are the choices we have:
Once an automation solution is chosen we can look at how people are doing their New User Automation.....
- Azure Automation
- Cireson PowerShell Activity
This is where most of us start as it is integrated in to SCSM out of the box and is Microsoft's preferred method. It is relatively simple to learn and provides a simple visual view of what we are automating. However, if there is no integration pack for the app we are trying to automate or the integration pack does not do what we want it to we rapidly fall back on PowerShell to get the job done.
Server Management Automation is a PowerShell style of Orchestrator and uses PowerShell Workflows to run the automation required. This is NOT native PowerShell but rather a different approach to PowerShell and many people get confused why their code, that they cut from Google, does not run. This technology has had very little uptake but is super powerful.
Cireson has written a SMA connector to allow the SMA Runbooks to be triggered direct from SCSM.
If your organisation runs Azure then running automation from Azure might be a good way to go. While there is no specific hook in to SCSM there are ways around that and we will be holding a webinar on that very shortly.
Recently, Cireson released a native SCSM activity that can be placed directly in to the workflow of a Work Item and trigger the PowerShell direct from SCSM reducing queues and wait times to trigger external automation solutions (Orchestrator, SMA etc.)
Again, this is PowerShell so if you don't have a high level of competency in your organisation, this might not be the way to go. Also, as the PowerShell code runs on the workflow server, this can impact performance if your environment is not configured to take this new workload.
1. SMA 2016 can run native PowerShell runbooks, if imported via command line (not via WAP).
2. Don't bother installing the outdated WAP. There is a PowerShell ISE add-on for SMA (and similar for Azure Automation) that gives you some of this functionality. We had lots of issues with WAP reliability (e.g. inconsistently producing output when testing runbooks) and installing it offline was a massive pain.
3. We haven't configured the Cireson SMA connector yet to verify it'll run PowerShell scripts from SMA. Hopefully somebody else will get to this before I do.
4. We will attempt to run SMA in Windows Server Core with an aim to containerise it. If anybody has experience here, please let me know if it's possible and any gotchas.
5. Read the SMA White Paper. It's concerned with 2012, so it relies on the WAP, but it's a terrific resource for understanding the beast.
6. The SMA database is rather tidy, making for some simple T-SQL queries to pull the data into reporting services. The management and dashboards in the WAP can be replicated between SSRS and the ISE add-on. Even the stored procs are easy to understand.
7. The SMA database does not store version or actor information (i.e. who edited the runbook last).
8. Since SMA uses PowerShell, it makes version control, and build and release simple via TFS. No more cumbersome integration packs and runbooks just to export runbooks, and it goes into a GIT repo quite happily.
Once the runbooks are completed, all that is left are some legacy systems provisioning and the hardware provisioning.
- Create a new user ID and validate that it is unique
- Update the SR so all activities have the proper info, and based on the questions answered in the RO, skip any unneeded activities
- Create the AD Account
- Add the new user to all necessary AD Groups
- Initiate an Azure AD Sync and Provision the new Account with the correct O365 License
- Add the O365 User to the appropriate O365 Groups
From submission to Manual Activity to the helpdesk for the computer provisioning is about 15 Minutes.
Within the runbooks there is a fair amount of PowerShell scripts as well as some SQL scripting for our inhouse database of UserIDs.
All-in-all there are 5 Runbook Automation Activites that in turn call upon another 20 or so runbooks to complete the process.