Wednesday, October 23, 2013

System Center 2012 Integration Guide - Operations Manager


System Center 2012 Integration Guide - Operations Manager

This document is  part of a collection of documents that will make up the System Center 2012 Integration Guide.  The purpose of the Integration Guide is to provide an overview of each System Center component in its role as a programmable platform to be leveraged for the Microsoft Private Cloud.  It is intended to provide an abstraction layer that guides partners and customers on their decision process for methods to build automated solutions across System Center components and between System Center and other systems.
This guide is a community project to analyze the different options for integration with the components of Microsoft System Center 2012.  Please feel free to edit this document to improve its quality.

Table of Contents


1 Product Overview

System Center 2012 Operations Manager enables you to monitor services, devices, and operations for many computers from a single console. Operators can gain rapid insight into the state of the IT environment and the IT services running across different systems and workloads by using numerous views that show state, health, and performance information, as well as alerts generated for availability, performance, configuration and security situations.
The following diagram shows the different technologies for integrating with System Center 2012 – Operations Manager from other software, hardware, and System Center components.  Each of these technologies is discussed in the following sections.



Product Documentation

2 Role in the Microsoft Private Cloud

The following table briefly introduces the capabilities that VMM provides as part of the Microsoft Private Cloud Reference Model.  Further details are provided in Mapping Private Cloud Capabilities to the Microsoft Private Cloud Platform.
 Layer Description
Service Delivery LayerThe primary function of Operations Manager within the Services Delivery Layer is to support Demand Management which enables the reliable offering of services in the private cloud.  
Infrastructure LayerOperations Manager provides instrumentation to measure the resource demands of services within the private cloud so as to support proper sizing and dynamic distribution of resources.
Service Operations LayerThe Service Operations Layer includes all the routine administrative tasks performed on the private cloud infrastructure.  Operations Manager enables this layer by exposing its administrative functions through cmdlets.
Management LayerOperations Manager provides the means to define instrumentation to measure the health of the cloud fabric and services deployed within the cloud.  In addition, it provides detailed reports on performance availability of those services.

3 Programmability

3.1 Operations Manager SDK

The System Center 2012 - Operations Manager SDK  can be used to access all data and functionality of Operations Manager.  This is the preferred integration technology to use if you have an application, such as an alternate console, that requires access to Operations Manager.
The Operations Manager SDK is also useful to the administrator for those functions that do not have a Windows PowerShell cmdlet available such as retrieving performance data and creating overrides.  Windows PowerShell has the ability to access any .NET assembly so that the entire Operations Manager SDK is available to it.  Information on using a .NET assembly with Windows PowerShell is available in Creating .NET and COM Objects (New-Object)  .

3.1.1 Creating management packs Using the SDK

