Update Sunday August 16th 2015 - URL in script has changed. I have updated the script here leaving the legacy URL in place but commented out.

Windows Azure Pack and Service Management Automation are on fire. Having spent a little bit of time working with WAP, one of the first items that I found needing my own personal adjustment was to the Computer Names given to my VM’s after a Stand Alone Virtual Machine deployment. More to the point, if you deploy a Standalone VM, giving it a VM Name of VM001, you will end up with a Computer Name more like ZB0NLHY74MPYW0. However, I want my VM’s to have a common VM Name and Computer Name. That is if I name my VM VM001, I want my computer name to also be VM001.

Fortunately with the tight integration between Service Management Automation and Windows Azure Pack we are provided with a platform on which to automate post VM deployment tasks such as renaming a computer. In this blog I will be sharing a sample solution that demonstrates how to use an SMA Runbook to dynamically rename the computer to match the name chosen for the VM.

So to recap my intent here:

Issue: When deploying a standalone VM using the Windows Azure Pack a random computer name is given to the VM regardless of the VM name.

Desired Outcome: to have the VM Name and the Computer Name of the VM match after deployment with no manual intervention. I also want to ensure that this name is not currently is use, and adjust accordingly if it is.

Solution: Create a SMA Runbook that will consume the given VM Name, and once deployed, rename the VM’s Computer Name to match the VM Name.

Before We Get Started:

There are several core items to WAP VM automation that I will not be covering (like how to ‘link’ the automation to the VM creation process). Below is some content that can be used for ramp up on those core components.

Blog: SMA Capabilities in Depth.

Blog: Calling an Orchestrator Runbook using SMA (Good example of using SMA parameter data).

TechNet: Using Automation with Virtual Machine Clouds.

TechNet: Global Resource or Assets.

Sample Runbook: I've used the Sample-Using-VMCloud-Automation which is included with SMA as a starting point for this Runbook. Be sure to examine this Runbook as it is very helpful reference for this post VM deployment type activities.

The Runbook:

The sample Runbook in this post rely on a few SMA Assets. The following have been created and configured in support of the Runbook.

ADCred: this contains the credentials of an account with access to rename a computer.

spfUrl: Variable that contains the SPF endpoint URL. This URL should be similar to https://spf_end_point:8090/SC2012R2/VMM/Microsoft.Management.Odata.svc/ .

spfCredentials: this contains the credentials of an account with access to the SPF Endpoint.

A copy of this Runbook can be found here - Runbook .

The Breakdown:

Line 6 and 13 – initializing data. Note that in initializing $resourceObject we are consuming or loading several pieces of valuable data from the VM creation process such as the current VM Name ($resourceObject.Name) and Computer Name ($resourceObject.ComputerName).

Line 19 - Here I am consuming an SMA Credential asset ($ADCred) that is populated with credentials with the appropriate access to perform a computer rename.

Line 24 - 27 - when retrieving $resourceObject.ComputerName the value is returned as ComputerName.Domain. Here I am splitting off the  'Dot-Domain Name' and placing only the Computer Name into a new variable.

Line 30 - 35 - Sample logging. This is visible on the job output in Windows Azure Pack Admin Portal.

Line 37 - 64 - This chunk was taken from the Sample-Using-VMCloud-Automation Runbook that is included with SMA. The code is retrieving the current state of the VM deployment, looping until the VM deployment has completed, outputting progress during each loop. This code allows us to hold off on any post deployment routines (such as a computer rename) until the VM has been successfully deployed.

Line 67 - 68 - validating that values have been populated for the VMName and Computer Name.

Line 72 - 89 - Rename routine, note here that I am using straight PowerShell encapsulated in an Inlinescript. In order to ensure that a computer does not already exist with the intended name, this routine checks AD for any matches to that of $resourceObject.Name (or the VM Name). If none exist the computer is then renamed. If the intended name is in use, the variable is incremented with a numeric value, and AD is checked again. This occurs in a Do / Until loop until no match is found at which time the computer is renamed..

Line 77 and 82 - note that because I am working from within an inlineScript I am referring to the variables here using a $Using variable. More information can be found at this blog by Jim Britt .

The Runbook is configured to execute anytime a Standalone VM is created as seen below.

NOTE: In this configuration only Stand Alone VM deployments are effected. The Runbook will not execute when deploying a VM Role. These will inherit Computer Name's from the Gallery Item pattern. This is a good thing..

Finally once completed not only will your new VM have a Computer Name that matches the VM Name, we can also observe the logging in the job output.

Click Image For Better View:

Conclusion:

While this was a simple project demonstrating the integration between Windows Azure Pack and Service Management Automation, I found it to be very helpful in terms of understanding the integration, understanding how to work with SMA, and really just a simple yet practical introduction to the two products. I am looking forward to a continuing my ramp up on these products and will continue to share significant examples here. Subscribe to my twitter feed using the button found on this page for up to date notification as these posts occur.

Thanks for reading.

Quite some time back I built and made available Runbook Commander: A System Center Companion Application. RBC is essentially a dynamic console extension for System Center Configuration Manager which can execute a System Center Orchestrator Runbook, passing to this Runbook information about the selected Configuration Manager object. I’ve not made any changes to the application however have decided to make the source code available.

Below is the locations of the Runbook Commander documentation, download, and source code.

• Runbook Commander Documentation – TechNet Blog
• Runbook Commander Download – TechNet Gallery
• Runbook Commander Source Code – GitHub Project

Enjoy - neilp

Rather the include all information in one single document or blog post, this will serve as a jump off point to separate items related to CMAEE. I suggest you start with the demonstration videos, each of these are shot and walk through configuration and use of CMAAE. As you work with CMAAE you may want to refer to the documentation when is pretty extensive and detailed. This documentation has an active index that will hyperlink you to the specific items you may need to dig in on. Finally if you are up to the challenge, the source code for CMAAE can be found linked below as well, feel free to grab a copy and modify to fit you liking.

