...building hybrid clouds that can support any device from anywhere
I know it is a bit back-to-back with these examples, but I wanted to continue to share my learnings with you, as I continue down the “Tenant Provisioning POC” path with my team. Today it is all about dynamically creating Virtual Machine Manager Run As accounts for use as parameters during Service Template deployment.
Note This post will be best understood if you check out my most recent previous post:
Automation–PowerShell Workflow Script Spotlight–Deploying Virtual Machine Manager Service Templates “OnBehalfOf” Tenant Administrator User Roles
Here is the high level breakdown of the scenario in this blog post (all steps are performed with PowerShell against Virtual Machine Manager):
Again, before we dive in, let’s take a quick look at some of these concepts…
Run As Accounts are pretty common, whether they are created and leveraged within VMM or not.
Within VMM, they can be found and configured within Settings – Security – Run As Accounts:
You can create them manually, or leverage PowerShell (as seen in the example below).
For more information about VMM Run As Accounts, please refer to the following: Configuring Run As Accounts in VMM
Here are two common examples:
The following image illustrates the usage of a Run As Account as a Parameter in the OS Configuration – Networking Configuration:
The following image illustrates the usage of a Run As Account as a Parameter in the Application Configuration – Scripts Configuration:
While the following blog post, SC VMM 2012 Service Settings, outlines service setting usage in great detail, it boils down to two main reasons:
This particular service setting is further explained by the simple definition of VMM Run As Accounts: A Run As account is a container for a set of stored credentials.
So, for our example here, it is best to look at VMM Run As Accounts for Service Templates as a reusable container for stored credentials which allow for dynamic deploy time configurability.
Okay, now that we have those two things down, let’s get right to the scripts!
The following PowerShell workflow script (Create-SCRunAsAccount) will create a VMM Run As Account with the following settings:
Note Hardcoding of a plain text password is not best practice. Its usage here is strictly for example purposes. If this PowerShell is leveraged within SC Orchestrator or SMA, it could be easily obscured.
You can call the Create-SCRunAsAccount workflow like this:
A VMM Run As Account is created with a name matching the pattern “<Domain Name> Administrator” with the configured Username and Password.
In the example below (as Domain Name = Contoso):
Like all examples, there are lots of options here, choose the one that makes sense for your deployment.
Granting permissions should be leveraged sometime after the VMM Run As Account has been created, and after a the intended VMM User Role (Tenant Administrator in this example) has been established.
It most likely will be part of the script that calls the Create-SCRunAsAccount PowerShell workflow (above).
The following PowerShell snippet extends the above “Calling the Create-SCRunAsAccount PowerShell workflow” example as well as leverages the previously blogged Create-TenantAdminUserRole PowerShell workflow example:
The following extends the previously blogged Build-ServiceSettings PowerShell workflow example, leveraging the examples illustrated above. For ease of use, the entire extended version of the Build-ServiceSettings PowerShell workflow example has been included here, with the updates highlighted.
Note The highlighted portions above reflect the major updates to the previously blogged Build-ServiceSettings. For more information about this specific PowerShell workflow example, please refer to the previous blog post.
More specifically for this example: Set the VMM Service Template Global Setting Parameters (leveraging the new Build-ServiceSettings PowerShell workflow) “OnBehalfOf” the User Role (Tenant Administrator).
Because we extended the functionality a layer down (in the Build-ServiceSettings PowerShell workflow example), no changes are necessary to the Deploy-VMMService PowerShell workflow. This is due to the fact that Deploy-VMMService leverages a foreach statement to traverse the hash table created in Build-ServiceSettings – Setting Global Setting Parameters is then completely dynamic at this level. For ease of use, the Deploy-VMMService PowerShell workflow example has been included here.
Note The Deploy-VMMService script above is the same exact script previously blogged. For more information about this specific PowerShell workflow example, please refer to the previous blog post.
The same exact script example from the previous blog post can be used to call Deploy-VMMService. Again, for ease of use, here is an example (this time for the Exchange Service Template):
Note The $ServiceTemplateName and $ServiceTemplateRelease values would vary based on your Service Template details.
All results and further detailed explanation is the same as the previous blog post, see that post for more information.
That’s it - thanks for checking it out!
And for more information, tips/tricks, and example solutions for PowerShell + System Center 2012 R2, be sure to watch for future blog posts in the Automation Track!