Microsoft System Center targets cloud, virtualization

With the revamped System Center 2012 suite of management tools, Microsoft has launched a powerful new weapon in the battle to control the virtualized data center and the cloud, both private and public.

Although it’s a totally gruesome/forklift installation (yet better than before), for the first time in recent memory, all of the modules that comprise System Center are in nominal revision sync, and have increased their coverage to include the competition.

Private cloud is well covered in System Center 2012, although the focus is poised more towards Windows Azure, Microsoft’s public cloud platform. Virtualization is also heavily covered, and although the emphasis is on Microsoft’s Hyper-V hypervisor, there is also support for many heavily used, but not all, features of Citrix XenServer and VMware ESXi/vSphere.

Systems Center 2012’s coverage includes plenty of other non-Windows devices. You can deal with Windows Phone, Apple’s iPad/iPhone’s iOS 5, and perhaps that pesky department with the Android phones, too — if there’s a link to Microsoft Exchange Server controls. Microsoft is trying to change its Windows-only stripes. It’s the most egalitarian coverage we’ve seen from Microsoft, and while the added coverage is welcome, it does add to the complexity level.

We divide our review into two parts. One roughly covers SC 2012:Orchestrator, the upgraded workflow tool that Microsoft bought and presented as Opalis vNext, along with SC 2012: Configuration Manager.

ALSO FROM MICROSOFT: Microsoft raises the bar with SQL Server 2012

The second part of the review covers SC 2012:Service Manager, AppController, Virtual Machine Manager, and Data Protection Manager. Microsoft Endpoint Protection Manager is excluded– we have insufficient resources to pound it.

Infrastructure You’ll Need

We needed a lot of hardware in the form of VMs to make the full installation of all modules work. At minimum, a server/VM instance with 40GB of disk and reasonable memory is needed for each module. Underneath System Center 2012 activity is commonly SQL Server 2008 R2 as an engine. (See our review of SQL Server 2012.) Many modules also seem to need their own hefty hardware (or healthy VM instances).

None of the modules are recommended to be run on Active Directory Domain controllers, necessitating additional instances. Microsoft wants to play a dominant role in the enterprise, and we feel that for many Microsoft-centric organizations, System Center could be a good, if non-trivial choice.

Each module needs planning prior to installation. Modules cannot be reasonably expected to be installed without the Unified Installer, which also presumes you’ve done your homework. Homework includes understanding the prerequisites of each module (they’re all slightly different) and having prerequisites installed, like the aforementioned SQLServer, and in most cases, IIS with various mandated tunings/settings. We found this the hard way. Use the Unified Installer after homework is done.

Despite the heterogeneity of the System Center 2012 pieces, Microsoft clearly advances its own products first, as might be expected. More interestingly, it also adds features that clearly attempt to replace premium features of its competition — while managing competitive virtualization and cloud infrastructure. System Center 2012 works especially well, and advances the viability of Microsoft’s Hyper-V infrastructure. As an example, SC 2012: Virtual Machine Manager offers strong management of virtualization instances in the contexts of private cloud and public cloud (which usually means, but is not confined to, Microsoft’s Azure cloud resources).

As an example, the SC:VMM modules can do bare metal installations utilizing Hyper-V, populate the hypervised bare metal with Windows or Linux instances (SuSE instances, but Red Hat, too, if you must).

SC:VMM also can control VMware ESX/ESXi instances, too, but many VMware features found in VMware vSphere 5 still require vSphere 5. The benefit gained is largely control nexus for common tasks used in managing VMware-based instances. The same can be said for XenCenter and Citrix’s XenCenter management.

Orchestrator

System Center 2012:Orchestrator is perhaps the most compelling module as it’s an advance of Opalis, the IT process automation tool Microsoft acquired in 2009. Orchestrator makes Runbooks, through a Runbook Designer, which amounts to an understandably customizable script generator that goes deep into Microsoft infrastructure to do complex jobs. The Orchestrator module must have at minimum, a server largely dedicated to the work of building, managing and deploying the Runbooks, which are objects that contain the instructions that deploy resources for en masse distribution.

