OpsMgr 2012 R2 – QuickStart Deployment Guide


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 (53)

    1. Kevin Holman says:

      @Matthev –

      There is NO reason to run setup as the OM Server action account. This is actually a worst practice – because the user installing SCOM needs WAY more rights and privileges than the OMAA, which is a service account and should follow the path of least privileges
      needed. I discourage that practice. Service accounts should be granted ONLY the rights they require to effectively execute the services and processes they run. The best practice is to run setup as your user account, that has been granted rights to all the
      machines and SQL. Then – if needed, your rights can be revoked, and the service accounts are unaffected.

      How SQL is installed is up to the organization. Generally speaking, whomever installs SQL server is completely irrelevant. Once it is installed, the security access list can be configured within SQL. Some organizations use the built in local accounts to run
      SQL servers, and some use Domain accounts for SQL services. Some organizations run all SQL servers under a shared domain account, and some create a unique domain account for each and every SQL server. The only bad practice would be using a single domain account,
      because if that account is ever locked out, you risk shutting down a LOT of SQL servers.

    2. Kevin Holman says:

      @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.

    3. Kevin Holman says:

      @Najam –

      You can remove SCOM 2007 R2 whenever you are ready to cut over to SCOM 2012R2 as production. Then once this step is complete, you can uninstall SCOM 2007 or just shut down/retire those servers, whatever is your normal process for server lifecycle. On the agents,
      you need to use the agent scripting objects to remove the additional management group:

      http://blogs.technet.com/b/kevinholman/archive/2014/01/29/using-the-agent-scripting-objects-on-a-scom-2012-agent.aspx

    4. Kevin Holman says:

      @Manaf – yes. Use gateways with certificates. This is covered in the product documentation on TechNet.

    5. Kevin Holman says:

      You should look at the OpsMgr Sizing helper for 2012. For a management group with 500 agents, and 100 network devices, you can place both the SCOM OpsDB and Warehouse in the same SQL instance. For SCCM – it will depend on the number of clients. Is SCCM
      being deployed only for targeting these servers, or will it be targeting the desktop environment? If for servers only, I’d split the DW and OpsDB in different instances and share the SCCM DB with the DW as you originally planned. If SCCM will be used for desktops
      as well, and good performance is needed, I might consider dedicating a SQL instance for SCCM DB, and combining OpsDB and DW together per the sizing guide.

    6. Kevin Holman says:

      @Jared. Yes – you put the agent on both nodes of the cluster. We don’t alert on failovers. We assume that is a healthy part of clustering. We alert when a resource group is not online.

    7. Kevin Holman says:

      @John –
      Yes – to move your "tweaks" over, simply export and then import all your self-created custom unsealed management packs from one management group into the other. The only problem with this, is often you bring over a lot of "garbage" where you had tweaks saved
      to the wrong places, or you have a bunch of overrides set in the past that are undocumented and nobody understands why, etc. So most customers tend to choose to recreate their core overrides in the new environment and look at this as an opportunity to "do
      it right" and document all the changes you make to the environment, and leave the old stuff behind. If you just want to forklift whatever you have in SCOM 2007 and move it all over, then by all means you just move the unsealed MP’s over and you are done.

    8. Kevin Holman says:

      @Yesh –

      You didn’t tell me the most important things, like what scale you are monitoring at? How many windows agents, Linux, URL, network device, 3rd party MP’s in scope, etc. These are all part of gathering requirements and mapping them to a design. You also didn’t
      tell me how many nodes are in the SQL cluster. Assuming this is a 2-node cluster, that falls into our "supported but not recommended" configurations. Only not recommended because both instances could fail over to a single node, and this could create a memory
      and CPU pressure condition depending on how much you scale. If this is a smaller environment, say less than 1000 windows agents and no Linux/Network, AND the cluster nodes have a good amount of memory, then it will likely be fine. From a compatibility perspective,
      there is no issue with combining an SCCM database and a SCOM database in a single instance. However, each will need their own respective SSRS server deployed separately for their respective reporting components.

    9. Marlon says:

      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

    10. Kevin Holman says:

      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.

    11. sundar says:

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

      Regards,

      Sundar

    12. Marlon says:

      Tx, Kevin

      I will discuss it with my manager and the customer,

      Regards,

      Marlon

    13. Chris says:

      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

    14. Jon says:

      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….

    15. Jon says:

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

      Thanks,

      Jon

    16. Anonymous says:

      Pingback from SCOM QUICK Install | config.re

    17. Vitor Montalvao says:

      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 (DOMAINOMAA), since both are local administrator of the target server.
      Discovery only fails with DOMAINOMAA. With my user runs ok.

      Regards

    18. Vitor Montalvao says:

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

      DOMAINOMAA 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.

    19. Garry Trinder says:

      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?

    20. Dale says:

      So I have gotten to the point in your excellent guide where I am attempting to install the OM12 Reporting on the SQL server. I had the issue with the SPNs not being applied to the correct accounts but I fixed that. When I get to the Configure Operations
      Manager Accounts part where it is asking for credentials for the Data Reader account I give it the account I created (which is a member of local admins on the SQL box and SCOM management server, and is a separate account from OMDAS) and I get a pop up saying
      Setup could not connect to the SDK to retrieve the necessary information to validate this account. When I click on the little red x I get The user account *******omdr cannot be verified. Please verify the username and password to continue. Which I have done.
      I assume it has something to do with permissions in reporting services but I am at a loss. I have been stuck here for a day and I am supposed to demo a working deployment of this to our R&D department this friday, lol. As you can imagine I am somewhat panicked.
      Any help you could offer would be fantastic.

    21. Steven says:

      do we able to create 2 management server which shared the same clustered SQL DB ?

    22. jimmy says:

      You can add in as many management servers as you want. During setup, you add to an existing management group.

    23. Steven says:

      Hi Jimmy, mean if 1 of them are down and monitoring will still online and working normally which work like redundancy?

    24. Matthev says:

      Kevin, I have a question.
      Some people told me that the best practice to install MSSQL and OM is to run setup for:
      – Operation Manager using Run As different user account and use OM Server action account

      – MS SQL using Run As different user option and use SQLDB account (for Database Engine Service)

      Why? Could you please explain what is the clue?

    25. MJ Almassud says:

      Thank You Very Much.

      MJ

    26. ibulut says:

      by consulting the event log SQLPRD, I found several connection attempt fails with the admin of scom, there is there a problem with connectivity between Scom 2012 R2 SP1 & SQL. I think it is a right of access problem for the "admin Scom" or Harbor problem
      with sql.
      knowing that I use one account SCOM Service

    27. Najam says:

      Hi Kevin,

      I want to configure my existing SQL 2008 R2 cluster for SCOM 2012 R2 installation. Do you have any suggestions or guide mention somewhere?

    28. Yesh says:

      Hi Kevin,
      I need your advice on this ……

      Have been provided a Single SQL Cluster which would be common for SCOM & SCCM.
      we are planning to have
      – on 1 instance SCOM DB
      – on another SCOM DW and SCCM DB….

      Could this be achieved? pros and cons if any?

      Thank you very much…

    29. Yesh says:

      Sorry Kevin for not mentioning those…
      Less than 300 agents and less than 100 nw devices….could grow as well….
      Yes, its a 2-node SQL cluster with 16GB ram for each node…
      Not to forget its being implmented in a virtual environlent….

      Yes i am aware about SCOM not sharing SSRS with other SC components……
      Respective SSRS server means requesting 2 more servers for Reporting or single Reporting Server with 2 instances? Will this work?

      Thanks once again Kevin for the help 🙂

    30. Manaf says:

      Hi Kevin,

      I wanted to know if it is possible to Monitor 2 non trusted forest with a single scom 2012 R2 setup?

      If yes, how to achieve this?

      Thank You.

    31. JaredCEG says:

      I setup my SQL DB in a cluster everything is working great. In the document it says to Deploy an agent to the SQL DB server. In my case should I deploy to each server in the cluster? how will it handle alerts for the clustered servers example: you fail-over
      the cluster will that generate an event on the services stopping on the SQL server handing off the roles?

    32. John Lomonaco says:

      Hey Kevin. Love your SCOM and SCCM Blogs. Incredibly helpful. Question. We want to set up a new SCCM 2012 Ops Manager server to replace our old SCOM 2007 Ops manager. We’re not going to upgrade as the HW is old so we’ll just keep the old box around for
      historical purposes. But my question is, is there any way to export the configuration from SCOM 2007 and import into 2012? For example, all the tweaks of done in terms of Overrides and such?

      Thanks much!

    33. Najam says:

      Hi Kevin,

      Thanks for your contributions. Just lovin it 🙂

      I have upgraded the our SCOM 2007 R2 to SCOM 2012 R2 side by side. Now, how can I remove SCOM 2007 R2 from my environment completely?

      Note: All my agents are pointing to both SCOM 2007 and 2012.

    34. Raghul says:

      In our infra we have 2 SCOM mgmt servers, 2 SQL servers (clustered) and 1 server for reporting. Is it possible to install reporting role in any one of the SQL servers ?

    35. Kevin Holman says:

      @Raghul –

      You would never install reporting on any clustered node. I am not sure what the question is…. if you have allocated 1 server for reporting, you would install reporting on that server.

    36. Raghul says:

      Ya correct. Even though we have a dedicated server for reporting, installation of SSRS on that would require additional license, whereas if we install on the same SQL machine it would not require additional license. Hence the query.

    37. Kevin Holman says:

      There is no additional licensing required as long as you use System Center Standard edition. System Center licensing includes access to use SQL server standard edition as part of system center, as long as the SQL installation is dedicated to System Center
      products. It does not matter if you deploy 1 SQL or 10 SQL servers to support System Center deployment.

    38. Nirmal says:

      Hi Kevin, Thank you for a Great Post. One small issue I am facing is my Reporting Pane is blank when I access the SCOM console – remotely as well as from the Mgmt Servers. Went through numerous web searches but not able to find a solution. Will you be
      able to help. Thanks.

    39. Kevin Holman says:

      @Nirmal – blank reporting is normal for up to one hour. After that – if reports don’t deploy, it usually means you missed a step in applying correct permissions as called by the document, or you have some odd security policy in your environment which is
      blocking some account access. You should review all the events on all management servers Operations Manager logs for failure clues.

    40. Nirmal says:

      Thanks Kevin for quick response. I have looked the OM logs. There is one service failure that I get which is then resolved right away automatically in about couple of minutes time…The error is "Report deployment process failed to request management pack
      list from SQL RS Server. The operation will be retried." The resolved event shows "Report deployment process successfully requested management pack list from SQL RS Server " Both events are logged under Data Warehouse category. Is there any specific security
      policy for particular account that I need to look into? Thanks.

    41. Suwanto says:

      Hi Kevin, I have issue with my newly SCOM 2012 R2 where my reporting on availability is only showing few clients from total clients that it monitor. Please advise what could be the rootcause here. Thanks.

    42. Najam says:

      Hi Kevin:

      Thank you for this and all of your information. Do you have any specific step by step guide to deploy ACS (SCOM 2012 R2)? If not, could you please refer to any?

    43. dondon says:

      Thanks Kevin,
      I have lot of agents showing as critical and greyed out as well as some showing as not monitored. Checking event log I can see ;lots of login failures.

      Login failed for user DOMAINSERVER$’. Reason: Could not find a login matching the name provided.

    44. Hi Kevin,

      Can you please help me out?! I get to the same point Dale does, “setup could not connect to the sdk to retrieve the necessary information to validate this account”. I have double checked the DAS access to the Database Engine, and all looks fine. Please help?

    45. Hi Kevin, i am experiencing this error: setup could not connect to the sdk to retrieve the necessary information to validate this account. Please advise as to what the issue could be? Account is part of the local admin and domain admin group, is a sysadmin when referring to the Database Engine. But still i cannot install reporting on my SQL instance

      1. Kevin Holman says:

        My first thought would be firewall, or something odd like disabled remove registry service.

        1. Hi Kevin,

          Remote registry is active on both servers, and firewalls are completely switched off. I can telnet to the SQL Server through port 1433 and i can telnet to the management server through port 5723. When doing the reporting server install on the SQL server, the error comes just after the pointing to the SQL Server instance, where you have to specify a service account with the appropriate rights.

          problem is the appropriate rights have already been assigned to the account im using, from Sysadmin rights in SQL, to local admin rights on both MS and SQL Server, to even domain admin rights. it just doesnt want to validate the account for some reason.

          1. Kapil D says:

            I am having the same issue in a new SCOM 2012 R2 setup I am working on. The reporting service component on my SQL DWH running on SQL 2014 Enterprise edition is presenting the following error:

            ‘The user account domain\ cannot be verified. Please verify the domain, username, and password to continue.

            Any suggestions will be a big help.

            Thanks.

            1. Kapil D says:

              Piece of advice. If its a brand new setup, you are better off starting fresh. My first MS did generate some errors during setup but it still did install. But no matter what I did, could not configure Data Reader account to work with Report Server setup like I mentioned above.
              SECOND TIME AROUND IT WORKED!!!!
              Kapil Dham

    46. Jake says:

      Great article Kevin! Thank you!

      I wanted to ask if the provided scenario could possibly fit on a born in the cloud deployment.
      My company’s operational environment is hosted on 3 Azure datacenters (West Europe, East US, West Us).
      We are about to implement SCOM 2012 R2 and in order to succeed high availability we are thinking to spread the roles as provided below.
      1xDatabase Server (EastUS Azure)
      2xManagement Servers (1 in West Europe and 1 in West US)
      Latency between the Azure data centers: West Europe – East US is 83ms and West US – East US is 67ms.
      Monitoring: 500 servers + 500 network devices.

      Thank you in advance.

      1. Kevin Holman says:

        We do NOT support separating management servers across high latency connections. Management servers MUST be within 5ms of each other, and the database.

        Therefore – I’d place ALL your infrastructure in a single location where you have the most assets (agents, network devices) and then any additional assets would simply connect “across the pond”. It is FAR better to have agent traffic go across a high latency connection than MS to MS or MS to SQL.

        From: https://technet.microsoft.com/en-us/system-center-docs/om/plan/planning-a-management-group-design

        “Therefore, all management servers should be on the same local area network as the Operational database and the Data Warehouse database.”

        I sent a note to the documentation owner to try and make this a little more clear. It is a common design mistake.

        1. Jake says:

          Thank you for your feedback Kevin. I really appreciate it!

    Skip to main content