Disclaimer:

The Configuration Manager Application Approval Engine is designed as a sample solution and is not intended for ‘out of the box’ use. Ensure that if using the CMAAE you have fully tested for compatibility and functionality within your environment. All source code is available for examination, use, and extension. No support is provided with the CMAAE sample. This sample solution is provide "as is" with no warrantees and confers no rights.

Configuration Manager Application Approval Engine Introduction:

My initial vision for the Configuration Manager Application Approval engine was just that of a simple portal which would broker data between Configuration Manager and System Center Orchestrator facilitating the dynamical approval of CM Application Requests. After much consideration I decided that the solution should not rely on any one automation system rather be completely flexible in integration, operation, and extensibility.

The current iteration of CMAAE is a flexible and dynamic portal that facilitates the approval process of CM Application requests and can optionally trigger post approval automation. The CMAAE Process or experience can be broken down into three phases:

CMAAE Detection and Notification – any automation process (Orchestrator, PowerShell, and even managed code) monitors Configuration Manager for new application requests. When detected this automation creates a notification email with a specially crafted URL linking to the dynamic CMAAE portal. The CMAAE installer includes several sample automations to complete detection and notification.

CMAAE Approval – once the specially crafted URL has been engaged, the CMAAE portal is displayed allowing for the approval or denial of an application request.

CMAAE Post Approval Automation – this phase is optional. If post approval automation is desirable (such as delivering an email to the application requestor with the approval decision), the CMAAE portal can be configured to execute a post approval System Center Orchestrator Runbook, or a signed PowerShell script.

CMAAE Documentation, Links, and Other Information:

Short Demonstration Videos: TechNet Blog

Detailed Documentation: TechNet Blog

CMAAE Installer Download: TechNet Gallery

CMAAE Source Code: GitHub Project

Original Blog Posts Discussing CM Application Approval Internals: TechNet Blog

I will be adding videos to this section as they are created.

Simple Functionality - demonstration of CMAAE in action.