Runbooks are workflow instructions, and there are already online runbook resources available that can be added to the examples that come with Orchestrator. The runbooks are scripts, and scripts can be edited and replaced with locally specific variables that tailor runbook activities which are instructions that the runbook/script will execute.

In turn, the scripts can be stored, or placed into a workflow timeline that can themselves be triggered by events, such as a progressive installation of an application. We discovered too late that we could have used Orchestrator to install SQLServer, establish the role of IIS and make some of the modifications needed to make Orchestrator work.

We could import runbooks, or use Runbook Designer to get a wysiwyg view of “stock” scripts, or ones we built from scratch. Dependencies, and the specific names of assets and resources can be easily filled in to the process to make Orchestrator develop and execute some fairly complex jobs. Runbook Servers then do the work, and the first Runbook Server added becomes the Primary Runbook Server, and subsequent servers can be largely autonomous. This allows branches, or clouds to have largely autonomous script executions for workflows of installations, updates, and other work.

We tested several runbooks that performed application installation between servers in our lab and our network operations center at nFrame in Indianapolis. We queued them into life by a simple user batch click. The event is then logged (Microsoft warns that the logging database can become huge; why don’t they use a syslog, we wondered?) and there are many ways to control runbook executions, in terms of the number of concurrent jobs that are allowed, permissions to use while doing various parts of the job(s), and the kinds of activities that can be performed — including the customizable activities.

Orchestrator comes with Integration Packs that are the connection points to make runbooks that control Active Directory as well as third-party software. Currently offered are integration packs for HP’s iLO/OA server management, HP Operations Manager software, HP Service Manager, IBM’s Tivoli Netcool/OMNIbus infrastructure management suite, and VMware vSphere. As we’re too small a shop for the hardware network management apps, we didn’t test these. But we did take a long look at VMware integration, as we’re very familiar with it.

