Exchange Server 2013 CU2 Service Templates - Setup and Best Practices
This blog post is part 3 of 3 in a series.
This series of posts that detail how to deploy Exchange 2013 CU2 using Service Templates in Virtual Machine Manager. If you are just landing on this subject I recommend starting with Part 1. This page will focus on what you need to do import and configure the service templates, as well as best practices you should follow if considering deployment in production environments.
|Blog Series: Table of Contents|
Part 1 – Philosophy/Overview – Define scope and assumptions.
Part 2 - Prerequisites – Document any unique pre-work and link to all downloads that should be ready before getting started.
Part 3 - Setup the Service Templates in VMM and Best Practices – Document the process to setup and configure the service templates in VMM.
Exchange Server 2013 Service Templates for System Center Virtual Machine Manager
Before you begin - Make a decision about how you will extend Active Directory
Run As Account
VMM needs an account to run the commands for installing Exchange. What account you select depends on your scenario so let’s be a little bit careful here.
Question – will your forest and domain already be prepped for the new Exchange Org using the Exchange 2013 CU2 Schema Extensions?
If the answer is YES, then the Run As account will only need to be a domain account with permissions to write to the directory to add references to the Exchange server object. This is similar to permissions that would allow for joining the computer to the domain. You probably already have that setup in VMM for provisioning new VMs to automate the OS installation process, in which case you can select that account and move on (if your directory permissions are granularly delegated, you may need to consult your Directory Services administrator to agree on which account should be used for this process).
If the answer is NO, you have a decision to make. Exchange setup will attempt to extend the schema during install if it has not already been completed, unless you suppress it. You need to decide whether you will want to create a Run As account with this level of permission. In enterprise scenarios, you are almost certainly not going to allow this in production as schema extensions should be carefully planned and executed under change management process. In a test lab, it is very possible that you are fine with it. In a tenant provisioning process, you might have the ability to temporarily utilize such permissions during build and then revoke access before data is introduced.
The direction you proceed pivots on the scenario you are trying to build. I can however guide you through the technical process.
Open the VMM console and connect to the VMM server where you will import the service template. Click on the Settings button on the bottom left corner and then expand out Security. Click Run As Accounts and review what you already have in place. If a new account is needed, click the Create Run As Account button and complete the form. When you are done click OK.
Setting Up The Service Templates In VMM
Download the service templates from TechNet Gallery and extract the contents of the ZIP file. Here you will find the XML files and a ReadMe.txt that references this site. The resources for each template are the same, so I am only providing one walk-through of import and domain settings. Even though the screenshots reference the SSA, the same process is true for MSA. The application settings are slightly different. Details are explained in the application settings section.
First - Import the Files
Launch the VMM console and click on the button in the bottom left corner for Library, then expand Templates on the left pane and select Service Templates, and then click the button on the ribbon Import Template. Now browse to the location of the XML file. There are no sensitive settings in the XML so you can ignore the checkbox and click Next.
On the next page you will see a series of warning signs as well as a red X. As IT Pro’s we have a well developed synapse that triggers a gut reaction that everything is broken. Relax, nothing is broken. Take a sip of coffee as we prepare to edit each line and map the template to the resources in VMM created during the prerequisite section.
Click the pencil icon next to each line and map to the item you created in VMM. To simplify as much as possible, here is a reference table to assist.
Map this to the formatted Data.VHDX file you created and stored in the library.
Map this to the VM Template for Windows Server 2012 (created independently of this guidance).
Map this to the Run As Account you created that will be used to install Exchange.
Map this to the Run As Account by the same name in VMM. This should exist by default without creating anything new.
When complete, click Next.
Finally, review the settings that will import the ST. You may also want to click on “View Script” so you can see exactly how you would do this using PowerShell if you were to automate such a workflow in the future. Click Import and you are done!
Second – Configure Your Domain Settings
OK, that was not the end of the world, was it? We went through a lot of steps. Hang in there. We are going to add the finishing touches so the VM joins a domain.
Right click on the new service template and select “Open Designer”. This will give you the view below.
Right click on the center box and select Properties (for MSA you will see two boxes). This is your opportunity to customize anything you feel comfortable with according to your environment. Browse through the Hardware Configuration and validate the configuration. Pay special attention in the OS Configuration tab to customize the fields in the list below:
- Identity Information – this is defaulted to “EX” followed by a 2 digit counter supplied by ##. Does this comply with the standards you have in mind?
- Admin Password – set this according to the password standards for your environment.
- Domain / WorkGroup – to make the import go smoothly this is set with a placeholder in the Workgroup field. Switch to the Domain radio button and provide the full DNS name for your domain and either enter stored credentials or select a Run As Account.
Third – Configure Your Application Settings
This is the one area I want to fork and explain SSA and MSA a little bit differently per workflow. I made the conscious decision to make the SSA backwards compatible with VMM 2012 SP1. It is a simple workflow, and 2012 SP1 can handle it with no problem. On the other hand, MSA is more interesting because you have multiple servers all coming online at about the same time. The first server is going to extend the Active Directory schema and the others should wait for it to finish. If you have multiple Mailbox servers across fault domains, that creates a minor race problem. Never fear. There are new capabilities in service templates for VMM 2012 R2 that make this a breeze and actually make a difference in how we work with more advanced application installs going forward.
Part 1: Customize Application Settings for Single Server Architecture
Select the Application Configuration tab. You will notice three Script items. This is the set of commands that the service template is going to run in order. Review script items Pre-Install 1 and Pre-Install 2. These should not require any editing but if you click on the Advanced tab you can review the configuration including the location where logs will be written within each VM during installation.
Now select Pre-Install 3. This script is where we actually run Exchange Setup unattended. We really don’t need to make any changes but I want to call attention to 2 items.
- Place your mouse cursor in the Parameters: field. Ctrl-A to select all and copy the full string to Notepad. Verify the install string. You will notice @Organization@. This creates a mandatory parameter you can enter at run time. The value is used to name the Exchange Organization. If this will always be the same, you can replace it with something static.
- Note that the database name is based on the server name so it is unique per server. See comments at the end of the post regarding impact of database name when considering database availability groups.
- Review the value in the field Run As Account. If a change is required, select the account to run the Exchange install.
Part 2: Customize Application Settings for Multiple Server Architecture
If you are a frequent user of VMM 2012 SP1 and ready to move to VMM 2012 R2, take a look at the graphic below. Specifically, check out the application section. There is a new Script Application type in R2!
Right click on the each server role box (the large two in the middle) and select Properties. In the above section we validated the Parameters string and the Run As Account. For each server role in this case, please do the same. You just want to make sure these align with how Exchange should be installed in your environment.
Note the Specify a script block section. If you require something more advanced to be run during install such as looking up values and passing them in as parameters, VMM now allows you to do this directly.
There is also a Timeout (seconds) value. This is the duration of time that the script is given to execute before VMM cuts it off and considers the job to have failed. I have set this to an hour. If for any reason you need more time, or if you believe that is too long, this is a new ability to tweak the setting.
Looking specifically at the Mailbox Server role, in the Application Configuration dialogue, you will see I have a third pre-install script with a unique title. Another new feature of VMM 2012 R2 is the ability to execute a script only for the first VM, or only on VMs other than the first VM. The same is true for deleting VM’s should you ever decide you need a “cleanup” task.
I have utilized this functionality to separate out the action of extending the schema for Active Directory. This will occur only prior to creation of the first VM.
Fourth - Save and Validate
You can browse the remaining tabs and click OK. You may wish to further customize the template and that is OK. This is yours now! You may wish to utilize Quota Points, Custom Properties, etc, in self-service scenarios or in the case of additional automation.
Don’t forget to click “Save and Validate” in the top right hand corner to save your changes.
Finally - Deploy the Service Template
Everything is setup and you are ready to deploy. I am not going to recreate the TechNet documentation here. If you are unfamiliar with the process please visit the link below.
How to Deploy a Service in VMM
I do want to post a reference just so you have a complete walk-through. You will need to select the Virtual Network when you create the deployment configuration and provide a name for your organization. The organization field is mandatory before you will be able to deploy the service. The space to enter the value is in the lower left hand corner of your screen.
Follow Best Practices (VERY IMPORTANT FOR PRODUCTION SERVERS)
There are post-installation tasks I consider requirements for production. The service template deploys the Exchange application but if you plan to introduce the new server or servers in to production, you should think about how this fits in to your normal Exchange configuration workbook. You can reference the Exchange documentation on TechNet as well as the tool the Exchange team has provided to serve as a checklist. These additional items would be suitable for Orchestrator or SMA if your are deploying at scale.
Install production certificate, assign services, update URLs
If you deploy a new server in to an AD site where there are production users and do not complete the unique configurations for your environment, you could disrupt users by prompting them regarding an invalid certificate, and eventually lead to errors occurring in the Outlook client.
This would be a great way to extend the service template provided here to include unique information about your environment. In an automation platform where VMM is combined with Orchestrator/SMA, this would also be an excellent task to occur next in a production-targeted workflow.
Move the Data VHDX to a different spindle than the OS VHDX
The Exchange guidance clearly indicates that the best practice for virtualization is to put the OS and Data on different spindles (different hard drives). The service template creates separate Virtual Hard Disk files but does NOT automatically guarantee that they will be located on different storage. This creates one post-install task you should take as the admin, that is to consider your storage configuration and determine if you are using a large storage array and the files will already benefit from spreading disk IO across spindles or if you are using something like direct attached storage. If so, you will want to Live Storage Migrate the Data.VHDX file to a separate drive from the VHD where your OS virtual hard disk lives. The key word here is Live so it will not require downtime but you should complete the activity prior to using the VM as anything more than a test server.
Consider whether you will add additional databases
While reading various posts and talking to people about this project I learned it is not unusual to create a new database after install. To automate the process I have set the unattend parameters to create a default database using the naming convention “<ServerName>_Default”. Especially if this server will be part of a Database Availability Group that will be replicated across servers, it will make sense to create a new database for user accounts with a standardized naming convention that suits your environment.
You now have service templates for Exchange! Thank you for sticking with the entire walkthrough. We have deployed all prerequisites, configured the service template at import, and configured the unique settings in Designer. I know it is a lengthy post but details count. If you feel lost, I have recorded a full length walk-through. I would recommend you skip to the place where you would like a visual aid. I have included bookmarks to help.