[View:https://youtu.be/OX0ZG_--3rw:0:0]

Configuration: - Simple configuration.

[View:https://youtu.be/1Smc-OMtflQ:0:0]

Delegation (This is Important) - demonstration of delegation configuration.

[View:https://youtu.be/4ECqYXxhpPQ:0:0]

Detection and Notification Runbook - Configuration of the included detection and notification sample Runbook.

[View:https://youtu.be/0jQByEToOgM:0:0]

Introduction:
Configuration Manager Application Approval Engine Overview:
CMAAE Portal Installation and Core Configuration:
Delegation:
Detection and Notification Overview:
Sample Detection and Notification Runbook:
Sample Detection and Notification PowerShell Script:
Post Approval Automaton Overview:
Sample Post Approval Automation Runbook:
Sample Post Approval Automation PowerShell Script:

Disclaimer:

The Configuration Manager Application Approval Engine is designed as a sample solution and is not intended for ‘out of the box’ use. Ensure that if using the CMAAE you have fully tested for compatibility and functionality within your environment. All source code is available for examination, use, and extension. No support is provided with the CMAAE sample. This sample solution is provide "as is" with no warrantees and confers no rights.

Introduction:

The following document contains detailed documentation for deploying and administering the Configuration Manager Application Approval Engine. In addition to this detailed documentation see the following items:

• Quick overview including demonstration and configuration videos – Link
• Download the CMAAE Sample Installer – Link
• View and Download the CMAAE Source code - Link
  

Configuration Manager Application Approval Engine Overview:

Problem: System Center Configuration Manager 2012 includes the ability to configure requested software to require an approval before being installed on the requesting user’s computer. This system however does not include an engine for providing notification of new or pending approvals, nor does the system allow for a streamlined approval process.

Solution: CMAAE Provide a simple and flexible solution for automating the Configuration Manager Application request notification and approval process. This solution has been created such that any automation tool can be used to drive the application approval process (PowerShell, System Center Orchestrator, or even VBScript / Managed code). Once implemented and configured, as new application requests are submitted through System Center Configuration Manager, notification emails are delivered which link to a very simple approval portal. This solution is fully extensible using common datacenter automation tools such as System Center Orchestrator or PowerShell.

The Configuration Manager Application Approval Engine process consists of three stages.

Stage 1 - Request Discovery and Notification:

During this stage Configuration Manager is monitored for new application requests. This monitoring is done via. a simple WMI query against a Configuration Manager provider and can be performed by any automation tool. Once a new application request has been discovered an email message is created with a specially crafted URL which links back to the Application Approval Portal. Included with the CMAAE download is a sample PowerShell script and Orchestrator Runbook that can be used for this purpose.

Stage 2 – Application Approval:

Once the application request email has arrived at the intended recipient, the URL is engaged which navigates to the Application Approval Engine portal. Here the recipient can approve or deny the specific request.

Stage 3 – Post Approval Automation:

CMAAE can be configured to execute post approval automation using either a System Center Orchestrator Runbook or a PowerShell script. This allows for flexible post approval automation such as delivering additional notifications or interacting with associated service requests. The CMAAE solution includes both a sample post approval Orchestrator Runbook and PowerShell script.

CMAAE Portal Installation and Core Configuration:

Prerequisites:

• Configuration Manager 2012 SP1 or R2
• IIS Instance to host Application Approval Engine (Detailed Below)
• Proper Delegation for Application Approval Engine (Detailed Below)
• Method for discovering new application requests (PowerShell and Orchestrator sample solution provided)
• Optional Post Approval automation (PowerShell and Orchestrator sample solution provided)

Prepare the Windows environment:

• Add the Web Server (IIS) Role.
• Add Security - Windows Authentication.
• Add Application Development – ASP.NET 4.5
• Add Management Tools – IIS 6 Management Compatibility and IIS 6 WMI Compatibility.

Install the Application Approval Engine:

• Execute the CMAAE setup MSI – this may require elevated privileges to execute
• During the installation, name the application virtual directory, CMAAE is selected by default
• Once Completed the CMAAE Portal is installed
• Support files and sample automations are found under the application installation directory

Post Deployment Configuration:

• Within the IIS management tool, navigate to the CMAAE application and then Authentication.
• Ensure that ASP.NET Impersonation and Windows Authentication are enabled and the remaining authentication methods are disabled (Figure 1)
• Navigate to the Application Settings for the CMAAE application and configure the following settings (Figure 2 and figure 3)
  • SiteCode = CM Site Code
  • SiteServer = CM Site Server or CM Provider
  • siteTitle = the title you would like to appear on the CMAAE approval application

Figure 1:

Figure 2:

Figure 3:

This completes the core application configuration.

Delegation:

When the CMAAE application is installed on a server separate from a CM provider, a double hop / authentication issue will occur.

There are two methods for mitigating this occurrence.

Active Directory Delegation: Enable delegation for the computer hosting the CMAAE web application such as seen in the below image. The trusted computer in this case is the CM Site Server or other CM Provider.

Collocate the CMAAE Portal with a CM Provider: If configuring delegation for the web server is not an acceptable configuration, the CMAAE Portal can be collocated on a system with the Configuration Manager provider. In this configuration a second Configuration Provider would need to be deployed. Do not collocate the CMAAE portal on a Configuration Manager Site Server.

Detection and Notification Overview:

Before using the CMAAE portal a method must be engaged that will detect new application requests and provide notification of these requests. This can completed be any method, the only requirement being that the notification include a specially crafted URL specific to the detected application request.

URL Sample: https://CMAAEServer/VDir/?UID=<insert id>

Where UID = the application request unique id.

Included with the CMAAE sample automation is an Orchestrator Runbook and a PowerShell script which both provided detection and notification services.

Sample Detection and Notification Runbook:

Overview:

A sample detection and notification Runbook is delivered with the CMAAE installation package and can be found under the installation directory / Automation Samples.

The CMAAE Detection and Notification Sample Runbook runs on a configurable schedule (15 minutes by default) and checks the specified Configuration Manager Provider for new application requests. When a new application request is detected a notification email is sent which contains a link to the CMAAE approval portal. After a configurable amount of time if the application request has not been approved or denied, a second notification is sent. Finally after a second configurable amount of time if not approved or denied, the application request is auto denied and an email stating thus is delivered.

This sample Runbook is to be used as a guide and can be adjusted and or extended to fit any particular pre approval automation needs.

Configuration:

• Import CMAAE_DetectionAndNotification.ois_export into a System Center Orchestrator (no Orchestrator integration packs are necessary)
• Configure the Variables found under the App Approval Folder as per the provided descriptions.
• Start the Runbook

Sample Detection and Notification PowerShell Script:

Overview:

A sample detection and notification PowerShell script is delivered with the CMAAE installation package and can be found under the installation directory / Automation Samples.

The CMAAE_DetectionAndNotification.ps1 PowerShell script performs the exact same functions as the CMAAE Runbooks.

This sample PowerShell script is to be used as a guide and can be adjusted and or extended to fit any particular post approval automation needs.

Configuration:

• Modify script parameters to match environment
• Sign Script if necessary
• Configure Scheduled Task to execute script every 15 minutes (adjust if necessary)

Post Approval Automation Overview:

Optionally CMAAE can be configured to execute a post approval System Center Orchestrator Runbook or PowerShell script. These can be used to include post approval automation such as sending additional notifications, modifying related service requests, or validating successful application installation.

Both the post approval Runbook and PowerShell automation solutions have been configured such that it is simple to provide data output from the application approval process to required Runbook or script parameters.  

Sample Post Approval Automation Runbook:

Overview:

A sample post approval automation Runbook is delivered with the CMAAE installation package and can be found under the installation directory / Automation Samples.

The CMAAE post approval sample automation Runbook is executed once the Approve / Deny decision has been submitted in the CMAAE portal. The Runbook consumes the following data from the application request:

• Requesting User
• Application Name
• Approval Decision
• Approvers Comments

The post approval Runbook automation then discovers the requesting users email address from an Active Directory and delivers an email with the approval details.

This sample Runbook is to be used as a guide and can be adjusted and or extended to fit any particular post approval automation needs.

Configuration:

• Ensure that the Active Directory Integration Pack has been imported into the Orchestrator environment
• Import the CMAAE_PostExecutionSampleAutomation.ois_export into System Center Orchestrator
• Configure the necessary Orchestrator variables (Figure 1)
• Reconfigure the Get User Active Directory activity with environmental specific global configuration
• Gather the Unique ID of the Runbook from the Orchestrator database or Orchestrator Web Service
• Configure the CMAAE Portal Application settings as detailed below (Figure 2)

Figure 1:

Application Portal Settings:

Note: it is not required to specify a value for each possible post approval data output. Only those marked as required must be completed.

• RB: False or True - this enables or disables post approval Orchestrator Runbook automation (required)
• RB_SCOWS: Address to the Orchestrator Web Service (required if RB = True)
• RB_UID: Unique ID of the Post Approval Runbook (required if RB = True)
• RB_User: Parameter to which you would like to provide the requesting users user name
• RBAppAproveDeny: Parameter to which you would like to provide the approval decision
• RBAppComments: Parameter to which you would like to provide the approvers comments
• RBApplication: Parameter to which you would like to provide the name of the requested application
• RBUserComments: Parameter to which you would like to provide the requesting users comments

Figure 2 – notice here that Approval: Application, User:, and Comments: are the names of Runbook parameters defined in the post approval sample Runbook.

Post Approval Automation PowerShell Script:

Overview:

A sample post approval automation PowerShell script is delivered with the CMAAE installation package and can be found under the installation directory / Automation Samples.

The CMAAE_PostExecutionSampleAutomation.ps1 PowerShell script performs the same function as the previously discussed Orchestrator Runbook.

This sample PowerShell script is to be used as a guide and can be adjusted and or extended to fit any particular post approval automation needs.

Configuration:

• Modify script parameters to match environment
• Store the script on an accessible file share
• Sign Script and ensure that the associated certificate is available on the CMAAE portal computer
• Ensure that the Active Directory PowerShell module has been installed on the hosting computer
• Configure the CMAAE Portal Application settings as detailed below

Application Portal Settings:

Note: it is not required to specify a value for each possible post approval data output. Only those marked as required must be completed.

• PS: False or True – this enables or disables post approval PowerShell automation (required)
• PSScriptPath: Path to Script (required if PS = True)
• PSAppApproveDeny: Parameter to which you would like to provide the approval decision
• PSAppComments: Parameter to which you would like to provide the approvers comments
• PSApplication: Parameter to which you would like to provide the name of the requested application
• PSUser: Parameter to which you would like to provide the requesting users user name
• PSUserComments: Parameter to which you would like to provide the requesting users comments

Notice that approval, comments, application, and userFromCM are the names of parameters defined in the post approval sample PS script.

Introduction: One of the more popular use cases I’ve encountered with System Center Orchestrator is the scenario where in a Monitor Alert (SCOM) activity is used to trigger automation as the result of a detected alert. A simplified yet practical example as seen in System Center Orchestrator may look like the following:

Parent Runbook monitors for alert. Once the alert is detected a child or component Runbook is invoked to perform some automated inspection / remediation. In the case of this example, the received alert indicates that the Print Spooler service has stopped on at least one monitored computer.

During the component or child Runbook the SCOM alert may be updated (resolution stated set to acknowledged), the print spooler examined, and an attempt made to start said service. Finally if the service cannot be started, an incident is raised in System Center Service Manager.

Again, this is an overly simplified example but will serve well conceptually for this post.

How then can we replicate this type of monitoring in System Center Orchestrator: Service Management Automation (SMA)?

You may have noticed that there is no native SMA activity for SCOM monitoring. Further more, because we need to write SMA automations using PowerShell workflows, the moitoring solution may not be obvious (at least is was not for myself). 

During this blog posting I will be detailing how to replicate the behavior of the above Orchestrator Runbooks with Orchestrator SMA.

SMA and Monitoring:

Simply said, at this point, in order to achieve this type of monitoring in Orchestrator SMA we need to craft the monitor using an SMA Runbook / PowerShell workflow. As it turns out, the solution I will be showing here (one of potentially many) was very simple to create. What I have done is to use a simple Do-While loop to craft the Monitor. The following can be used as a template for a SCORCH SMA Monitoring Runbook.

 Take note of the following items:

• Line 003 – here I am setting while ($True) which will create an infinite while loop, which is core to a monitoring activity
• Line 006 – Defines the monitoring interval (how often to check for the monitored condition)
• Line 008 – Here I am using an inline script which will hold all monitoring logic. This could be any monitoring condition such as checking SCOM for new alerts, checking a service, or checking a mailbox for a new email. I am placing the results of the monitor into a variable $monitorResults. To note, you may not need the inlinescript depending on the logic placed here.
• Line 012 – If the $monitorResults variable has been populated or in other words the monitoring check resulted in positive detection, we can react here. This reaction may be to execute a second Runbook such as in my initial Orchestrator Spooler example.

Practical Example:

In the following full featured example I am using a Runbook to monitor SCOM for any new alerts that match specific criteria. The Runbook completes the following:

• Checks SCOM every 30 seconds for a new alert with a MonitorObjectName of Spooler
• If an alert is detected, invokes a second Runbook that sets the alert state to 249 (Acknowledged)
• Then invokes a third Runbbok to check the state of the service. If the service is stopped, attempts to start it, and then 'returns' the service state to the parent Runbook
• If the service could not be started, a Runbook is invoked to create a Service Manager Incident.
• If the service could be started, or was running after first check, a Runbook is invoked to set the Resolution stat of the alert to ‘Resolved’.

This solution includes many different Runbooks to perform all of these automated checks and remediation's, I will only be detailing the monitor itself. A copy of the complete solution can be found here for further investigation - TechNet Gallery .

 Items to Note:

• 003 – 005: Establish SCOM Connection Information (see SMA provided SCOM sample for more info)
• 006: Variable holding the location of the SCOM PS Module
• 008: Establishing an infinite loop
• 012 – 018: This is the Monitor. The SCOM PS Module is being imported and the Get-SCOMAlert CMDLET used to gather alerts. Notice that
• 020 – 038: This is the reaction to a positive Monitor (individual details below)
• 022: Notice the Foreach –Parallel. When multiple alerts are detected this will allow all of them to be process in parallel
• 023: Child Runbook call to set the alert state to acknowledged
• 026: Child Runbook call to check service and attempt start. Notice here that the results of the child Runbook are stored in variable $checResults.
• 028 – 031: If service can be started call to child Runbook to resolve the alert
• 033 – 036: if service cannot be started call to child Runbook to submit incident.

Wrap Up: As seen here, while we do not have a native SCOM monitoring activity in SMA, crafting our own is not difficult and provides some neat flexibility. A little bit of PowerShell, some fundamental automation logic, and a bit of SMA / PowerShell workflow specific concepts and I’ve almost identically replicated what was being performed with SCOM monitoring in my original SCORCH Rubook solution.

Happy Automating - neilp 

• Post 1 – Introduction to service deployments
• Post 2 – Prerequisites for creating a multi-tier instance of Orchestrator Service
• Post 3 – Creation of SQL and Application Profiles for use in this service deployment

In this post I will be using all previously discussed topics, prerequisites and the detailed SQL Server / Application profiles to create and deploy a multi-tiered instance of System Center Orchestrator R2.

Create the Service Template:

To create the service template, right click on the appropriate node in the VMM Library node and select ‘Create Service Template’.

Give your service template a name, a release name or version, and select the service pattern. I generally leave the version at ‘new’, modifying this once completed and tested. I also generally start by selecting the blank pattern. As we will see, with all of the prep work completed across the previous few posts in this blog series, creating our service from scratch (blank pattern) is not a complex task.

At this point our Service Template will look like the following. Notice that in my demo environment I only have two Virtual Machine Templates, these are the two that were created during post two of this blog series. The first is configured to deploy a VHD which contains only the OS image and a few other prerequisites such as .Net 3.5 and current software updates. The second is configured to deploy a VHD which in addition to OS and prerequisites also contains a prepared SQL Server image. In this example I will be using both of these templates, thus will drag an instance of each onto the designer pane of the Service Template designer.

Once the VM Templates have been placed into the service pattern, the service template will look thusly.

At this point we have defined that the service being deployed will consisted of two tires, and have defined the VM templates that will be used to deploy the VM’s for each of these tiers. To keep in mind, these VM Templates contain the rules on how each VM will be deployed, such as network settings, VHD settings, and weather on not to be created as highly available. I will not detail each setting for each of these templates as these will be unique to your environment. For the most part, the core configuration of these templates will differ very little from that of just deploying a ‘standalone’ VM. Where we will see significant difference between a standard VM deployment and a service deployment is in the Application and SQL Server Configuration features.

That said, in the following section I will be detailing the configuration of the VM Template for Tier 1 of this example service.

Configure Tier 1: To recap, Tier 1 of the multi-tiered deployment of System Center Orchestrator will consist of a single VM which contains all components of the Orchestrator application (Management Server, DB Server, Web Components, and a Runbook Server). To begin configuration, right click on the VM Template intended for Tier 1 (with SQL Server) and click properties.

Give the Template / Tier a name, I’ve used ‘Tier 1 – Management Server / DB / Web Components / Runbook Server’.

Next, while we will not make any modifications, observe that this Tier will both be deployed and serviced first. It is important that this Tier is completely deployed before Tier 2 begins as Tier 2 will rely on the existence of the Tier 1 SQL Server instance. Also note that this Tier will not scale. Whereas this service instance may contain many Orchestrator Runbook Servers (Tier 2), we will only have one Management / DB / Web Components Server (Tier 1).

Tier 1 OS Configuration: Next we need to make a very minor yet key change to the OS Configuration of the VM Template. Under the Identity Information / Computer name: I have entered ‘@COMP@’. The @@ identifiers essentially create a variable that can be used throughout the service template. By creating this variable in the Tier 1 computer name position, we can dynamically specify the computer name of the Orchestrator Management / SQL Server at several different positions within the service template. This allowing us to both dynamically deploy the service, but also to deploy multiple instance of the service using unique computer names across all deployments without having to make adjustments to the service template.

Because we have created a Service Template variable @COMP@, when deploying this service we will be asked to provide a value which is ultimately that value that will be given to our Tier 1 VM’s Computer Name.

While potentially not necessary, we can also take this opportunity to add any additional Roles or Features that may not already exists on our captured VHDs. For instance the Orchestrator Orchestration Console requires HTTP Activation; as can be seen below I have configured the VM template to deploy this feature at deployment time.

Tier 2 Application Configuration: No need to go into depth here as the work behind the application deployment has been completed in the form of an application profile. So at this point we simply need to select the application profile that will deploy all Orchestrator components and also SQL Server Management Studio – this profile was detailed in post 3 of this series.

While there is nothing to detail in terms of configuration, I will point out below an example of where we are using the @COMP@ variable to dynamically specify the location of the Orchestrator database.

SQL Server Configuration: Again, nothing to configure here, we simply need to select the SQL Server profile created in post 3. To reiterate, the purpose of this profile is to complete the deployment of the SYSPREPED SQL instance contained on the Tier 1 VHD.

This completes the necessary configuration for Tier 1 in this example.

Tier 2 Configuration: to recap, Tier 2 of this service will contain multiple VM’s each containing only the System Center Orchestrator Runook Server component. Additionally this Tier will be scalable such that additional Runbook Server can be added at will. To begin the configuration right click on the VM Template or Service Tier for Tier 2 and select ‘properties’.

On the General tab give the Tier a name, I have chosen ‘Tier 2 – Runbook Server’.

I have then modified the deployment and servicing order so that this Tier is deployed and services after Tier 1.

Finally I have configured the tier for scale out. In this case I have started with a default instance count of 4 and max instance count of 8.

Tier 2 OS Configuration: Once again I am going to modify the Computer name field in the template for my Tier 2 VM template, however instead of creating variable like what was done for Tier 1, I have specified RBS0##. The ## indicates that VMM will increment values here starting with 01. So each Tier 2 system will be named similarly, however with incremented computer names (RBS001, RBS002, RBS003, etc.).

Tier 2 Application Configuration: Once again no configuration necessary, select the Application Profile created that will deploy only the Orchestrator Runbook Server component. Again pictured below is another use of the Tier 1 computer name variable. In this case we are using the variable to reference the database server during the Runbook Server deployment.

Because the Tier 2 VM’s do not require SQL Server we do not need to add a SQL Server profile, in fact this Tier configuration is now complete, click ok.

Once the Service Template has been completely configured it will appear similar to the following.

At this point we can validate the Service Templates configuration and save the template using the Save and Validate button found at the upper left hand side of the designer. Once completed the designer can be closed.

Deploying the Service Template: Now we reap the rewards of four blog posts worth of content. To deploy the Service Template, right click on the template and select ‘Configure Deployment’, Select a name and destination for the service.

On the Deploy Service window, we can observe a few items. First notice that we can see a visual representation of the service as it will be deployed, in this case 1 VM for Tier 1, and 4 VM’s for Tier 2. On the left hand pane we can see the current VM computer names for the VM’s of each Tier, and finally we see the ‘prompt’ or text box in which we provide the value to be used in the @COMP@ variable.

We could click the Refresh Preview which would engage the fabric placement algorithm ensuring that our service will ‘fit’ on the destination, or we can just click on the Deploy Service button. If there is going to be a pre-detectable placement issue, the Deploy Service wizard will let you know.

After selecting Deploy Service, confirm that you would like to deploy the service and VMM will take care of the rest. Once this process has completed you service will be baked and ready for use.

Conclusion: If you read all four post of this blog series or simply flipped though, I hope that this has been helpful in your pursuit to service deployment.

Happy Hydration..

neilp

Prerequisites Recap: If you recall from the previous posting, the following items have been created / gathered in support of this service template / deployment. Many of these will be utilized throughout this process.

• SCVMM Virtual Hard Drive with SQL generalized and ready for deployment
• SCVMM Virtual Hard Drive (without SQL)
• SCVMM VM Template for each VHD/VHDX
• The information necessary for the SQL deployment
• Custom SCVMM Resource containing the System Center Orchestrator installation media
• The commands / scripts required for an unattended installation of all Orchestrator components
• The commands / scripts required for an unattended installation of only an Orchestrator Runbook server

SQL Server Profile:

SQL Server Profiles can be added to a Server Template and serve the purpose of completing the SQL imaging process of a SYSPREPED SQL instance. In the example being detailed throughout this series of posting, the SQL Server Profile will be added to the Tier 1 VM of the service deployment and will ultimately prepare the SQL instance that will host the Orchestrator database. In order to create a SQL Server profile, navigate to appropriate node under the VMM Library workspace, and create a new SQL Server Profile. 

Recall from my previous post that several pieces of data will be required for this configuration. This data includes:

• Name of the SQL Instance: MSSQLSERVER is the default name given to a non-modified instance
• Instance ID: Specified during the SQL SYSPREP process                                                                    
• Media Source: In my example I have made a copy of the media local to the VM before creating my VHDX / VM Template. This copy was placed under c:\source\sql2012

Configure the SQL Server Deployment as seen below. In this case ‘Name:’ is an internal to VMM value and is not related to the prepared instance of SQL on the VHDX, anything can be placed here. Also notice that not only have I specified the Instance Name and Instance ID, but I have also increased the timeout value.

Configure the SQL Server Configuration thusly. Notice that not only have I specified the media source, but have specified a SQL administrator and ensured that TCP/IP and named pipes has been enabled.

Finally specify VMM Run As accounts to be uses as service accounts for the SQL instance.

This completes the creation of the SQL Server Profile and it is now ready for use in our Tier 1 configuration. I will detail how to use the profile later on in this blog series.

Application Profile for all Orchestrator Components plus SQL Server Management Studio:

In addition to completing the SQL configuration on my Tier 1 VM, I will also be deploying all System Center Orchestrator components as well as SQL Server Management Studio. These items can be taken care of using one Application Profile. Just like SQL Server Profiles, Application profiles can be added to a service template and are used to preform post VM service configurations such as installing application, executing scripts, and providing access to VMM Library resources.

To create the Tier 1 Application Profile navigate to the appropriate profile node under the VMM Library workspace and create a new application profile. On the general tab give the profile a name similar to ‘Orchestrator Management Server'.

On the Application Configuration tab add a Script Application and name it similar to ‘Orchestrator Management Server’. Recall in the previous blog that I had detailed the command that would perform a complete and unattended installation of System Center Orchestrator. We are going to use that information here. Configure the Script Application like the following:

Where the Executable Program is:

%WINDIR%\System32\cmd.exe

And the Parameters are:

/c .\setup\setup.exe /Silent /Key:<insert key> /ServiceUserName<insert service account> /ServicePassword:<insert password> /Components:All /DbServer:@computerName@ /DbNameNew:Orchestrator /WebServicePort:81 /WebConsolePort:82 /OrchestratorRemote /UseMicrosoftUpdate:0 /SendCEIPReports:0 /EnableErrorReporting:never

Let’s back up a bit and take a closer inspection of the Executable Program and parameters. Please notice the following

• Executable Program: we are not executing setup.exe for Orchestrator, rather a CMD shell or interpreter
• Because we are executing a command shell we need to specify /c indicating that the commands following should be executed
• /DbServer:@COMP@ - what is this about? VMM allows us to define variables when creating service. What we will see is that in the OS template for deploying the Tier 1 VM, we will specify @COMP@ as its computer name. Hence, we will be prompted to populate this value at service deployment time. Any place in our service template that the @COMP@ variable is referenced will consume the provided value. Essentially @COMP@ will be the name of the Tier 1 VM, which is also where the Orchestrator database will be stored, which is why I am using /Dbserver:@COMP@. I will revisit this in more detail when we configure the Tier 1 VM deployment.
• Be sure to select the Custom Resource package which includes the orchestrator media.
• Take note that several items in the parameter need to be changed to match your media / environment (anything with <insert etc.>).

Finally for the Tier 1 application profile, to install SQL Server Management Studio we will add a script to the application profile and configure it as follows:

Where the Executable Program is:

%WINDIR%\System32\cmd.exe

And the Parameters are:

/c c:\source\sql2012\setup.exe /q /ACTION=install /FEATURES=ssms /IACCEPTSQLSERVERLICENSETERMS

The one item to note here is the path to setup.exe. This is the path on the reference VM in which I have stored the SQL media.

Application Profile for only the Runbook Server Components:

To complete the Tier 2 end of this service deployment we will need an additional application profile that will deploy only the Orchestrator Runbook Server components.

So we will create a new application profile naming it something like ‘Orchestrator Runbook Server’ and configure it thusly:

Where the Executable Program is:

%WINDIR%\System32\cmd.exe

And the Parameters are:

/c .\setup\setup.exe /Silent /Key:<insert Key>/ServiceUserName:<Insert Service Account> /ServicePassword:<Insert service Password> /Components:RunbookServer /DbServer:@COMP@ /DbNameExisting:Orchestrator /OrchestratorRemote /UseMicrosoftUpdate:0 /SendCEIPReports:0 /EnableErrorReporting:never

Be sure to replace any items marked with <Insert>, as well note that where the Tier 1 application profile was configured to install all Orchestrator components (/Components:ALL), here we are only installing a Runbook Server (/Components:RunbookServer).

Conclusion:

I'm going to wrap this post up here. If you have been following along, at this point we've discussed Service Deployments and seen one in action, have gathered all needed prerequisites and configured our SQL Server and Application Profiles. Stick around as I will soon place up the final post to this series in which I will pull this all together into a Service Template for precise, mass, and repeatable service deployments.

In Post one of this series I’ve introduced the concept of Virtual Machine Manager Service Templates or Service Deployments and also introduced the example that I will be detailing in this and future posts. The initial post including a video demonstrating the end results of this service deployment and can be found here:

https://blogs.technet.com/b/neilp/archive/2014/01/15/scvmmservicetemplates.aspx

Service Deployment Prerequisites - With this post, the second in the series, I will begin detailing how this service template has been configured. More to the point, this post is all about pulling together the prerequisites. In order to achieve a service deployment similar to the example that I am working with the following items will be required:

• SCVMM Virtual Hard Drive with SQL generalized and ready for deployment
• SCVMM Virtual Hard Drive (without SQL)
• SCVMM VM Template for each VHD/VHDX
• The information necessary for the SQL deployment
• Custom SCVMM Resource containing the System Center Orchestrator installation media
• The commands / scripts required for an unattended installation of all Orchestrator components
• The commands / scripts required for an unattended installation of only an Orchestrator Runbook server

Wowza – this is a lot of requirements, however no worries, I am confident that the time spent collecting these artifacts and creating / generalizing VHD’s will pay off with the ability to both mass deploy and repeatable deploy this service with only a few mouse clicks.

During the next few sections I will be examining each of these prerequisites.

Virtual Hard Drives, VM Templates, and SYSPREPED SQL Instance:

The example service deployment detailed in this blog series consist of two different VM tiers.

• Tier One (VM1): All components of the Orchestrator application including the Orchestrator database, thus has a requirement of SQL server.
• Tier Two (VM2 – VM5): Only the Orchestrator Runbook Server component and thus does not require a SQL Server installation.

Because of the SQL requirements, I have chosen to use the concept of VMM SQL Server Profiles, and two different Virtual Hard drives, one for each tier. There are other ways that this could be performed using only one hard drive and a scripted installation of SQL, however the method detailed here works very well.

I chose to create both my virtual hard drives and my VM Templates using Virtual Machine Managers ability to create a VM Template from an existing VM which coincidentally will also create the virtual hard drive. This process is documented in the following article:

Creating a VM Template - https://technet.microsoft.com/en-us/library/hh427282.aspx .

In the case of this example I have created two reference VM’s and performed the following on each.

Tier 1 VM Source: Because this tier will include a SQL Server installation, I’ve prepared the source VM with a SYSPREP copy of SQL 2012 SP1. The following steps were used to complete this task.

• Deploy Standard VM with Windows 2012 R2
• Prepare the VM with a SysPrep instance of SQL (This is an involved process so I have detailed it independently in the below section)
• Applied all software updates to VM
• Powered off the VM
• Used the SCVMM create template from existing machine capabilities to create both a virtual hard drive from the VM as well as a VM Template

Tier 2 VM Source: This tier will not need a SQL instance. The following steps were used to complete this task.

• Deployed a Standard VM with Windows 2012 R2
• Installed .Net Framework 3.5
• Applied all software updates to VM
• Powered off the VM
• Used the SCVMM create template from existing machine capabilities to create both a virtual hard drive from the VM as well as a VM Template

After completing these tasks I am left with two VHDX files in my VMM Library and also two VM Templates which takes care of the first three prerequisites on the list.

SQL SysPrep:

To Note – at this time VMM does not support creating SQL Profiles for SQL 2012 SP1. Features have been added to SQL 2012 SP1 CU2 around image preparation that may change this experience once SQL Server 2012 SP1 is supported for deployment using SQL Profiles by VMM.

When creating the Tier 1 VM image (see previous section) there is a requirement of preparing the Tier 1 reference VM with a SYSPREPED instance of SQL . More information can be found on performing this task at the following sites

TechNet - https://technet.microsoft.com/en-us/library/ee210664.aspx

For completeness sake I will walk though a few steps of this process here.

First thing first I have done is to copy the SQL media local to the reference VM image. I have placed this under a folder at the root drive names ‘source’. This can be placed in any location however we will need to take note of this location for later use.

Second: We can being the SQL installation / image preparation. This is very similar to a standard SQL installation however will be initiated using the options shown below.

Notice that when installing a reference instance of SQL 2012 that we have a limited set of features that can be added. Also notice that SQL Server Management Studio is not one of these features. If you would like to include SQL Server Management Studio, this will need to be performed post deployment which I will demonstrate later in this blog series. This experience may change once VMM supports SQL Server Profiles for SQL SP1.

During the image preparation wizard we will select an Instance ID. This information will be required when configuring the SCVMM service deployment.

Once completed, SQL Server is generalized and prepared (notice that the services are not actually installed on the sever). At this point we can continue preparing the reference VM for the VHDX and VM Template (as detailed in the previous section of this blog).

Custom VMM Resource Containing Orchestrator Media:

With our Virtual Hard Drives and VM Templates secure, we can now begin to collect the artifacts necessary for the application deployment side of this service deployment. In this case, before we can deeply Orchestrator we will need to stage the Orchestrator media somewhere that can be accessed during the VM / Service deployment. This could easily be an external to VMM share, however we have an additional option when using VMM to store media, scripts, and other resources directly in the VMM library. In order to do so we need to create a custom VMM Library resource. Once our Custom Resource has been created in the VMM Library it can be reference in service templates. To create a custom library resource complete the following:

• Create a folder in the VMM Library Share that contains .CR in the folder name - for example OrchestratorR2.CR
• Copy the desired contents to this folder (in this case the Orchestrator media)
• Refresh the VMM Library

Once completed the following items can be observed: In the Custom Resource folder that was created a file named SCVMMCRtag.cr will be automatically created (screen shot 1), and our custom resource will be added to the VMM Library (screen shot 2)

SQL Management Studio:

Because of the SQL versioning limitation when using VMM SQL Server Profiles SQL Server Management Studio is not included in the prepared image of SQL Server. If you wish to use SQL Server Profiles and also desire to include SQL Server Management Studio with your deployments, this can be achieved using Post Deployment Scripts. This is an optional step, however one that I prefer. Being that we are just collecting prerequisites, at this point I will only be detailing the command necessary to install SQL Server Management Studio. In the following blog posting to this series I will be putting this command to use. 

I’ve gathered the following installation string from the following documentation: Install SQL Server From the Command Line .

setup.exe /q /ACTION=install /FEATURES=ssms /IACCEPTSQLSERVERLICENSETERMS

Orchestrator All Components:

For Tier 1 of this service I will be installing all Orchestrator components on one VM. In order to do so I need the commands that will make this happen. The command line installation documentation for Orchestrator can be found here: Install Orchestrator with the Command Line .

The following command will install all Orchestrator components. Notice that there are several items that need replacement here (Key, ServiceUserName, ServicePassword, and DBServer). I will be discussing the configuration of these in the next posting of this blog series.

setup.exe /Silent /Key:<Insert Key> /ServiceUserName:<Insert Service Account> /ServicePassword:<Insert Service Account Password> /Components:All /DbServer:<Insert DB Server Name> /DbNameNew:Orchestrator /WebServicePort:81 /WebConsolePort:82 /OrchestratorRemote /UseMicrosoftUpdate:0 /SendCEIPReports:0 /EnableErrorReporting:never

Orchestrator Runbook Server:

Finally because Tier 2 of this service will contain only the Orchestrator Runbook Server component, we will need the commands necessary to install only this component, which can be seen below. The following items will require adjustment below, Key, ServiceUserName, ServicePasword and DBServer.

setup.exe /Silent /Key:<Insert Key> /ServiceUserName:<Insert Service Account> /ServicePassword:<Insert Service Account Password> /Components:RunbookServer /DbServer:<Insert DBServer> /DbNameExisting:Orchestrator /OrchestratorRemote /UseMicrosoftUpdate:0 /SendCEIPReports:0 /EnableErrorReporting:never

Conclusion:

At this point we have gathered the prerequisites and in some cases created a few VMM resources that will be needed to pull this Service Template together. To recap these items are:

• Tier 1 VHDX (Server 2012 R2 with Prepared SQL Instance)
• Tier 2 VHDX (Server 2012 R2 with no additional components)
• Template for the Tier 1 VM Deployment
• Template for the Tier 2 VM Deployment
• Custom VMM Library Resource containing the Orchestrator Media.
• Commands necessary for an unattended deployment of SQL Server Management Studio (Optional)
• Commands necessary for an unattended deployment of all Orchestrator components
• Commands necessary for a deployment of only the Runbook Server Orchestrator component

Check back soon, in the next post of this series I will bring this together creating SQL and Application profiles that will be paramount to the deployment of this service.

Introduction to Service Templates: Essentially, Service Templates allow us to rapidly deploy a pre-configured services (application), consisting of one or more virtual machines, managed as a single entity, which can be scaled to match demand. A simple example may be a two tiered application consisting of a SQL Server, and a load balanced web server. As demand for the application increases, the web interface may be scaled out into a three or four NLB cluster. As demand decreases, the service can be scaled back to the initial two node cluster.

We configure Service Templates through the use of many resources already familiar to the SCVMM administrator such as virtual hard drives, VM Templates, and other VMM library resources. The service template allows us to configure how many VM’s are initially deployed as part of the service deployment, configure applications including SQL Server to be installed at deployment time, as well as to configure other scripts to be execute throughout the deployment. Finally service templates allow us to define thresholds or minimum and maximum instance sizes at which the service can be scaled.

My goal with this blog series is to not only provide an example service template, but to also deep dive on the items that need to be completed in order to create your own service templates / deployments. Rather than have one large post to complete this task, I am going to break this post up into the following chunks.

• Post 1 (this post) – Introduction and Video Demonstration
• Post 2 - Prerequisites
• Post 3 – SQL Server and Application Profiles
• Post 4 - Configuring the Service Deployment

I hope that you enjoy this series and that you can take some of the lessons that I have learned about rapid service deployment and apply them for your own benefit.

Scenario or Example for this Blog:

I will be deploying a multi-tier Orchestrator Instance that can be scaled as necessary. My initial deployment needs to consist of one server which contains all Orchestrator roles (Management Server, Database Server, Web Components, Runbook Server). I will then deploy an additional four servers which will each contain an additional Runbook server.

So my initial deployment will look thusly:

• Server 1: All Orchestrator Components (Database Server, Management Server, Web Components, and Runbook Server)
• Server 2: Runbook Server 2
• Server 3: Runbook Server 3
• Server 4: Runbook Server 4
• Server 5: Runbook Server 5

In order to achieve this goal, the following actions need to occur at initial deployment:

• 5 VM’s are deployed
• SQL Server is deployed to VM1
• All Orchestrator components are deployed VM1
• Four additional Runbook servers are deployed to the remaining VM’s (VM2 – VM5)

To close out this introduction I am going to include a video demonstration of this service deployment in action. If you like what you see, stay tuned for the next few blog posting in which I will detail how this deployment was configured.

Direct Link to Video - https://youtu.be/_QQLPvURntg

[View:https://youtu.be/_QQLPvURntg:0:0]