You can use the Operations Manager SDK to create and edit management packs.  This could either be editing a management pack installed in a management group or creating a new management pack offline.
It is typically easier to create and edit management packs using one of the available editing tools as opposed to programmatically creating it with the SDK.  The SDK should only be used under scenarios where a programmatic method of working with the management packs is required.  Examples of scenarios where the Operations Manager SDK might be used include the following:
Examples on creating management packs and management elements using the SDK are available in Automating Management Pack Development  .
References

      3.2 Windows PowerShell Cmdlets

      Operations Manager has Windows PowerShell cmdlets  available for performing many administrative functions from a command line. This includes such functionality as the following:
      • Creating administrative elements such as RunAs accounts.
      • Deploying and configuring agents.
      • Retrieving and modifying alerts and events.
      Not all Operations Manager functionality and data is accessible through cmdlets. You can use Windows PowerShell to access the Operations Manager SDK for these scenarios as described in the previous section. Example of scenarios where no cmdlets are available include the following:
      • Retrieving performance data.
      • Creating overrides other than basic enable/disable of workflows.
      • Creating or modifying management packs.
      In System Center 2012, some of the Operations Manager cmdlets are shared with Service Manager because the two components share an underlying architecture. These shared cmdlets use a noun prefix of SC. An alias is created usingSCOM as the noun prefix in order to better align these cmdlets with those cmdlets that are specific to Operations Manager.
      References

      4 Integration with other Management Systems

      It is a common scenario to use Operations Manager with other monitoring tools.  Operations Manager may be used exclusively for data collection and alert creation while administrators interact with the other tool.  Alternatively, Operations Manager may provide the primary console with other monitoring tools provide it with additional data.
      When Operations Manager interacts with another tool in this manner, the primary requirement is to synchronize alerts between the two systems.  This includes creating new alerts and modifying alert properties.
      In Operations Manager 2007 R2, the primary means of synchronizing alerts between Operations Manager and other systems was through a connector.  An Operations Manager connector specifically created for the other system was required for this purpose, and a variety of connectors were available as documented at Operations Manager 2007 R2 Connectors  .

      4.1 Orchestrator Runbooks

      In System Center 2012, Orchestrator runbooks have replaced connectors as the preferred method for synchronizing alert data between Operations Manager and other systems. Runbooks provide the following advantages over connectors:
      • More complex logic that potentially includes multiple systems.
      • A wider range of supported systems.
      • No need for a specific connector since Integration Packs are general purpose.
      The System Center Integration Pack for System Center 2012 Operations Manager  includes activities that retrieve and modify alerts from an Operations Manager management group.  The only requirement for the other system is to have an Integration Pack available. An Integration Pack provides a set of activities that work with a particular application or component, and a single runbook can be made up of activities from multiple Integration Packs.  In a connector scenario, the Integration Pack only needs activities specific to the other system and has no specific knowledge of Operations Manager. Information on the Integration Packs currently available is at Integration Packs for System Center 2012 - Orchestrator  .
      References

      4.2 Connectors

      The one challenge that runbooks have in comparison to connectors is throughput.  Orchestrator is a scalable product with the ability to distribute runbooks across multiple servers.  Alert synchronization though typically requires relatively few runbooks (or even a single runbook) running every time an alert is created or modified. This can create a bottleneck when handling a high volume of alerts.
      The connector framework in Operations Manager was designed to be lightweight technology focused on a single function supporting a high volume of alerts. System Center 2012 has the same connector framework from Operations Manager 2007 R2. New connectors can be created using the Operations Manager Connector Framework  , and existing connectors will work without modification.
      References

      5 Management Packs

      Management Packs contain logic for discovering and monitoring the health of the elements of an application or device that is monitored by Operations Manager.  Management packs are available for each of the System Center 2012 components and for most Microsoft server based applications.  Management packs are also available from a variety of vendors for different applications and devices.  To access the complete set of available management packs, see theManagement Pack Catalog  .  If a management pack is not available for an application or device, then you must create one in order for it to be monitored by Operations Manager.
      Management packs are implemented in XML files that adhere to a particular schema.  Operations Manager 2007 R2 uses version 1.0 of the management pack schema, while Operations Manager in System Center 2012 uses version 2.0.  Since the schema is backward compatible, any management pack written using the version 1.0 schema will work in both Operations Manager 2007 R2 and System Center 2012.  Management packs written with version 2.0 schema will only work in System Center 2012.
      There are very few advantages to using the version 2.0 schema for most monitoring scenarios, so it is recommended that you use the version 1.0 schema for all management packs in order to ensure that users can use them in both versions of Operations Manager.  The only reason to use  the version 2.0 schema is if you are creating a management pack using features specific to System Center 2012.  The only such features at this time are dashboards and network monitoring.
      If you are designing a management pack that requires one or more dashboards, then you should create the dashboards in a separate add-on pack for System Center 2012.  The rest of the management pack should be implemented in the original Operations Manager 2007 schema.  If you are designing a management pack for monitoring a network device, then you should use the format specific to the version of Operations Manager that you are going to support.
      There are a variety of resources for learning how to create management packs as listed in Operations Manager Management Pack and Report Authoring Resources.  The Authoring Guide for System Center 2012 – Operations Manager  is targeted at users new to management packs and is limited to those monitoring scenarios that can be implemented in the Operations Console.  The System Center Operations Manager 2007 R2 Management Pack Authoring Guide provides complete detail of management pack concepts applicable to each version of Operations Manager for the intermediate to advanced author.

      5.1 Cross Platform

      Operations Manager can monitor UNIX and Linux computers  by designating a resource pool  to manage it.  The rules and monitors are run on the management servers in the pool and access the Linux/UNIX system to collect required information.
      Management packs are available for multiple Cross Platform Operating Systems  .  These management packs provide complete monitoring for the operating system that they are designed for.  For applications running on these platforms, you can create custom management packs using the Cross Platform Management Pack Authoring Guide  .

      5.2 Network Monitoring

      Operations Manager 2007 R2 includes support for monitoring network devices.  Any device that supports SNMP version 1 or 2 can be added to a management group and will be monitored for basic up/down status.  Vendors of network equipment may provide management packs that provide more detailed monitoring for their devices.  These management packs are typically based on the Network Monitoring management pack included with Operations Manager 2007 R2.
      System Center 2012 includes more detailed monitoring for a variety of network devices  .  In addition to SNMP version 1 and 2, it supports SNMP version 3, and it supports monitoring at the component level rather than focusing on the device itself.  It can provide a health for individual ports and other components of the device such as processors or power supplies.
      Vendors with a network device that is not included in the standard library can create a management pack specific for their device.  The only difference between a device that included in the standard libraries and one that has a separate management pack is that the customer must install the management pack as opposed to having it automatically included with the System Center 2012 installation.  Once the management pack is installed, the device is discovered and monitored like any other.
      Custom management packs for network devices can be based on the same Network Monitoring management pack that is used by devices in the library.  This management pack includes detailed monitoring scenarios that can be leveraged in addition to modules that perform specific operations such as collecting information through SNMP probes and traps.  You can download a Sample Network Management Pack for System Center 2012 Operations Manager  that includes methods for discovering devices and implementing different kinds of monitoring.
      In order to accommodate the new network monitoring features in System Center 2012, significant changes were made to the network management pack libraries from Operations Manager 2007 R2.  Any of these management packs are backward compatible for existing devices, but new devices cannot be discovered and monitored.  If you have a management pack for a network device written for Operations Manager 2007 R2, it should be rewritten for System Center 2012 in order to accommodate new devices.  Details on the changes between the two versions and the management pack changes required are available at Migrating Operations Manager 2007 R2 Network Monitoring  .
      References

      6 System Center Integration

      6.1 Virtual Machine Manager

      In System Center 2012, Virtual Machine Manager integrates directly with Operations Manager in addition to using theSystem Center Monitoring Pack for System Center 2012 - Virtual Machine Manager  for monitoring of the health of all resources in a VMM environment. This additional integration is what allows VMM to display Operations Manager data in the VMM console and to control maintenance mode during VMM operations. You can also manage the installation of management packs through VMM rather than performing this installation directly in Operations Manager as you do with the other components. Guidance on configuring this integration is provided in Configuring Operations Manager Integration with VMM  .
      VMM performs some actions using the Operations Manager SDK that are typically performed with management packs for other products.  For example, several VMM objects are created without using object discoveries.  One example of this is the Virtual Machine object.  If you select this class in the Object Discoveries node in the Authoring workspace of the Operations Manager, no object discoveries are listed.  Instead of relying on a discovery in the management pack, VMM creates these objects through the Operations Manager SDK whenever a new virtual machine is created or modified.
      There is nothing that the vendor of resources that are used by VMM must do to have those resources discovered and monitored.  If the resource is recognized by VMM, then it will be discovered and monitored by the monitoring pack.  Vendors are still encouraged to create monitoring packs for their own resources though to provide any deep monitoring specific to their product.  While the VMM monitoring pack may be able to identify that the resource is offline, it would be unable to provide detailed analysis to the root cause of the problem at potential remedies.

      6.1.1 PRO-Enabled Monitoring Packs

      Physical Resource Optimization (PRO)  allows you to expose data collected by Operations Manager in the VMM console and to perform automated actions in response to particular conditions.  For example, PRO can load-balance virtual machines between physical hosts when specific thresholds are exceeded, or it can migrate virtual machines to a host on a different physical computer after a hardware failure.
      You implement PRO through the creation of a PRO-Enabled management pack.  Management pack libraries that include base classes and modules required for this functionality are provided with the System Center Monitoring Pack for System Center 2012 - Virtual Machine Manager  .  Any alert targeted at a class based on one of the PRO classes will be raised in the VMM console as a PRO tip.  The libraries also include modules that will run Windows PowerShell scripts that you provide that will run in response to specified conditions.
      You perform automated actions in a PRO-Enabled management pack by writing a Windows PowerShell script that includes the process to run and then including that script in a Recovery in the management pack.  The PRO management pack libraries include modules that can be used for this purpose.
      Guidance on creating a PRO-enabled management pack for System Center 2012 is available at System Center 2012 - Virtual Machine Manager: PRO-Enabled Management Packs  .
      References

      6.2 Service Manager

      Service Manager integrates with Operations Manager through two types of connectors that are both created and configured in the Service Manager console.
      The Configuration Items connector imports objects from Operations Manager as Configuration Items in Service Manager.  Discoveries in Operations Manager locate resources and their properties on managed computers, and the connector allows these objects to be automatically imported into Service Manager.
      The Alerts connector imports alerts as they are created from Operations Manager into Service Manager.  They are created in Service manager as incidents where they can be managed.  The incident then remains in synchronization with the alert allowing it to be closed when the incident is resolved.

      6.2.1 Management Pack

      The System Center Monitoring Pack for System Center 2012 - Service Manager  allows Operations Manager 2012 to monitor the health of a Service Manager environment.  It discovers Service Manager management servers and data warehouse and measures the health of its services.
      The Operations Manager agent cannot be installed on a Service Manager management server because Service Manager uses the System Center Management service to process its own management packs.  To monitor a Service Manager management server, you must configure it to use agentless monitoring  which allows Operations Manager to process its management packs on an Operations Manager management server.  Once the computer is added to the Operations Manager management group in this manner, it is monitored like any other computer.  The only exception is that it will not run any rules or monitors that do not support an agentless scenario.
      References

      6.3 Orchestrator

      6.3.1 Integration Pack

      The System Center Integration Pack for System Center 2012 Operations Manager  includes activities that allow you to create a runbook in System Center 2012 Orchestrator that interacts with Operations Manager.  You can perform many of the functions that you can perform with Windows PowerShell cmdlets only within the context of an Orchestrator runbook.
      The activities included in the Operations Manager Integration Pack address the following scenarios:
      • Retrieve and modify alerts.  This includes the ability to monitor for an alert to be created or changed, a feature which directly supports the connector scenario with other management systems.
      • Get the current health state of one or more monitored objects.
      • Start and stop maintenance mode.
      The Operations Manager Integration Pack allows you to create one or more connections to Operations Manager management servers that can be used by its activities.  Each connection holds the security configuration required to access a management group.  You can create a runbook with multiple activities that share a single configuration so that you don’t have to maintain separate credentials and connections for each activity.
      If you need to perform an Operations Manager action from a runbook that doesn’t have an activity, then you can write a script using one or more of the Operations Manager cmdlets  and then run this script from a Run .NET Script activity .  In this case, the Operations Manager cmdlets would need to be installed on the runbook server.  The script would also need to include a connection to the Operations Manager management group using the New-SCOMManagementGroupConnection  cmdlet.  If the account used for the Orchestrator Runbook Service does not have authority to the Operations Manager management group, then alternate credentials would need to be provided for this connection.  In this case, the name and password could be stored as encrypted variables in Orchestrator so that they would not have to be hardcoded into the script.
      The activities in the Operations Manager Integration Pack connect to Operations Manager using the Operations Manager SDK which means that they connect to the Data Access service on a management server.

      6.3.2 Management Pack

      In System Center 2012, the management pack for Orchestrator discovers and measures the health of Orchestrator components such as management servers and runbook servers.  It does not discover runbooks, nor does it monitor at the runbook level.  For example, the management pack will send an alert if the runbook service on a runbook server fails, but it will not alert if a runbook fails.
      The recommended strategy to raise an alert in Operations Manager if a runbook fails is to include one or more Create Alert  activities that raise an alert if a previous activity does not succeed.  You can also use a third party management pack that provides additional functionality such as the System Center Orchestrator MP from Infront Consulting Group  .
      References 

       Other Resources

      , , , , , ,, , , , 
      Posted by at No comments:

      Installing System Center 2012 using the Unified Installer


      The unified installer ships with System Center 2012.  What is the Unified Installer and what is the experience like when using it to install System Center 2012?  Lets find out by walking through my experience.
      First and foremost - READ THE DOCUMENTATION – all of it! If you adhere to what is listed in the documentation you will avoid many problems along the way. The Unified Installer User Guide is the starting point. Follow all of the links and thoroughly understand what you will be doing and make all required system changes up front! Documentation is available here.
      OK, with that taken care of, a few impressions right up front.
      Pros: 1.  The Unified Installer is targeted for lab/proof of concept installations only.  That is clearly stated in the popup that shows when you first launch setup.
      image
      Also clearly indicated is the fact that when using the Unified Installer detailed and advanced configuration for setting up the various products in the suite is suppressed.  This allows getting the suite components up and running more quickly but without understanding some of the configurations that should be considered and possibly implemented during install.
      2.  The Unified Installer leverages System Center Orchestrator runbooks to drive installation of suite components.  The Unified Installer is a great engine to show what is possible with runbooks.  And the runbook components of the Unified Installer are visible in the Orchestrator console and useful as a learning tool in and of themselves.
      3.  Working through the Unified Installer is a really good academic exercise.  You learn a TON about WinRM and Orchestrator and, after installs are complete, you are able to surf through the installed components to quickly gain a feel for the various components in each product, see the location of installed files, the SQL database and more.
      4.  Once you work through the process of using the Unified Installer, future attempts to set things up will be much more streamlined.
      Cons: 1.  Setting up the Unified Installer is TIME CONSUMING!!!  There is significant effort to assemble and extract all of the prerequisites.  This is time that would be spent even without the Unified Installer as the prerequisites are just that – prerequisites – but once you go to the effort to get ready for deployment you are a long way toward just installing individual suite components and gaining the significant extra learning opportunity and configuration flexibility that is associated with the full installation experience.
      2.  Using the Unified Installer streamlines the installation process but at the cost of more fully understanding the requirements of installation for the various suite components.
      3.  The Unified Installer installs suite products using a single server per product and gives no option to add additional servers or create more complex deployments.  While I understand that masking installation complexity is the nature of the Unified Installer, it does limit knowledge gained during the process.
      4.  There are multiple places in the installation wizard where you might encounter problems.  Most are due to incorrect configuration on systems due to not fully reading the very good documentation available.
      My Recommendation:
      The Unified Installer is great to learn since it is part of the System Center suite.  Having used the tool once I don’t plan to again for lab installs as I tend to need more custom setup than what the tool provides.  If you are new to System Center there is a lot of good learning that comes with wetting up the individual products manually.  For that reason, I strongly urge anyone setting up System Center to take the extra time to work through installing the products individually.  I also very much encourage working through the Unified Installer at least once.  Doing so will help gain some understanding of WinRM which is a very cool component for remote management and also will help you begin to understand System Center 2012 Orchestrator.
      The Walkthrough: The unified installer makes use of an installer system and target systems. 

      The installer system can be either Windows 7 SP1 or Windows 2008 R2 SP1.  System Center Orchestrator is the engine that drives the Unified Installer.  Thus, it is possible to configure the Unified Installer to be co-located with System Center Orchestrator on the Installer computer provided that the Installer computer is running Windows Server 2008 R2 SP1.  All other components must be on remote target systems.  You can also elect to install Orchestrator on a remote target system if so desired.  It is possible to use the Unified Installer to deploy only a single suite product or suite components in combination up to including every product in the suite.  In the example scenario, the Installer computer will be a Windows Server 2008 R2 SP1 host where Orchestrator will be co-located.  The Unified Installer will be used to deploy every component of the System Center suite to various systems.
      There are specific system requirements for using the Unified Installer.  As highlighted earlier, the documentation is your key to ensuring everything is configured as you need.  The Unified Installer makes heavy use of WinRM and, accordingly, settings will need to be applied through policy to the various systems participating in the installation.  These configurations differ depending on whether setting up the installer or target system.  Note that if co-locating Orchestrator on the same server as the Unified Installer, you will need to run through both sets of WinRM configurations on that one server.  More on the required configuration changes shortly.
      Before launching the setup wizard take some time to identify and download the System Center 2012 source files and prerequisites needed.  The Unified Installer will allow you to download prerequisites (not the source) as a part of the wizard but I found it easier to organize the needed items ahead of time.  Specifically, you need the following items:

      Source The source files you need will depend on which components you want to install.  At a minimum you will need System Center Orchestrator.  Other source files needed might include System Center Virtual Machine Manager, System Center App Controller, System Center Operations Manager, System Center Configuration Manager, System Center Service Manager and System Center Data Protection Manager.  Note that Unified Installer wizard requires expended source files.
      Prerequisites:
      There are a number of prerequisites that are needed by various components during installation.  Required prerequisites are as follows, .NET Framework 4.0 Extended, Microsoft Report Viewer Redistributable 2008, Microsoft Report Viewer Redistributable 2012, SQL Server 2008 R2, SQL Server 2008 R2 Native Client, Windows Automated Installation Kit, SQL Server 2008 R2 Analysis Management Objects, SQL Server 2008 R2 SP1 and SQL Server 2008 R2 Cumulative Update 4.  Here also the files will need to be expanded.  So, in the case of SQL Server 2008 R2 SP1 (as one example), the service pack comes as a single executable.  Extract the files by launching the executable and noting the location of the temp folder.  Copy the content of the temp folder to a location you have specified.  Once you have the files simply exist the installation wizard that launched as a result of starting the service pack install.  Another example is the WAIK which is downloadable as a .ISO image.  The contents of the .ISO must be extracted to a folder for use in the Unified Installer wizard.
      If the source files are in the form of an MSI or already expanded then no further action is needed.
      OK, so lets dive in.  The first thing to know is that the Unified Installer log is found under the \AppData\Local\Microsoft System Center 2012\Unified Installer\Logs.  Be sure to set your view options appropriately if you don’t see AppData.  The installation logging is really good good and will help keep you on track if something should go wrong during the installation.  Also cool is that once you complete the wizard and start installation, settings are retained so if you need to start over, consistency is maintained as to servers and settings selected!
      Before launching the wizard go ahead a work through setting the required group policy objects, either directly or through WinRM commands shown shortly, on all systems that will be touched during installation.  Required group policy settings will vary by the type of system and are shown below.  If setting policy by changing group policy objects it’s a good idea to manually force a policy update after configurations are complete by running gpupdate /force.  Also, changes can be made on individual systems with local policy changes or can be implemented in the domain and filtered to the desired systems.

      Installer Computer
      This is the system where the Unified Installer console is operating.
      In the Local Computer Policy console configure the settings as follows:
      image
      image
      image
      image
      The above settings are also configurable using WinRM commands as follows:
      winrm set winrm/config/client/auth @{CredSSP="True"}
      winrm set winrm/config/client @{TrustedHosts="*"}
      Target computer These are the systems where the Unified Installer is working to install suite components.
      In the Local Computer Policy console configure the settings as follows:
      image
      image
      image
      image
      The above settings are also configurable using WinRM commands as follows:

      winrm set winrm/config/service/auth @{CredSSP="True"}
      winrm set winrm/config/winrs @{AllowRemoteShellAccess="True"}
      winrm set winrm/config/winrs @{MaxMemoryPerShellMB="2048"}
      Whether or not you are using WinRM or policy settings set manually you will for sure want to run the following command on the target systems.  This enables them for remote management and ensures they are listening when remote management requests come in.
      winrm qc –q
      Before getting started with the installation be sure to validate firewall settings are configured as required.  Refer to the firewall configuration section of the documentation for details.  Also, during my install I found the installer would sometimes hang, seemingly without error.  I resolved this problem by increasing the maximmum concurrent policy instances on the Installer system which is running the Orchestrator management server.  Details on how to do that are found here.
      The environment
      The diagram below shows the lab environment I have used for working through the installation.
      image
      Running the Unified Installer wizard
      Tired yet?  ON TO THE INSTALL!!
      Note the splash screen provides links to the various documentation and also allows you to either install multiple suite products, up to the entire suite, by selecting Install System Center or a custom installation on the local server can be done by selecting Custom install on local server.  The later option only allows a single suite product to be installed.  For the example installation I chose the former option.
      image
      Fill out the registration information as well as supplying a product key or choosing an evaluation installation.  Also select that you agree with the license agreement.
      image
      Choose which suite products should be installed
      image
      Browse to the locations for the expanded source files discussed earlier.  A potential problem you will see here is when specifying the source path for System Center 2012 Data Protection Manager.  Be sure to point at the folder containing autorun.inf.  In my case the log errored indicating a version mismatch stating the FPP version was expected but not found.  Be sure that the version of source that you have in place matches what is expected by the Unified Installer.  The two types of source I’ve seen the Unified Installer ask for are either ‘evaluation’ or ‘select’ based on selections made on the Getting Started screen earlier.
      image
      On the next two pages of the wizard, accept the various license agreements
      image
      image
      On the prerequisite page of the wizard, point to the various prerequisite files downloaded earlier or, if you missed one, download it here.  Remember, the wizard requires the source files be expanded.
      image
      Next, pick the path that each product should use when installing
      image
      Finally, choose which servers should receive which products.  Note that the only product that may be co-located on the Installer system (assuming it is running Windows 2008 R2 SP1) is System Center 2012 Orchestrator.  Also note that no system is able to receive more than one suite component.  Input your selections.  Note that the wizard will verify connectivity to systems.  Also note that the wizard may appear to hang here.  It really isn’t, it is going out to each configured system to verify WinRM is able to access remotely.  Just take a look at the UISetupWizard.log located in \AppData\Local\Microsoft System Center 2012\Unified Installer to see the activity.  If there is a problem an error will popup but in my experience was often behind the Unified Installer wizard.  Just hover over the Unified Installer icon on the task bar to see if there are more than a single instance showing.  If there is likely one of them is an error popup.
      image
      After validation takes place the next screen allows configuring service accounts.  This is a lab or proof of concept (should NOT be a production deployment) so using a single account is convenient.
      image
      Set the options for System Center 2012 Operations Manager, Configuration Manager and Service Manager
      image
      Decide what to do with error reporting
      image
      Review the summary page
      image
      LET THE INSTALLATION BEGIN!!!!
      image
      At this stage, take a break – a LONG one – this will take a while.  The installation ran for multiple hours in my lab environment.  The progress bars keep moving right along and normally this indicate activity is taking place.  To confirm, you should also see the UISetupWizard.log updating.  If the log fails to update for 2 hours the Unified Installer will interpret that as a failure and stop so it’s a good idea to keep an eye on things.  It is normal to sometimes see 15-20 minute gaps in time between updates to the log as various activity runs on the various target systems being installed.
      image
      The Unified Installer may complete with all components in an error state, some components installed successfully while others failed (as shown below) or all successful.  If you encounter an installation failure for one or more components, review the UISetupWizard.log file.  This log tracks the progress of the installation for the various components and will often help identify a failing component.  The UISetupWizard.log resulting from the installation below is available here.
      image
      Another option is to evaluate any Orchestration failures by reviewing the messages in the Events table of the Orchestrator SQL database as shown.
      image
      After investigating the cause of the problem it is a simple matter to restart the installation to try again – just be sure to remove from the list any components that did successfully install in the first run.  If the results window is still open simply click previous and again click Install.  If not, simply start the Unified Installer again, all settings from the previous attempt are preserved.
      Relevant Files A bunch of log files and components are created on the various systems during install.  Many of them are suite component specific and I won’t go through each but there are a few locations worth of further discussion here.
      \AppData\Local\Microsoft System Center 2012\Unified Installer
      As already mentioned, this is the location (under the logs folder) where we find the UISetupWizard.log but there is more here as well.  In this folder you will find the source files that are used for the Unified Installer and to get the Orchestrator component up and running on the server.  Looking in the Unified Installer folder on the Installer machine you will see txt files that describe the work that needs to be done for the various components.  Below we see the Unified Installer folder on the Installer system where the Unified Installer is being run.
      image
      DeploymentPack.xml – This file contains the deployment configuration. While working through the UI certain servers were specified to receive specific suite components. This file details component to server mapping as well as containing instructions for installation.  A snip from this file focused on the System Center 2012 Operations Manager deployment is shown below.  All sensitive data is encrypted.
      image

      On target machines the Unified Installer folder may be empty.
      SelectedProduct.xml
      This file details installation information for all suite products that have been chosen for installation.  The file contains all details such as component source location, destination location, required prerequisites and their location and more.
      SQL_ files
      The various files that begin with SQL_ describe the SQL server configurations that will be implemented for the particular products.  These are text files and specify information such as service startup configuration and associated account information for the services. along with instructions needed to execute the installation silently, such as SQL features and automatic license acceptance.
      \AppData\Local\Microsoft System Center 2012\Orchestrator This location contains the log files associated with setting up System Center 2012 Orchestrator.  Log files on the Installer machine include ManagementServiceMSI.log, RunbookDesignerMSI.log, RunbookServerMSI.log, SetupWizard.log and WebComponentMSI.log.  The Target machines will have this folder as well but since they do not host the full version of Orchestrator they only will have the RunbookServerMSI.log and SetupWizard.log.
      c:\Temp
      This folder will be present on the Installer and all Target systems but the contents will vary.  This folder will be the location where source files or prerequisites for the specific suite component being installed will be staged before installation begins.
      c:\Temp\Unified Installer On the Installer computer you will see the Unified Installer folder along with xml files representing the various Target systems involved in the installation.  The xml files each contain an inventory of the various Targeted servers and show which features/roles are already installed or are not installed.
      image
      image
      c:\Temp\Unified Installer\UIInstall The Unified Installer folder will also contain a UIInstall folder with the binaries needed by the Unified Installer.
      c:\Temp\Unified Installer\UIInstall\Repository This folder contains three files of interest.
      PKConfig-.xml
      This file contains needed product key information based on inputs during the wizard.
      Prerequisites.xml
      This file describes the prerequisites that need to be in place for the Unified Installer to operate correctly.

      Progress.xml
      This file keeps track of progress as the Unified Installer is installed.  Progress results are communicated back to the Unified Installer and recorded in the UISetupWizard.log to keep track of various components as installation proceeds.
      c:\Temp\Unified Installer\UIInstall\Runbooks This folder contains the Unified Installer Runbook.ols_export.  This runbook is used by System Center 2012 Orchestrator to drive the installation of suite components.  This includes checking prerequisites, installing needed components (like SQL) and installing the System Center 2012 components themselves.  If you open System Center 2012 Orchestrator Runbook Designer after it’s installed you can navigate the runbook (it’s already there) to see how it works.  If you haven’t used System Center 2012 Orchestrator before this is a really cool way to gain some insight as to whats possible.
      image

      Final thoughts And there you have it, the Unified Installer has done it’s job and it’s now time to explore the environment and what has been done.  Don’t be shy, poke around a bit – this is a lab (or should be) so that’s the point.  Enjoy learning System Center 2012.  I know I’m a Microsoft employee – but it honestly is the best management solution going!
      Posted by at No comments:

      Friday, June 8, 2012

      Posted by at No comments:
      Posted by at No comments:
      Posted by at No comments:
      Posted by at No comments:
      Subscribe to: Posts (Atom)