VMM 2012 introduces the concept of services: it allows defining service templates (blueprints of user applications), deploying services from service templates (creating VMs and applications), and servicing services with updated service templates (updating VMs and applications). A service template can contain configurable service settings that are referenced within the service template.
Service settings, just like Windows environment variables, are a set of dynamic named values that can affect the way a service is deployed/serviced.
Why Use Service Settings
The main benefits of Service settings are re-usability and deployment time configurability:
1. Reusability : Service settings can be reused across multiple tiers within a service template and are centrally configurable, this makes service template authoring easier and less error-prone for administrators. For example, in a typical 3-tier web application, the Middle Tier and the Web Tier need to access the same database; in this case, both tiers can uses a service setting called ConnectionString to set the value of the SQL connection string that should be used.
2. Deployment time configurability : Some information may not be available at the time of service template authoring. For example, since test and production environments are often in different domains, it is necessary to specify the domain name and domain join credentials at deployment time as opposed to hard coding such information in the service template itself.. Service settings provide the flexibility to defer the value assignment to deployment time, rather than baking them into the service template model. As a result, service settings make it possible to deploy multiple services with different settings from the same service template: users can override the service setting values in Service Deployment Configuration and deploy a service from it.
Syntax for Service Settings
Service settings can contain information such as computer name, file path, database connection string, etc., and can be referenced at a few pre-defined places (for example, the Computer Name property of Guest OS Profile, etc.) within a service template. A service setting is enclosed in paired at sign (“@”): for example, the Computer Name property of Guest OS Profile can be “@SQLComputerName@”.
Users do not have to define service settings first before using them, VMM 2012 will parse and find out the service settings used in the pre-defined places and show their usages, to further simplify service template authoring.
Note : A service setting name cannot contain at sign (“@”); to express literal at sign (“@”), use double at sign (“@@”).
Types of Service Settings
There are two types of Service Setting: string type and Run As Account type, depending on where the service setting is referenced. For example, a service setting referenced by the domain join Run As Account in an OS profile is Run As Account type; a service setting referenced by Computer Name in an OS profile is string type. Users do not need to specify the type of a service setting, VMM figures it out as part of the automatic discovery process mentioned earlier.
Properties of Service Settings
A service setting has the following properties:
Name : name of a service setting, and it is the string between the paired at signs (service setting delimiters)
Description: Service template authors can add description for service setting, say, about the usage.
Mandatory (1st checkbox): Service template authors can check this checkbox to make sure a value is provided during deployment.
Encryption (2nd checkbox): Service template authors can check this checkbox to tell VMM that the value needs to be encrypted and handled securely (transported/stored in DB securely).
Value : Service template authors can specify default value, and it can be overridden at deployment time with deployment specific values.
The following is the properties dialog for a string type service setting.
For Run As Account type service settings (as shown in the following dialog), Mandatory and Encryption properties are determined by VMM and are not user settable; and the Value property can be set using a Run As Account picker.
Where Service Setting can be used
As aforementioned, service settings can be referenced at a few pre-defined places, and here is the list:
1. The Value property of an application setting under an application in an application profile (see fig below).
2. The Parameter property and Run As Account property of application profile-level script (see figure below) or application-level script.
3. The Deployment Run As Account property of SQL Data Tier Application in application profile.
4. The following properties in VM Template/Guest OS Profile: Identity information (computer name), product key, domain, domain Run As account, admin Run As account.
5. Application host machine name
6. SQL script command parameters.
7. All Run As Account properties and Product Key property of SQL Server Deployment in SQL profile
Create Service Template with Service Settings
Now, we are ready to create a service template with service settings. Steps are:
1. Create a VM template from above created application profile, guest OS profile, and SQL Server profile. (In the “Library” navigation pane, expand “Templates”, right click on “VM Templates” and select “Create VM Template”)
Specify to use application profile, guest OS profile, and SQL Server profile created above.
2. Create a service template with the VM template. In the “Library” navigation pane, expand “Templates”, right click on “Service Templates” and select “Create Service Template”. For simplicity, choose to create a single tier service template.
Drag and drop the VM template from the “VM Templates” pane on the left to the service designer canvas, then click on “Save and Validate Service Template”, and close the service designer.
A service template has been created, and the service template properties dialog will show the service settings and their usage. (right click on the newly created service template, and choose “Properties”)
How Service Settings can be used
We next look at two scenarios where service settings are used: service deployment scenario, and service servicing scenario.
At the time of service template authoring, we can give default values to service settings. During service deployment, the default value of service settings can be overridden, this way we can create different services from the same service template. For example, the same service template can be used to deploy to test environment with one set of credentials and another to deploy to production environment, without having to change the service template.
For an existing service, we can service it by attaching an updated service template (with modified service settings) to it.
1. Service deployment scenario
Up till now, we have created a service template with service settings. Let’s deploy it!
During service deployment (right click on the service template and choose “Configure Deployment”), the default value can be overridden and the specified overriding value will be used for deploying that service. For example, in the screenshot below, setting “MyDomain” uses the default value “contoso.com”, whereas setting “SQLAdminAccount” overridden the default value to use “NT AUTHORITY/System” Run As Account. When the deployment starts (click the green arrow icon “Deploy Service”), the service settings will be replaced with their values where referenced, that is, the vm will join domain “contoso.com”, and SQL Server will use “NT AUTHORITY/System” Run As Account as SA account.
After a service is deployed, service settings are also stored with the service. The screenshot below shows the service settings of a different service using PowerShell cmdlets.
2. Service servicing scenario
VMM provides full life-cycle management for services. After a service has been deployed, we can still make changes to it through service servicing. We can either set the service template of the service to be the updated service template; or, if servicing is scoped to applications (e.g., application settings such as database connection strings need to be changed), we can set the servicing settings directly. Now we walk through these two different cases respectively.
Case 1: Servicing a service by updating the service template
In the following example, a newer version of the service template is created with setting “lobComputerName” value changed from “mtComputerName” to “NewLobComputerName” (this can be done by right click on the original service template and choose “copy”, then change the new copy’s service settings). Now, let’s apply the newer version service template to the service (by right click the service and choose “Set Template”, and then choose the newer version service template).
We can see the settings value change for setting “lobComputerName” (New Value in bold): Current value is the value currently being used in the service; New Value comes from the newer version service template, it is the target value for servicing. After servicing finishes successfully, New Value will become Current Value.
The summary for servicing actions is also shown. Since setting “lobComputerName” is used in an application, changing in its value leads to an application update.
After servicing has successfully completed, the setting “lobComputerName” gets the New Value (New Value before servicing becomes the Current Value after servicing), as shown in the Power Shell screenshot.
Case 2: Servicing a service by updating the service settings directly
When the servicing scope is the applications in a service, we can directly set the service settings that are referenced by application settings, and the service setting changes will be applied to appropriate applications.
In the following example, we change the service setting “lobComputerName” value from “mtComputerName” to “NewLobComputerName”. Since this service setting is referenced by a WebDeploy application’s settings, the application setting change will be applied during servicing.
Similar as the above servicing case, we right click the service and choose “Set Template”, and then choose “Modify application settings for this service”.
Next, give the new value to the service setting and click next.
The servicing actions show an update action for the WebDeploy application.
I hope you found this blog informative and helpful. For more information on SCVMM 2012 Service Creation feature please check out our TechNet Library .
Qingbo Cai – SCVMM 2012 System Development Engineer