The Orchestrator module doesn’t replace vSphere, but it knows how to automate many daily grind and grunt tasks. After mapping a lot of vSphere information (addresses, machine names, host platform information, hypervisor datastores, we were able to do the job of moving an ESXi VM from one machine to another. But it took a lot of work.

There are limitations to the control of Orchestrator Integration Packs in VMware environments, particularly when it comes to being able to use the decision intelligence of vSphere 5 to make choices about storage and resource management. Until Orchestrator gets an API that can stealthily grab more infrastructure conditions information to move VMs around to load/storage balance ESXi-hypervised servers, they miss an important part of vSphere’s control mechanism — which is a VMware secret sauce. Nonetheless, the Orchestrator integration controls for VMware were found compelling, if daunting to put together.

On a good day, part of the use of Orchestrator is execution of packaged “normal” events, while the other part of the day is spent monitoring logs. There is a lot of initial planning that is required to put Orchestrator to use, and then like every new hammer, there’s a stage where we wanted to craft runbooks to do all sorts of things, some of which really don’t need automation. There is a reporting and documentary test that applies discipline to what runbooks do — a task is performed according to a runbook, which plays nice with consistency and auditing. It’s nonetheless non-trivial to put Orchestrator to work — you have to train large parts of the symphony.

Systems Center 2012: Configuration Manager

Like Orchestrator, Configuration Manager requires planning and forethought before the first installation can commence. Configuratoin Mamanger uses SQL Server 2008 R2 as its engine, and like Orchestrator, needs to live in a separate instance from an Active Directory domain controller. Indeed, as much work can be stopped if SQL Server becomes unavailable or mangled, frequent backup and replication and/or clustering might be a good idea.

Configuration Manager needs at minimum, a site server and site database instance (they can be in the same machine or VM instance) along with a component server (can also be combined with the site or database server in small installations). So far, we have three server instances that can be combined. The SQL Servers can’t be mirrored, which bothered us. High availability is important here.

Configuration Manager sites consist of primary and secondary. Secondary sites are used as distribution points, so as to conserve bandwidth by multicasting through a hierarchy of sites. This also works well for multi-branch/multi-regional sites, where language or audit/compliance technique and reporting may be different, which is another reason that larger organizations will need to bury themselves in the System Center documentation to understand the implications of how and where Configuration Manager sites are deployed.

After reading the considerations, we installed Configuration Manager using the Unified Installer. There’s an option that extends the Active Directory schema to accommodate a container that allows trusted installation, but we didn’t test this. The Site Server has roles that it takes on as storage points for configuration functionality. This might mean storage for Windows updates via Windows Server Update Services (WSUS), or as an anchor point for the remediation performed by Microsoft’s Network Access Protection policies. There are any number of possible Configuration Manager roles.

Configuration Manager inventories, deploys, audits, and maintains application instances, and operating system instances and their licenses — and is largely incapable of doing this for non-Windows platforms, unlike the increased heterogeneity of Orchestrator. However, if you’re using Windows in a big way, Configuration Manager can discipline the deployment of apps and OS instances, while making the work much simpler than manual alternatives.

There are several stages in a device’s life cycle where Configuration Manager comes into use. Windows operating systems along with applications payloads are brought into life onto bare metal. A Windows-based Configuration Manager agent then is used to manipulate the device, either by push or pull commands for information. Windows Mobile 6+, Symbian Belle phones, certain Windows embedded systems versions, and mobile devices that use the Exchange ActiveSync API (Apple iOS 4+, certain versions of Android) can be configured and managed through their life cycles, too.

Pushing operating systems

There are several operating systems deployment methods available with Configuration Manager that we found compelling. First, one finds a suitable image as a payload. You can capture one, or use a converted ISO image. It would be good to use one that has needed drivers, or even the right software load so that you can do everything in a single step, subject to localization, customization, and so forth. We’re used to doing that in our labs.

The next step is to choose a distribution method. There’s good-old PxE (Pre-boot eXecution Environment), which uses Windows Deployment Server. Indeed, you can use PxE without Configuration Manager at all, subject to licensing constraints and local implementation. Configuration Manager adds its value by allowing a RemoteInstall folder to be built, so that images can be rotated in and out of a centralized distribution point, where one might normally stage operating system deployments on to new or retrofit hardware.

We tested this method, and it worked for our test Windows 7 Professional instance. We used the WDS, made an IPv4 local network, configured the RemoteInstall folder and resource payload, did the WDS configuration work (simple enough), and booted the image onto a Lenovo T520 test machine.

It’s also possible to make a boot CD/DVD or flash drive that redirects a similar link to the WDS configuration to make a machine swallow the desired operating system payload, but we didn’t test this. So as far as we know, it could be used for non-Windows instances.

Making the inventory comply

Software apps, content and updates are distributed in similar ways, but System Center 2012: Configuration Manager can also create objects of information regarding inventory and states through a metaphor called Collections. Collections are groupings of users, or devices (not both). Data is collected once (or simply accumulated in counts) or is checked in intervals. Microsoft warns against querying “global” information in intervals, as this spawns a huge, and potentially useless event. Through the collections, we could tabulate items set for compliance. Compliance means inventing, then checking the existence, or through a custom script, the state of an object — perhaps an application. We tested with a rudimentary example that used a built-in check box, of calling upon the client’s Windows Installer file existence, in our case, Windows Office 2010 that was installed on our Lenovo T520 notebook. It was more sophisticated, and customized scripts can be deployed.

Where machines can tell their power state, one could also conceivably test power settings for machines. This could be interesting in terms of Carbon Trading compliance, but we only pay a pittance for our coal-powered electricity in Indiana, so we didn’t mess with it.

Reporting requires SQL Server Reporting, and many queries of inventory, compliance, and general activity logs were pretty easy. We could also see how the tables could be modified to make things look perfect, and so from an auditing perspective, auditors will need to note that we could export, manipulate, and re-import tables to make them look crystal clear — but you’ll need to be a good database administrator to know how. If we played by the rules, the reports were actually both simple to use, and with a few annotations, simple to understand, even for a CIO.

Summary

Configuration Manager, like Orchestrator, requires considerable planning, but can be started in at a simple level. Successful implementations will take an investment in the time, energy, and resources of high-level systems personnel to reap benefits. It’s highly sophisticated, and dives very deeply into a strongly Windows-based system. Its application into a small/mdisize organization may be helpful, but larger organizations will find its depth very useful.