Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

OpsMgr 2012 R2 – QuickStart Deployment Guide

OpsMgr 2012 R2 – QuickStart Deployment Guide

  • Comments 12
  • Likes

There is already a very good deployment guide posted on TechNet here:  http://technet.microsoft.com/en-us/library/hh457006.aspx  The TechNet deployment guide provides an excellent walkthrough of installing OpsMgr 2012 for the “all in one” scenario, where all roles are installed on a single server.  That is a very good method for doing simple functionality testing and lab exercises.

The following article will cover a basic install of System Center Operations Manager 2012.   The concept is to perform a limited deployment of OpsMgr, only utilizing as few servers as possible, but enough to demonstrate the roles and capabilities in OM2012.  For this reason, this document will cover a deployment on 3 servers. A dedicated SQL server, and two management servers will be deployed.  This will allow us to show the benefits of the RMS removal, and the highly available resource pools concepts.  This is to be used as a template only, for a customer to implement as their own pilot or POC, or customized deployment guide. It is intended to be general in nature and will require the customer to modify it to suit their specific data and processes.

This also happens to be a very typical scenario for small environments for a production deployment.  This is not an architecture guide or intended to be a design guide in any way. This is provided "AS IS" with no warranties, and confers no rights. Use is subject to the terms specified in the Terms of Use.

Definitions:

  • MS - Management Server
  • SRS - SQL reporting services

Server Names\Roles:

  • DB01               SQL Database Services, Reporting Services
  • SCOM01         Management Server, Web Console server
  • SCOM02         Management Server

Windows Server 2012 R2 will be installed as the base OS for all platforms.  All servers will be a member of the AD domain.

SQL 2012 with SP1  will be the base standard for all database and SQL reporting services. 

High Level Deployment Process:

1.  In AD, create the following accounts and groups, according to your naming convention:

  • DOMAIN\OMAA                 OM Server action account
  • DOMAIN\OMDAS               OM Config and Data Access service account   
  • DOMAIN\SQLSVC               SQL service account
  • DOMAIN\OMAdmins          OM Administrators security group

2.  Add the “OMAA” account and the “OMDAS” account to the “OMAdmins” global group.

3.  Add the domain user accounts for yourself and your team to the “OMAdmins” group.

4.  Install Windows Server 2012 R2 to all server role servers.

5.  Install Prerequisites and SQL 2012 with SP1.

6.  Install the Management Server and Database Components

7.  Install the Reporting components.

8.  Deploy Agents

9.  Import Management packs

10.  Set up security (roles and run-as accounts)

Prerequisites:

1.  Install Windows Server 2012 R2 to all Servers

2.  Join all servers to domain.

3.  Install the Report Viewer controls to any server that will receive a SCOM console.  Install them from http://www.microsoft.com/en-us/download/details.aspx?id=35747  There is a prereq for the Report View controls which is the “Microsoft System CLR Types for SQL Server 2012” available here:   http://go.microsoft.com/fwlink/?LinkID=239644

4.  Install all available Windows Updates.

5.  Add the “OMAdmins” domain global group to the Local Administrators group on each server.

6.  Install IIS on any management server that will also host a web console:

Open PowerShell (as an administrator) and run the following: 

Add-WindowsFeature NET-WCF-HTTP-Activation45,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net,Web-Windows-Auth –Restart

***Note – .NET 3.5 is removed from the OS by default, and therefore the content is not present in the OS to add this feature.  You must provide a “–source” parameter to installation media for Windows Server 2012 R2 in order to add this.  Such as “-source D:\sources\sxs”

