...building hybrid clouds that can support any device from anywhere
Yay! Part 4 has finally arrived…
And by Part 4, I am obviously talking about the next big post in “The New World of Tenant Provisioning with Windows Azure Pack” blog series.
What is this one all about?
Automated Deployment of Tenant Workloads (Lync, SharePoint, and Exchange)
What does that mean?
Well, let’s first take a look back: Part 1 (here) was the Intro/TOC for this fine blog series; Part 2 (here) was all about Automated Deployment of Tenant Network and Identity Workload (Active Directory Gallery Item VM Role) from the Service Admin Persona; and Part 3 (here) was all about Automated Deployment of the Identity Workload (Active Directory Gallery Item VM Role) from the Tenant Admin Persona.
So what that means is, in Part 4, we only have one major aspect of Gallery Item VM Role Deployment left to discuss in the series: Tenant Workloads (Lync, SharePoint, and Exchange Gallery Item VM Roles)
Up to this point in the blog series, we have covered an example for each of the following deployment options:
Note In this diagram, we also see that deployment options for both administrator personas have been covered. And we did this with a specific example in mind: the Active Directory Gallery Item VM Role. This was due to the fact that the subsequent example Gallery Item VM Role deployments in this blog series take a strong dependency on Active Directory. In this way, both the Gallery Item VM Role for Active Directory and the Tenant Network are “table stakes”.
Truth be told, based on just Parts 2 and 3 of this blog series, you really have everything necessary to deploy not only the Gallery Item VM Role for Active Directory, but any Gallery Item VM Role you have built (or pulled down off of WebPI (or our Blog)).
Which leads to the logical next step…
Describing what it takes and providing the necessary script updates (to what you have seen so far) to deploy the Gallery Item VM Roles for Lync, SharePoint, and Exchange (for both personas).
Which means, at least in part, that these three diagrams happen to also apply to this blog post:
Because we established a solid foundation in Parts 2 and 3 of the series, this post really just highlights the script updates necessary to get Automated WAP Deployments to work for OUR PUBLISHED Lync, SharePoint, and Exchange Gallery Item VM Roles. The reason I say “OUR PUBLISHED” in yelling-case is to emphasize which Gallery Item VM Roles the example scripts in this post actually directly relate. If you are wondering, “OUR PUBLISHED” Lync, SharePoint, and Exchange Gallery Item VM Roles can be found here: Windows Azure Pack VM Role Gallery Items for Collaboration Workloads
Good question, glad you asked.
Well, as you saw in Part 2 and 3, no one generic script can be created that handles the deployment from beginning to end. This is due to the fact that each VM Role Definition can vary, based on how that VM Role was created, what fields were included, and which Resource Extensions were added. And while I did my best to keep my scripts generic, there were just portions that had to be hardcoded - dun! dun! dun! The good news is, the hardcoded – dun! dun! dun! stuff is kept to where the scripts differ. Meaning, logic can be introduced to dynamically add the appropriate hardcoded - dun! dun! dun! script portions based on VM Role type.
Yes. There will be a “discovery” section in the post which takes you through how to enumerate “What’s different” or “What’s required” as it relates to the Resource Definition (ResDef/ResDefExt), and Resource Definition Configuration (ResDefConfig).
This topic will not be discussed again here in this post. Please refer to Part 2 of this blog series for more information and example script.
Note The TechNet Gallery Contribution download will also include the example script(s) for automatically creating a Tenant Virtual Network.
Just like in Parts 2 and 3, there are various options to choose from when deploying Gallery Item VM Roles. These options are depicted above, in the first image (the one with all the green checkmarks). To keep this blog post manageable, I will be providing the example Runbooks / Scripts / Guidance in the following order:
Instead of making a whole big section, reiterating the same thing over and over, I will simply be providing the following:
There are a couple topics out of scope for this particular blog post, as they have been covered previously within the series.
In other words, from a deployment perspective (and from the Tenant’s view), this is our starting point:
If we take a look at the “overall structure of my SMA Runbooks” section from Part 2, the following SMA Runbook will be the same for each Gallery Item VM Role Deployment (well, depending on your implementation, but definitely for this example) and can be leveraged generically:
If we take another look at the “overall structure of my SMA Runbooks” section from Part 2, these two SMA Runbooks will have subtle differences for each Gallery Item VM Role Deployment:
Note I provide the updated SMA Runbook examples for each Tenant Workload Deployment below.
Before we dive into the SMA Runbook updates, I want to level-set…
Because more significant updates take place in the Deploy-TenantVMRole SMA Runbook, this section of the post will concentrate more on it, rather than the Subscription-Create-Dispatcher SMA Runbook.
Remember in both Parts 2 and 3 there was a portion of the example PowerShell that created the Gallery Item Parameter Hashtable (for Common Data) and then added to the Gallery Item Parameter Hashtable (for GI Specific Data)?
If not, here is an image to help jog your memory:
It is right below this section in the Deploy-TenantVMRole SMA Runbook where we will be adding the updates. Essentially, more logic will be introduced to dynamically add the appropriate hardcoded - dun! dun! dun! script portions based on VM Role type.
Note I will be including the script portions in each respective Tenant Workload sub-section below. Then an all-up Deploy-TenantVMRole SMA Runbook with configuration for all 4 (including Active Directory) Tenant Workload Deployments will be made available after the last sub-section. Also included, will be the all-up Subscription-Create-Dispatcher SMA Runbook with calls for all 4 (including Active Directory) Tenant Workload Deployments.
Note For each of these example script portions, I kept most of the Hashtable Variable building “complex” and/or hardcoded – dun! dun! dun! on purpose. I wanted to avoid creating and leveraging extra variables outside these individual IF blocks. In these examples, much of the string formatting is the same from IF block to IF block, so you can create a “Credential” string before all this, and leverage it throughout.
Disclaimer This is a set of examples to handle the GI Specific Data. There are other (and likely better) ways to do this same thing. If you have improvements, please leverage them. If you would like to share those improvements with the community, please leave comments, or send a link to your related blog post. I am always happy to cross-post.
(with IF blocks for DomainController, Lync, SharePoint, and Exchange)
Note Obviously I took some liberties with the data sharing in this example. Before I started this SMA Runbook, I knew that each of our Gallery Item VM Roles shared a set of “Common Data” for the Gallery Item Parameter Hashtable. At that point, I just had to figure out which parameters fell into the “GI Specific Data” for each Gallery Item VM Role to be included in the SMA Runbook. Each set of “GI Specific Data” then gets its own IF block, appending to the “Common Data” already in the Gallery Item Parameter Hashtable. More information on “Discovery” of “GI Specific Data” can be found in the very next section of this post!
(with calls for each Tenant Workload)
Note I did not add any “wait logic” in this example. It simply deploys Active Directory, waits 10 minutes and then deploys the other workloads (Lync, SharePoint, and Exchange). For more information on Monitoring and Notifications, refer to this blog post: Automation–Monitoring and Notifying in Windows Azure Pack with SMA.
So, how did I know which items in the Gallery Item Parameter Hashtable were “Common” and which were “GI Specific”?
Well, other than tearing apart the JSON during my learning process for all this, there is a pretty simple method to extract the necessary data for review.
The following is an example PowerShell script which leverages the WAP Tenant API (non-Public), pulls down the specified Gallery Item VM Roles desired for comparison, and outputs a Hashtable containing the Gallery Item VM Role Name and its required Resource Parameters.
Note I leveraged a function within this example script, to minimize duplicate command execution. Modify this example as you see fit. Oh, and it needs to be executed (at least in part) from the WAP Admin Server, or wherever the MgmtSvcAdmin Cmdlets live.
A Hashtable of values you can use to compare/contrast Gallery Item VM Role Resource Parameters:
Challenge I simply provide the Hashtable worth of data, it is up to you to enumerate the data and make something fancy with Compare-Object command to dynamically compare the Resource Parameters on the fly!
Notes(s) Once again, I have several notes about the above script. So I will list them here:
After the dust settles on back to back executions, you should see something similar to this in the Tenant Portal:
Note This is essentially a copy/paste of the Service Admin script, with modifications to work against the Public WAP Tenant API. The major updates: URL port (changed from 30005 to 30006); and Authorization method (changed from Header with bearer token to Certificate).
And once again, the output of this script is:
I assume once you watch the video (below) you will have a few ideas, but here are some use cases (from both the Service Admin and Tenant Admin personas):
Note Again, these are just some of the use cases I could come up with off the top of my head. I am sure you have many more scenarios in mind.
Oh, you want the VIDEO and TECHNET GALLERY CONTRIBUTION now, do you?
Fun Fact It may be my first 8-Minute-Demo Video that is actually 8 minutes exactly.
The download (Windows Azure Pack Tenant Provisioning Automation Toolkit.zip) includes the following (14) files:
SMA Runbook Exports
Note XML (SMA Runbooks) and PS1 (PowerShell Scripts) files are both provided in the download. Use SMART for Runbook Import and Export to leverage the provided XML files in the above download for an enhanced experience in importing the example solution into your SMA environment.
Optional Some of the scripts within this download contain commented out “optional” portions for Monitoring and Notifications. The associated Runbooks and Variables for these options are not included in this download. For more information about Monitoring and Notifications within SMA, please see the following blog post: Automation–Monitoring and Notifying in Windows Azure Pack with SMA
Download the Windows Azure Pack Tenant Provisioning Automation Toolkit from TechNet Gallery here:
Windows Azure Pack–Gallery Item VM Role–References for Creation, Configuration, and Automation
If not, check it out.
And while it does cross-reference back to this post, it covers the entire Gallery Item VM Role Lifecycle (well the important bits, anyway).
Thanks for checking out my latest blog series! For more information, tips/tricks, and example solutions for Automation within System Center, Windows Azure Pack, Windows Azure, etc., be sure to check out the other blog posts from Building Clouds in the Automation Track!