Building a private cloud with System Center 2012: Part 2
In the first part of our Microsoft Private Cloud experience we spent a couple of days sourcing suitable servers, configuring the seven virtual machines we needed to run System Center 2012 and installing the components required for private cloud management.
It was a lengthy process, and we had to think on our feet, but we got through it with only minimal head scratching. However, that was just the beginning of the journey: in part two we work through the next stage of the process — joining up our System Center 2012 tools.
Starting over
According to Microsoft's Private Cloud Evaluation Guide, one of the biggest strengths of System Center 2012 is its "integrated approach to workflow, knowledge and data management" — an approach that underpins the whole private cloud concept.
However, that integration doesn't just appear by magic — it must be programmed in using System Center 2012 Integration Packs. Furthermore, we had to first register and deploy the packs, and then configure them (individually, as it turned out) to work with the servers on which we had installed our System Center components.
This wasn't a particularly complicated job — all we had to do was follow the instructions in the evaluation guide. It was, however, very repetitive and time consuming, and there were the inevitable technical hiccups to deal with along the way. The first glitch was the need to reactivate all of our Windows Server licences.
This was necessary because, just as in a real life, we're not able to work on our Private Cloud evaluation full time, and a couple of weeks had elapsed since we first configured our virtual machines. On boot-up, each one told us that activation was required, displaying a black rather than blue desktop to emphasise the point.
The instructions insisted that we needed to extend the grace period for activation of Windows Server 2008 R2 on each one of our seven VMs. Simple enough: just boot up Windows, log in, type in the command required (slmgr –rearm) and reboot.
Doing this seven times would have been tedious enough, but we'd also have to repeat the process every 10 days. Fortunately we found that simply taking the option to activate Windows from the Control Panel caused our evaluation copy to be 'magically' licensed for a full 180 days. So that's how it works!
Registering and deploying the Integration Packs
A second issue arose as soon as we began the process of registering the Integration Packs (confusingly abbreviated to IP in some of the tools). This is done on the Orchestrator server using the System Center 2012 Orchestrator Deployment Manager, which has a wizard to help with just this task. This is all very well, but you do need to download the Integration Packs first — something the evaluation guide omits to tell you.
Still, never mind. A quick Google search soon located the packs, which were duly downloaded and then, using the wizard, registered with our Orchestrator server. It did take a while, though, as we had to register each pack separately, starting with Virtual Machine Manager and followed, in turn, by Data Protection Manager, Operations Manager and Service Manager.
No mention was made of the Active Directory Integration Pack, although much later in the guide you're told that this is also required in order to complete the evaluation. Because we were working our way religiously through the guide, we didn't discover this information until it was too late to do much about it. If you're planning an evaluation, you can save time by including the Active Directory pack along with the others at this point in the process.
The next step was to deploy our newly registered Integration Packs to the Runbook server — a crucial step as Runbooks contain the instructions used to automate tasks and processes.
In in our case the Runbook server was also the Orchestrator server, so it came as no surprise to find this was also done from the Orchestrator Deployment Manager with the usual wizard to help. For once, there were no issues to contend with.
(Continued)
Configuring the Integration Packs
Next we needed to configure the Integration Packs to use our servers. This meant specifying the name of each server, its host domain and a suitable username and password, starting with the Virtual Machine Manager pack.
Before we could do that, however, we had to quickly log onto our VMM server and use PowerShell to allow configuration files and scripts to be run remotely.
That done, we opened the Orchestrator Runbook Designer and, following the instructions in the evaluation guide, configured our VMM Integration Pack. Note that our test domain is called ellipsis.local and we were using the local administrator account for authentication.
We then repeated the process for each of the four other Integration Packs — not forgetting, when you do it, to include the Active Directory pack to save time rather than following the guide to the letter.
Some care is also needed to make sure that you type all the names in correctly as you're creating a fairly complex web of servers. Although some of the packs let you test the connection (as in Service Manager, shown below), some don't provide the option.
Additionally, when it comes to the Operations Manager Integration Pack you must first install the Operations Manager console on the Orchestrator server. For some reason, the process required is documented in Appendix B at the back of the evaluation guide, where you're told that the Operations Manager console needs to be installed on the Virtual Machine Manager server as well.
Fortunately this proved to be relatively straightforward using the Operations Manager setup program included in the original Private Cloud download. We did, though, have to first install .NET Framework 4.0 onto our Orchestrator server and, once we had located it, the Microsoft Report Viewer 2010 distributable onto both this and our VMM server.
We were then able to go back to the Orchestrator VMM and configure the Operations Manager Integration Pack, this one having the option to test the connection.
And finally, we repeated the process for the Data Protection Manager, the only prerequisite here being to first enable PowerShell remoting on the DPM server by typing in another simple PowerShell command.
A magnum opus
The only other work required was to create some user accounts for the exercises to follow. The main ones were Jeff, our mythical datacentre administrator and Emily, an application owner responsible for a line-of-business application to be deployed on our Private Cloud. A couple of others are also required, but we'll talk about them, and the other steps required to join all our System Center components together, in part 3 of what's rapidly becoming something of a magnum opus.