7. Install SQL 2012 with SP1 to the DB server role

  • Setup is fairly straightforward. This document will not go into details and best practices for SQL configuration. Consult your DBA team to ensure your SQL deployment is configured for best practices according to your corporate standards.
  • Run setup, choose Installation > New Installation…
  • When prompted for feature selection, install ALL of the following:
    • Database Engine Services
    • Full-Text and Semantic Extractions for Search
    • Reporting Services - Native
  • Optionally – consider adding the following to ease administration:
    • Management Tools – Basic and Complete (for running queries and configuring SQL services)
  • On the Instance configuration, choose a default instance, or a named instance. Default instances are fine for testing and labs. Production clustered instances of SQL will generally be a named instance. For the purposes of the POC, choose default instance to keep things simple.
  • On the Server configuration screen, set SQL Server Agent to Automatic.  You can accept the defaults for the service accounts, but I recommend using a Domain account for the service account.  Input the DOMAIN\sqlsvc account and password for Agent, Engine, and Reporting.
  • On the Collation Tab – you can use the default which is SQL_Latin1_General_CP1_CI_AS or choose another supported collation.
  • On the Account provisioning tab – add your personal domain user account or a group you already have set up for SQL admins. Alternatively, you can use the OMAdmins global group here. This will grant more rights than is required to all OMAdmin accounts, but is fine for testing purposes of the POC.
  • On the Data Directories tab – set your drive letters correctly for your SQL databases, logs, TempDB, and backup.
  • On the Reporting Services Configuration – choose to Install and Configure. This will install and configure SRS to be active on this server, and use the default DBengine present to house the reporting server databases. This is the simplest configuration. If you install Reporting Services on a stand-alone (no DBEngine) server, you will need to configure this manually.
  • Setup will complete.
  • You will need to disable Windows Firewall on the SQL server, or make the necessary modifications to the firewall to allow all SQL traffic.  See http://msdn.microsoft.com/en-us/library/ms175043.aspx                 

    Step by step deployment guide:

    1.  Install the Management Server role on SCOM01. You can also refer to: http://technet.microsoft.com/en-us/library/hh301922.aspx

    • Log on using your personal domain user account that is a member of the OMAdmins group.
    • Run Setup.exe
    • Click Install
    • Select the following, and then click Next:
      • Management Server
      • Operations Console
      • Web Console
    • Accept or change the default install path and click Next.
    • You might see an error from the Prerequisites here. If so – read each error and try to resolve it.
    • On the Proceed with Setup screen – click Next.
    • On the specify an installation screen – choose to create the first management server in a new management group.  Give your management group a name. Don’t use any special or Unicode characters, just simple text. Click Next.
    • Accept the license.  Next.
    • On the Configure the Operational Database screen, enter in the name of your SQL database server name and instance. In my case this is “DB01”. Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.
    • On the Configure the Data Warehouse Database screen, enter in the name of your SQL database server name and instance. In my case this is “DB01”. Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.  
    • On the Web Console screen, choose the default web site, and leave SSL unchecked. If you have already set up SSL for your default website with a certificate, you can choose SSL.  Click Next.
    • On the Web Console authentication screen, choose Mixed authentication and click Next.
    • On the accounts screen, change the accounts to Domain Account for ALL services, and enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS, accounts we created previously. It is a best practice to use separate accounts for distinct roles in OpsMgr, although you can also just use the DOMAIN\OMDAS account for all SQL Database access roles to simplify your installation (Data Access, Reader, and Writer accounts). Click Next.
    • Choose Yes or No to send Customer Experience and Error reports.
    • On the Microsoft Update screen – choose to use updates or not.  Next.
    • Click Install.
    • Close when complete.
    • The Management Server will be very busy (CPU) for several minutes after the installation completes. Before continuing it is best to give the Management Server time to complete all post install processes, complete discoveries, configuration, etc. 10 minutes is typically sufficient.

    2.  Install the second Management Server on SCOM02. You can also refer to: http://technet.microsoft.com/en-us/library/hh284673.aspx

    • Log on using your domain user account that is a member of the OMAdmins group.
    • Run Setup.exe
    • Click Install
    • Select the following, and then click Next:
      • Management Server
      • Operations Console
    • Accept or change the default install path and click Next.
    • Resolve any issues with prerequisites, and click Next.
    • Choose “Add a management server to an existing management group” and click Next.
    • Accept the license terms and click Next.
    • Input the servername\instance hosting the Ops DB. Select the correct database from the drop down and click Next.
    • On the accounts screen, choose Domain Account for ALL services, and enter in the unique DOMAIN\OMAA, DOMAIN\OMDAS accounts we created previously.  Click Next.
    • Choose Yes or No to send Customer Experience and Error reports. Next.
    • Turn Microsoft Updates on or off for SCOM, Next.
    • Click Install.
    • Close when complete.

    3.  Install OM12 Reporting on the SQL server. You can also refer to: http://technet.microsoft.com/en-us/library/hh298611.aspx

    • Log on using your domain user account that is a member of the OMAdmins group, and has System Administrator (SA) rights over the SQL instances.
    • Run Setup.exe. Click Install.
    • Select the following, and then click Next:
      • Reporting Server
    • Accept or change the default install path and click Next.
    • Resolve any issues with prerequisites, and click Next.
    • Accept the license and click Next.
    • Type in the name of a management server, and click Next.
    • Choose the correct local SQL reporting instance and click Next.
    • Enter in the DOMAIN\OMDAS account when prompted. It is a best practice to use separate accounts for distinct roles in OpsMgr, although you can also just use the DOMAIN\OMDAS account for all SQL Database access roles to simplify your installation. Click Next.
    • Choose Yes or No to send ODR information to Microsoft. This is very important to assist Microsoft in getting good information to help improve the product.
    • Click Install.
    • Close when complete.

    4.  Deploy an agent to the SQL DB server.

    5.  Import management packs. Also refer to: http://technet.microsoft.com/en-us/library/hh212691.aspx

    • Using the console – you can import MP’s using the catalog, or directly importing from disk.  Note – some MP’s should only be imported from disk.
    • Import the Base OS and SQL MP’s at a minimum.

    6.  Create a dashboard view:

    7.  Manually grow your Database sizes and configure SQL

    • When we installed each database, we used the default of 1GB (1000MB). This is not a good setting for steady state as our databases will need to grow larger than that very soon.  We need to pre-grow these to allow for enough free space for maintenance operations, and to keep from having lots of auto-growth activities which impact performance during normal operations.
    • A good rule of thumb for most deployments of OpsMgr is to set the OpsDB to 30GB for the data file and 15GB for the transaction log file. This can be smaller for POC’s but generally you never want to have an OpsDB set less than 10GB/5GB.  Setting the transaction log to 50% of the DB size for the OpsDB is a good rule of thumb.
    • For the Warehouse – you will need to plan for the space you expect to need using the sizing tools available and pre-size this from time to time so that lots of autogrowths do not occur.   http://www.microsoft.com/en-us/download/details.aspx?id=29270

    8.  Continue with optional activities from the Quick Start guide on TechNet:

    9.  Enable Agent Proxy

    10.  Configure Notifications:

    11.  Deploy Unix and Linux Agents

    12.  Configure Network Monitoring

    13.  Connect with VMM 2012:

    14.  Configure your OpsMgr environment to accept manually installed agents.

    • The default is to block manually installed agents.  I recommend setting this to “Review new manual agent installations”

    15.  Configure your management group to support APM monitoring.

    16.  Deploy Audit Collection Services

    17.  Configure SQL MP RunAs Security:

    Comments
    • Hi Kevin,

      For a new customer (300+ servers) I must design a SCOM2012 environment.

      My SQL desgin will be  a SQL2012 database with OM and DW database, on the same SQL machine there will be a separate instance for the Report Database.

      For me the most "challenging" issue are the service accounts.

      I want to narrow it down as much as possible  so that I will have only 1 service account for all the SCOM operations.

      Instead of separate accounts for reporting, action accounts, sdk etcetera.

      Is this a good idea to have only one account or should I use the "old" way and create separate accounts for each service ?

      Regards,

      Marlon

    • Using a single service account is just fine.  Using multiple accounts is simply a best practice from the standpoint that each role needs different rights, and therefore should use a separate account from a security perspective.  However, there is no problem using a single service account for SCOM, for the MSAA, DAS, and reporting roles.  It isn't a "new" way or "old" way... it is simply broken apart for security best practices because many management groups and responsibilities can be widely distributed.  But especially for smaller environments, using a single account is fine and will not create any support issues.  You simply are granting more rights to a single account, which isn't necessary, but might simplify things for you or your customer.

    • While installing ReportServer, do we have to use Data reader account or DAS account. Kindly confirm.

      Regards,

      Sundar

    • Tx, Kevin

      I will discuss it with my manager and the customer,

      Regards,

      Marlon

    • You might want to add a stepp about configuring the SPN for the SDK service to the domain user account since that does not happen automatically. Even worse, it tries to register that SPN to the computer account which is a bug:

      https://blogs.technet.com/b/kevinholman/archive/2011/08/08/opsmgr-2012-what-should-the-spn-s-look-like.aspx

    • Can managed service accounts be used without issue? Also, do the OMAA & OMDAS account on each management server need to be the same account. Due to our security policy they would like to have an account tied to a specific server, so ideally we would have OMAA01 & OMDAS01 for mgmt server 1 and OMAA02 & OMDAS02 for mgmt server2, etc....

    • @Jon -

      Great question. However, as these are new features in Windows 2008R2 and later (and require domain/forest levels to support those), there is no support for MSA's or GMSA's in SCOM 2012. I'd imagine we will see support for GMSA's in the future as they grow in popularity.

      As to having distinct accounts per server.... the SDK account is used across multiple servers, it is not only assocuiated with a specific server, but it is used to access web console connections to an SDK, for the SDK to access SQL, for connector servers/Orchestrator to access the SDK, etc. Tying a service account down to a singular server seems a bit archaic, but I do understand different companies have unique security requirements. I do know that you can use different accounts for each management server's OMAA, I imagine you can also use different OMDAS accounts as well, this would just get a bit uglier with security access to the database, etc. You might be plotting some new ground, as most of my customers want to simplify and use fewer service accounts to have to deal with.

    • Great, thanks for the information. I would agree with your sentiment about multiple accounts...only wish I made the policies :).

      Thanks,

      Jon

    • Hi Kevin,

      I want to try to find out why I don’t have issues in Discovering Windows Computer when I use my user account instead of SCOM action account (DOMAIN\OMAA), since both are local administrator of the target server.
      Discovery only fails with DOMAIN\OMAA. With my user runs ok.

      Regards

    • Ok, I’ve found out where was the problem.

      DOMAIN\OMAA need to be Local Administrator of the SCOM Management Server. Add it to the Administrators Group and had the problem solved.
      I just don't know why SCOM didn't add it to the Administrators group when it was installed.

    • Is it possible to change the data reader and data writer account after the setup to use separate accounts when I installed scom to use the DAS account for data reader and data writer as well?

    Your comment has been posted.   Close
    Thank you, your comment requires moderation so it may take a while to appear.   Close
    Leave a Comment
    Search Blogs