Book Review: SAMS System Center 2012 Operations Manager

System Center 2012 Operations Manager Unleashed CoverHello Everyone,

Something that you may not know about me, but I am an avid reader. Late last year I was able to complete my reading of the SAMS System Center 2012 Operations Manager Unleashed (2nd Edition) book. That’s right, I read the entire book cover-to-cover.

If you are like me, when reading a 1536 page book, you’re bound to come across either some interesting points, tips, etc. However, unless you make some sort of note about it, you’re more than likely to forget about it by the time you get to the end. Therefore, I have gotten into the habit of purchasing the eBook (along with a physical printed copy) and making highlights as I go. I then sync  these highlights to my Evernote account, so that I can easily access, and search them in the future.

Well, I’ve decided to share my highlights from reading this specific publication, in case the points that I found of note/interest will be of some benefit to someone else. So, here are my highlights (by chapter). Note that not every chapter will have highlights (depending on the content and the main focus of my work).

 

Chapter 01: Operations Management Basics

  • NONE

Chapter 02: What’s New In System Center 2012 Operations Manager

  • Should you need to move the RMS emulator role, Microsoft provides the Get-SCOMRMSEmulator, Set-SCOMRMSEmulator, and Remove-SCOMRMSEmulator PowerShell cmdlets to identify, move, and delete the RMSE
  • Windows agents do not use resource pools for failover
  • As APM is configured using templates, it does not require authoring management packs or code modifications
  • SP 1 adds support for WFC, ASP.NET MVC, .NET Windows Services, Azure SDK, and IIS 8.
  • One change is the Actions pane is renamed to the Tasks pane
  • The OpsMgr 2012 Web console is completely redesigned and based on Silverlight
  • Having a resource pool requires at least two management servers
  • Previous versions of Operations Manager used connectors to connect to other systems. In System Center 2012 Operations Manager, this functionality is replaced by Orchestrator integration packs.
  • Agentless exception monitoring provides data on application crashes
  • ACS is a secure and efficient way to gather Security event logs from systems and consolidate them for analysis and reporting
  • The ACS agent is included in the OpsMgr agent deployment
  • Components in OpsMgr 2007 are now called product features
  • The OpsMgr agent is now a feature, rather than a component
  • A gateway server enables monitoring of computers that lie outside the Kerberos trust boundaries (Kerberos realm) of the management group
  • Gateway servers use certificates to communicate with those agents that cannot otherwise communicate with a management server
  • The data transmitted between the agent and a management server (or gateway server) is both encrypted and compressed.
  • Compression ratio ranging from approximately 4:1 to 6:1
  • Management packs use XML
  • Management packs are the brains of Operations Manager; they provide the logic and reports used for monitoring
  • A Run As profile is a profile that associates a credential with a workflow so it can run using those credentials
  • When a workflow requires credentials that cannot be provided by the default action account, it can be written to use a Run As profile

Chapter 03: Looking Inside OpsMgr

  • The operational and data warehouse databases should run on clustered SQL Server instances for high availability of the OpsMgr management group
  • Failover of the RMSE role to any surviving additional management server is performed simply but manually in OpsMgr 2012 using a PowerShell cmdlet.
  • Microsoft recommends a minimum of two management servers be deployed in all management groups monitoring mission-critical highly available infrastructures
  • In the case of Windows computers, the agent can be staged in computer images, and the agent can discover its configuration from Active Directory.
  • The process of multi-homing an agent occurs automatically by discovering the computer and pushing agents from two management groups—the first discovery installs the agent; the second discovery multi-homes the agent
  • You can install the reporting server feature on the same SQL Server hosting the data warehouse database in a small environment
  • In large and high-availability environments, SSRS typically runs on a dedicated server
  • The OpsMgr reporting server itself cannot be made highly available
  • All management servers are members of the All Management Servers Resource Pool unless they are expressly removed using a PowerShell cmdlet
  • Microsoft recommends all management servers have no more than 5ms latency between them
  • Place all management servers in the same datacenter
  • In heavy use and high-availability scenarios, you can load balance one or more dedicated Web console servers.
  • The gateway server resides in an external environment and uses certificates (rather than AD-based Kerberos) to secure communication back to the other features in the management group
  • Gateway servers compress agent to management server traffic by as much as 50%
  • Microsoft requires the version of SQL Server for the audit database match the SQL Server version of the operational database
  • You can cluster the SQL instance hosting the ACS database for high availability,
  • You will generally have only one ACS collector per management group.
  • The Agentless Exception Monitoring (AEM) client feature is activated by a group policy object (GPO) applied to computers
  • AEM centralizes the crash and bug information collected by Dr. Watson and Windows Error Reporting (WER) in your organization
  • You will want to create a network device monitoring pool with specific management servers or gateway servers as members
  • You should only include those management servers or gateway servers in network device monitoring pools that are not already heavily loaded with agent management traffic
  • APM is activated by importing the APM Web IIS 7 (or IIS 8 if running Windows Server 2008 with System Center SP 1) management pack and running the Add Monitoring Wizard in the Authoring space.
  • The health service usually runs under the local system account on all computers.
  • The OpsMgr agent to management or gateway server connection is encrypted by a public-private key pair created on each instance of the health service (agent, management server, and gateway server), after being authenticated by Kerberos or certificate
  • The public key is automatically regenerated during health service startup, when the key expires, and when there is a failure to decrypt a message.
  • TCP port 5723 in OpsMgr is associated with the health service
  • Consoles, web consoles, and report servers connect to the System Center Data Access Service.
  • The DAS typically runs under a domain service account on management servers.
  • The configuration service is responsible for providing the monitoring configuration to each agent’s health service
  • The service acts as an intermediary for delivering sensitive information in an encrypted format from the OpsMgr database to the target health service on a managed computer
  • The configuration service almost always runs under a domain service account on management servers
  • The audit forwarding service is automatically installed (but not configured) on every OpsMgr management server, gateway server, and agent.
  • The database is created during setup of the ACS service on the selected management server.
  • The APM service is automatically installed (but not configured) on every OpsMgr management server, gateway server, and agent.
  • Communication between management servers and the three OpsMgr databases (operational, data warehouse, and audit) is always via standard SQL client/server protocols, specifically OLE DB (Object Linking and Embedding Database)
  • Between agents, as well as management and gateway servers, the primary Transmission Control Protocol (TCP) port is 5723, which is the only outbound firewall exception needed to manage a computer in a minimal configuration once the agent is installed
  • An exception is the Web console when using the optional APM feature—this scenario requires the Web console to access the operational and data warehouse databases directly.
  • Additional outbound ports are used when enabling ACS and AEM features.
  • The primary OpsMgr agent-management server connection, TCP port 5723, is protected with a unique digital key and is essentially a secure sockets layer (SSL) connection, an encrypted tunnel
  • Stopping the health service (the System Center Management Service) and deleting the Health Service State folder is a safe and standard procedure to troubleshoot many OpsMgr server and agent issues
  • View what workflows are loaded on a management server is to run the Workflow Analyzer tool from the OpsMgr resource kit
  • All scripts have a default timeout value as a safety feature to avoid allowing idle or dormant monitoring threads to stack up and overload the system
  • The console is generally installed on every OpsMgr management server
  • Only unhealthy monitors appear when you first open an object’s health model
  • There are also two new web portals associated with the APM feature

Chapter 04: Planning An Operations Manager Deployment

  • Start by creating a single high-level design and planning document
  • Developing a comprehensive plan and receiving backing from the appropriate sponsors within your organization.
  • Proper technical deployments require a disciplined approach to implement the solution
  • Understand from a monitoring perspective the current environment and history, how the organization reached where they are today
  • An organization’s history of monitoring will show where previous pitfalls existed so they can be avoided in the future.
  • Important to be aware of any services on which OpsMgr may have dependencies. These include but are not limited to local area network (LAN)/wide area network (WAN) connections and speeds, routers, switches, firewalls, Domain Name Server (DNS), Active Directory (AD), instant messaging, and Exchange
  • Determining which servers Operations Manager will be monitoring (including domain/[s] workgroup they are in), applications on these servers that need to be monitored, and how long to retain alert, event, and performance information.
  • Important that you identify what is and is not in scope for the project
  • First phase deployment for OpsMgr 2007 often did not include monitoring for non-Windows operating systems or devices, Audit Collection Services (ACS), or Agentless Exception Monitoring (AEM)
  • A typical first phase deployment of System Center 2012 Operations Manager will include design of the OpsMgr environment, deployment of OpsMgr, and tuning OpsMgr
  • In most cases, a single management group is the simplest configuration to implement, support, and maintain
  • Using a separate management group may be required should your auditors or company mandate state that the ACS functionality be administered by a separate group of individuals.
  • Management groups cannot have a leading or trailing space in their name.
  • The management group name is case sensitive.
  • Do not choose an existing management group name used for Operations Manager or Service Manager
  • An average client will use 3Kbps of network traffic between itself and the management server
  • Operations Manager can support approximately 30 agent-managed computers on a 128KB network connection (agent-managed systems use less bandwidth than agentless-managed systems
  • Install management servers in the same physical location as the database servers and on the same subnet if possible. OpsMgr requires high bandwidth and low latency between the management server and the database server.
  • Minimum network connectivity Data sent from the management servers to the databases is not compressed.
    • The amount of data sent by the agent depends on the management packs installed on each agent, the type of activity generated, how those management packs are tuned, and conditions in your environment. The good news is that data between agents and the management server/gateway server is compressed. Satya’s tests determined about 200Kbps is sent for 200 agents in an environment with the AD, Windows Base OS, DNS, and OpsMgr management packs.
  • Audit Collection Systems (forwarder to collector): Security events are sent in near real time rather than being batched together
  • Security events sent from the agent to the collector are typically less than 100 bytes, and the event in the database is under .05 KB
  • It is best to keep things simple by keeping the number of Operations Manager servers as low as possible while still meeting your business requirements.
  • Infrastructure is nearly always hosted in a single site. OpsMgr without the ACS feature consists of two databases, a number of management servers and gateways, plus an optional dedicated web console and reporting server.
  • For a distributed OpsMgr implementation, consider the location of the majority of the systems you will be managing. This generally is where you deploy the bulk of your OpsMgr environment, and should be the first thing to consider during planning
  • Management servers provide the communication path between OpsMgr agents and gateway servers and the Operations database and OpsMgr data warehouse.
  • Plan for a minimum of two management servers per management group. Each management server can handle up to 3,000 agent-managed computers. OpsMgr 2012 has a limit of 10 agentless monitored systems per management server
  • If a management group will monitor more than 3,000 computers, install multiple management servers in the management group
  • Add management servers to provide monitoring for up to 500 UNIX and Linux servers monitored by OpsMgr and to provide redundancy for these functions.
  • Add management servers to provide monitoring for network devices
  • Although each management server does not store any major amounts of data, it does rely on the processor, memory, and network throughput of the system to perform effectively
  • Management servers should be separate from the Operations database
  • If the MS and operational database are on the same server, the authors recommend monitoring no more than 200 agents with that server because it can degrade the performance of your OpsMgr solution
  • There are high processing requirements on both the operational database and data warehouse, and they perform better with their own server
  • 1,000+ agents: 4 Disk RAID 10, 16GB of memory, 8 Cores. This will vary based on your specific environment (number of agents, network devices, monitored URLs, UNIX/Linux systems, and so on
  • Use a highly available virtualization solution that migrates the management server(s) upon loss of a host system.
  • Resource pool functionality does not replace AD integration—OpsMgr Windows agents are NOT assigned to report to a pool, but to a specific management server.
  • A gateway server gathers communications from agents and forwards them to a management server on the other side of the firewall using port 5723
  • The specified management server handle only gateway server communication; because of load issues, it is best that agents do not report directly to the same management server as a gateway server
  • While the management server sends the command to deploy the agents to the gateway server, the gateway server does the actual agent deployment.
  • A latency of less than 100ms is desired
  • Data sent from the gateway server is consolidated, resulting in an estimated 20%-30% reduction of total data sent to the database
  • Note that this reduction in data that is sent applies when there are approximately 50 or more agents reporting to the gateway. With smaller numbers of agents, there will be very little benefit in terms of bandwidth savings from implementing a gateway server
  • Microsoft recommend assigning a dedicated management server with no traditional agents reporting to it (even in a failover scenario), for the sole purpose of collecting data from your gateway server(s).
  • This means you typically will want to host no more than three or four gateways per management server during normal operation, and control failover such that no more than six report to a single management server at any time
  • As a rule of thumb, trim the SQL Server instance to use only what memory is available on the server, leaving 1GB per CPU socket for operating system (OS) operations. This approach provides SQL with as much memory as possible without starving the OS.
  • You must use either the Standard or Enterprise editions with OpsMgr
  • Enterprise Edition is strongly recommended in high-volume ACS environments as it reduces the chance of lost security events
  • The best practice for database servers in OpsMgr is to place the two databases on different servers to avoid resource contention.
  • SQL collation: SQL_Latin1_General_CP1_CI_AS.Install the operational database and data warehouse on different systems. OpsMgr writes data in almost real time to these databases, making their loads similar
    • SQL Server Full Text Search: Required.
    • .NET Framework: .NET Framework 3.5 SP 1 and .NET Framework 4
  • Configure the database server with one disk for OS, one disk for SQL, one disk for tempdb, and one disk for transaction logs.
  • Resize tempdb and the transaction log to be 20% of the total size of the operational database and data warehouse
  • SSRS is often installed on the OpsMgr data warehouse server but can be installed on a separate web server
  • The hardware requirements for ACS database servers vary depending upon the number of events per second that are being inserted into the database.
  • Microsoft does not support using a different version of SQL Server for different Operations Manager features, so use the same SQL version for ACS as the other OpsMgr database components
  • The ACS collector feature is installed on an existing management server, so the hardware requirements for the collector mirror those of the management server.
  • After the service is enabled, the ACS collector feature captures all security events (which are also saved to the local Windows security event log).
  • System Center 2012 Operations Manager includes functionality that captures, aggregates, and reports on application crashes (Dr. Watson errors).
  • From a planning perspective, if there is a requirement for AEM, there must be a plan for a server that stores the crash information, and you must deploy a group policy to redirect the application crash information to the AEM server
  • From a planning viewpoint, the server you will use must be identified and have sufficient space to store crash information. (Crash information can range from very small up to 8GB.)
  • By collecting this information, identifying patterns, and working to resolve them, an organization can take a large step forward to becoming more proactive in situations affecting its end users, which will affect productivity
  • You should install this console on all management servers, including the server with the RMS emulator role.
  • From a performance perspective, it is best to run the Operations consoles from administrator workstations rather than from servers installed with OpsMgr features
  • PowerShell 3.0 is required for administration of UNIX/Linux systems
  • Web Console Servers: This server feature runs IIS and uses Silverlight to provide a web-based version of the Operations console.
  • Most non-administrator and non-authoring users of Operations Manager should be able to use the OpsMgr Web console for a majority of day-to-day operations.
  • Web browsers: Internet Explorer 7, Internet Explorer 8, Internet Explorer 9. Operations Manager 2012 SP 1 removes support for Internet Explorer 7 but adds Internet Explorer 10 and Silverlight 5.0.
  • It is not required that you install Silverlight on the server where you are installing the OpsMgr Web console, but it is often recommended
  • Web Console High Availability/Redundancy: You can configure redundancy for this feature by installing multiple Web console servers and leveraging NLB or other load-balancing solutions
  • Each device managed by the Operations Manager requires an ML, whether you are monitoring it directly or indirectly
  • System Center 2012 Standard: $1,323
  • System Center 2012 Datacenter: $3,607
  • NET monitoring is now integrated into Operations Manager so this does not affect licensing.
  • When monitoring network devices with Operations Manager anything OSI layer 3 and below does not require an SML
  • The planning phase identifies what needs testing as part of the POC—base testing on your business requirements
  • Your focus during POC testing should directly relate to the business requirements identified for your OpsMgr solution.
  • Although you are deploying your production environment design, you will limit either the number of servers to which you are deploying OpsMgr agent or the number of management packs used

Chapter 05: Installing System Center 2012 Operations Manager

  • OpsMgr 2012 does not change the AD schema. After installation, some management packs such as the AD management pack will create containers in the domain configuration. An unusual but important requirement is you cannot install OpsMgr in an AD domain with a “flat” Domain Name System (DNS) domain space
  • The OM_MSAA and the OM_DWWA OpsMgr service accounts must be local administrators on management servers
  • An additional consideration is the security status of the user performing your OpsMgr installation. The user account of this user requires SA (SysAdmin) rights on the SQL servers where the OpsMgr databases will be installed
  • All server roles except for the gateway server, including all SQL database servers, require .NET 3.5 Service Pack 1.
  • All server roles (other than gateway servers that are not involved in monitoring network devices or UNIX/Linux computers), including the operational and data warehouse SQL database servers, require .NET Framework 4
  • If installing the Web console component, it is important the web server role (Internet Information Services) be enabled before installing .NET Framework 4.
  • About the Enable SNMP Feature: It is not recommend installing this feature on management servers or gateways, unless they are physical servers that depend on SNMP-based agents for server hardware monitoring. OpsMgr 2012 does not leverage or interact with the Windows SNMP feature or service in any way. The Windows SNMP trap service is not used by OpsMgr and must not be enabled on OpsMgr servers monitoring network devices.
  • All console instances require Microsoft Report Viewer 2010 Redistributable Package
  • The list in this section is a recommended order of installation
  • Here is the list of features to install:The OpsMgr setup wizard creates and installs the database during setup of the first management server. Note that you must enable Full Text Search in SQL Server
    • 1. First management server
    • 2. Additional management server(s)
    • 3. Reporting server
    • 4. Web console(s)
    • 5. Gateway server(s)
    • 6. ACS
    • 7. Agents
    • 8. ACS forwarders
    • 9. Operating system management packs
  • One SQL Server system each for the operations, data warehouse, and ACS databases, plus a SQL Server Reporting Services server
  • SQL needs inbound firewall rules that permit ports TCP 1433 and UDP 1434. SQL Server Reporting Services requires ports TCP 80 and TCP 443.
  • In the enterprise environment, consider four processor cores and 16GB memory as a recommended minimum machine configuration for the RMS emulator role.
  • After you create a management group, you cannot change its name without reinstalling the management group
  • Notice there is no option to use an existing database; you cannot install OpsMgr 2012 using a pre-created database.
  • Unlike the operational database installation step, there is an option to use an existing data warehouse database.
  • The management server action account, which must be a member of the local Administrators group on the management server
  • This credential reads and updates information in the operational database and is assigned the sdk_user role in this database
  • The System Center Configuration service and System Center Data Access service account. Like the management server action account (OM_MSAA), this account must be a member of the local Administrators group on the management server
  • The Data Reader account is used to deploy reports
  • The Data Reader account is also used as the SSRS IIS Application Pool account that connects to a management server.
  • The Data Writer account reads data from the operational database and writes data from a management server to the data warehouse database
  • The MSAA and SDK accounts (which should not be Domain Admins in normal practice) should be made members of the local Administrators group on management servers.
  • You cannot install any other applications using SSRS on the instance of SQL Server used by OpsMgr reporting
  • OpsMgr needs its own dedicated SSRS instance, one that is fully functional in a default SSRS configuration, before you install OpsMgr reporting.
  • Each OpsMgr management group has only one reporting server
  • Before installing OpsMgr reporting, ensure the user account you plan to use during installation has SQL SA (SysAdmin) permissions on all databases. The Data Warehouse Write account (OM_DWWA in this book) is granted necessary SQL Server logon rights during setup. Service accounts only require local administrative rights on the SQL servers; it is the user account performing the installation that requires elevated SQL permission. (Members of the local Administrators group have SQL logon rights by default.)
  • At the Specify a Management server page, enter the name of a management server to be used by the reporting features only, shown in Figure 5.27. The specified server will handle data associated with specific management servers or management groups. Normally, this is either the name of the first OpsMgr 2012 management server you installed, or if you are using a load-balanced management server pool, specify the virtual server name of the pool
  • After the reporting server is deployed, it can take up to 30 minutes for reports to appear in the Reporting space of the Operations console
  • A key prerequisite for the Web console is having an existing local installation of IIS—you can ensure this by installing the web server role and related features on Windows Server. You must also install the following role services with IIS in addition to the IIS management console:The authors recommend the web server role (Internet Information Services) be enabled before installing .NET Framework 4
    • Static Content
    • Default Document
    • Directory Browsing
    • HTTP Errors
    • HTTP Logging
    • Request Monitor
    • Request Filtering
    • Static Content Compression
    • Web Server (IIS) Support
    • IIS 6 Metabase Compatibility
    • ASP.NET
    • Windows Authentication
  • If you want to enable an SSL connection to the Web console during installation (recommended), install a web server certificate to the default website before running the Web console setup.
  • If you install a stand-alone Web console on a server, you will not be able to add the management server feature to this server
  • Installing the Web console requires ISAPI and CGI Restrictions in IIS enabled for ASP.NET 4.
  • At the Specify a Management server page, enter the name of a management server to be used by the Web console only, as previously shown in Figure 5.27. The management server you specify will handle data associated with specific management servers or management groups. Normally, this is the name of the first installed management server, or if using a load-balanced management server pool, the virtual server name of the pool
  • You may see this warning (circled in Figure 5.35): Web console does not have sufficient access to the database. Setup can continue, but note that some components may not fully install. If this appears and you will be using the application performance monitoring (APM) features of OpsMgr, execute the following SQL statement against the operations and data warehouse databases in SQL Server Management Studio as demonstrated in Figure 5.36.
    • EXEC [apm].GrantRWPermissionsToComputer ‘<domainComputerName>$’
  • Configure permissions inheritance for the Web console:The Web console requires the latest release of Silverlight and a custom Silverlight update. The first time you access the Web console with your browser, you are prompted to install or update Silverlight if needed. It may be necessary to add the website of the Web console to your browser’s trusted sites list.
    • In Windows Explorer, navigate to the MonitoringView folder in the installation folder for the Web console (by default, %ProgramFiles%System Center 2012Operations ManagerWebConsoleMonitoringView), right-click the TempImages folder, and click Properties.
    • On the Security tab, click Advanced.
    • On the Permissions tab, select Change Permissions.
    • Select the Include inheritable permissions from this object’s parent check box.
    • In Permission entries, click Administrators, and then click Remove. Repeat for the SYSTEM entry, and then click OK.
    • Click OK to close Advanced Security Settings for TempImages, and then click OK to close TempImages Properties.
  • If you are deploying a gateway across security boundaries, you must first deploy a public key infrastructure (PKI) using a public, an enterprise, or a stand-alone certificate authority (CA)
  • Preparatory work for deploying a gateway may include installing .NET Framework 4 or 4.5 and obtaining an Operations Manager client certificate with a private key
  • The management group must also be prepared for the gateway server by running the gateway approval tool
  • Always add a gateway to the management group by running the gateway approval tool on the management server before installing the gateway software on the target computer
  • Run the gateway approval tool on a management server. First copy Microsoft.EnterpriseManagement.GatewayApprovalTool.exe and Microsoft.EnterpriseManagement.GatewayApprovalTool.exe.config from the SupportTools folder on the OpsMgr installation media to the OpsMgr program files server folder, generally %ProgramFiles%System Center 2012Operations ManagerServer
  • Run the tool with command line switches to assign the new gateway to an existing management server or gateway
  • At the Gateway Action Account page, select to use Local System if the gateway will not be pushing agents to other computers. If the gateway will push install agents, enter credential information for an administrative account in the domain of the gateway server
  • You must enable the Server Proxy setting on the new gateway server.
  • You are using certificates for authentication, import the Operations Manager client certificate on the gateway server.
  • Preparation for deploying ACS includes deciding whether you will install ACS reporting integrated with the reporting space in the Operations console, or on a separate, non-integrated, SSRS instance
  • Installing ACS on a secondary management server, which creates the new ACS database
  • Deploying ACS reporting to an SSRS instance
  • If you will use ACS to collect security events from computers in untrusted domains or workgroups, provision the ACS collector with the same certificate used to enable management server to gateway communication
  • Click on the DBAudit datasource and confirm Windows integrated security is selected for the connection credential type
  • If deploying ACS reporting in the non-integrated model that is not integrated with OpsMgr reporting but is installed on a dedicated standoff instance of SSRS, you must manually upload the report banner files to avoid a red “X” (missing graphic) at the top of your ACS reports. Open SQL Server Reporting Services in your web browser and navigate to the Home folder. (You should see the AuditReports data source folder at the same level.) Click the Upload File button and locate the files banner_landscape.jpg and banner_portrait.jpg in the %ProgramFiles%System Center 2012Operations ManagerReportingReports folder on the SSRS computer.
  • Import the Operations Manager client certificate on the agent:Enable audit collection first for all management servers and gateways, then for all agents
    • Copy the MOMCertImport.exe file from the SupportTools folder on the OpsMgr installation media to the Operations Manager program files client folder.
    • Open an elevated command prompt on the agent computer, and change directory to the OpsMgr program files server folder, such as %ProgramFiles%System Center 2012Operations ManagerAgent.
    • Run the tool with command line switches to import the certificate as previously seen in Figure 5.46 when installing a gateway server
  • For any fresh deployment, deploy the latest update rollup to all management group components.
  • The new System Center 2012 Operations Manager network device monitoring feature requires the Windows Operating System management packs to be installed
  • To complete the core management group deployment, import these management packs:
    • Windows Server Operating System Reports
    • Windows Server Operating System Library
    • Windows Server 2008 Operating System (Discovery)
    • Windows Server 2008 Operating System (Monitoring)
  • If you are using clustered OpsMgr SQL servers, consider also importing these management packs:
    • Windows Cluster Management Library
    • Windows Cluster Management Monitoring
    • Windows Server 2008 Cluster Management Library
    • Windows Server 2008 Cluster Management Monitoring
    • Windows Server 2008 Cluster Shared Volume Monitoring
  • Removing OpsMgr: If you need to remove Operations Manager from your environment, the recommended process is the reverse order from which you installed the components. All OpsMgr installed components are manually uninstalled in a conventional manner using Control Panel -> Programs and Features. Follow this recommended outline to remove OpsMgr from your environment:
    • 1. Disable the ACS forwarder component on all management servers, gateways, and agents using the Operations console.
    • 2. Delete any computers monitored by agentless monitoring in the Operations console.
    • 3. Manually uninstall all manually installed agents.
    • 4. Remotely uninstall all automatically installed agents using the Uninstall task in the Operations console.
    • 5. Uninstall the gateway server component from gateways and delete the gateway computer objects in the Operations console.
    • 6. Uninstall all Web consoles and dedicated Operations console instances.
    • 7. Uninstall the Reporting Server component.
    • 8. Disable the ACS Collector role on any management servers running that role.
    • 9. Uninstall each management server, uninstalling the root management server emulator last.
    • 10. Optionally back up, and then delete the operational, data warehouse, and ACS databases from the SQL server(s) that hosted them.

Chapter 06: Upgrading To System Center 2012 Operations Manager

  • Upgrading to System Center 2012 Operations Manager is supported from OpsMgr 2007 R2 Cumulative Update 4 (CU) or later.
  • Specifically, by deploying network load balancing (NLB) and establishing a DNS name for the NLB address of the management server pool, you can configure Operations consoles, Web consoles, and the reporting server with the DNS name for the pool
  • If your management servers, gateways, or database servers are running Windows Server 2008 R2 with SP 1, you can upgrade these computers to Operations Manager 2012
  • Database servers running versions SQL Server 2008 SP 1 (or later service packs) or R2 can be upgraded
  • Upgrading an ACS collector from OpsMgr 2007 R2 to OpsMgr 2012 does not perform SQL version checking; therefore, any existing ACS database will continue to be used by OpsMgr after the upgrade
  • Microsoft’s process flow diagram for upgrading Operations Manager is located at http://technet.microsoft.com/en-us/systemcenter/hh204732.aspx.Manually installed agents are your first priority. The authors recommend you then upgrade gateways that report to secondary management servers, conforming to an “outside -> inward” upgrade approach. This method is your best track to maintaining uninterrupted monitoring during migration
  • If you have PowerShell (PS) scripts running in your management packs that utilize the OpsMgr 2007 snap-in PS module, verify the snap-in is still available on the upgraded servers. Run the cmdlet Get-PSSnapin -registered. If the output lists PSVersion: 1.0, Microsoft Operations Manager Shell Snapin, the module is registered. If the module is no longer registered, follow the instructions at http://derekhar.blogspot.de/2007/07/operation-manager-command-shell-on-any.html to register the OpsMgr 2007 modules manually.
  • the data warehouse upgrade can fail with only 2GB memory installed.
  • Reject any agents in the Device Management -> Pending Management node of the Administration space of the Operations console.
  • Stop all System Center Operations Manager services and disable any installed connectors
  • Verify the operational database has at least 50% free space before upgrading the management group. The upgrade might fail if there is not enough space. Also ensure that the transaction logs are 50% of the total size of the operational database:
  • If you upgrade manually installed agents that also run the AVIcode 5.7 agent (or earlier versions of the AVIcode agent), you must include the option NOAPM=1 in the command
  • You cannot select the current Operations Manager 2007 Web console website as that site is deleted during the upgrade.
  • Run a SQL query on the operational database to clean up the Localizedtext table and the Publishmessage table. You can copy this query from Microsoft’s website at http://technet.microsoft.com/en-us/library/8c2dbaf4-2966-45e3-a72d-5de90ff4f495#BKMK_VerifyUpgrade.
  • Follow the procedure at http://technet.microsoft.com/library/ms187510.aspx to create a full SQL database backup if you do not have a backup process in place.
  • Run a SQL query on the operational database to clean up the Localizedtext table and the Publishmessage table. You can copy this query from Microsoft’s website at http://technet.microsoft.com/en-us/library/8c2dbaf4-2966-45e3-a72d-5de90ff4f495#BKMK_VerifyUpgrade.
  • After upgrading your management group from the secondary management server, manually edit the rsreportserver.config configuration file for the reporting server. If you attempt to upgrade reporting without making this change, the Upgrade Wizard will report a cri
  • tical prerequisite issue, because Operations Manager cannot connect to the reporting server. (If you upgraded your management group from the RMS, you do not have to update the configuration file manually for the reporting server.)
  • deploy management packs in a phased and deliberate approach. In particular, deploy several sealed management packs at a time and watch the effects on the management group in terms of alerting. As you discover alerts that need overrides applied, author overrides and save them in unsealed override management packs. Once monitoring is stable and effective, add another small batch of management packs until all critical business applications have end-to-end monitoring in place.
  • Custom distributed applications (DAs) in the OpsMgr 2007 R2 management group will likely need to be authored again using the Operations console once all required objects for the DA are discovered by OpsMgr 2012.
  • importance of having backups of the operational and data warehouse databases, as well as the complete computer and system state backup of the RMS.
  • A new feature in OpsMgr 2012 is enabling high availability for the Data Access Service (DAS). This allows consoles, Web consoles, and report servers not to depend on a particular management server for access to the database. While you can implement this feature using Windows network load balancing, the authors suggest a hardware or virtual appliance load balancer. In this example management group, the four OpsMgr 2012 management servers will be load-balanced and addressed by a single private DNS alias such as scom.odyssey.com.

Chapter 07: Configuring And Using System Center 2012 Operations Manager

  • It is not a good practice to run the Operations console on a management server itself; you want to dedicate all MS resources for the critical OpsMgr services it hosts.
  • Microsoft suggests that you not plan for more than 50 simultaneous Operations console sessions in a single management group. The authors recommend you close any console sessions not in active use.
  • To avoid cluttering your Monitoring pane, the authors recommend you avoid creating additional global views unless all users of the Operations console will use them.
  • For information on how to remove clutter from the Monitoring pane, see the suggestions at http://blogs.catapultsystems.com/cfuller/archive/2011/05/11/quicktricks-decluttering-the-monitoring-pane-view.aspx.
  • Tip: Changing the Report URL for the Web Page View
  • The reporting URL uses a value of “%2f” to represent the “/” character, the “%20” to represent a space “ ”, and the “%3a” to represent the “:” character. The Web Page view will not accept these characters, so to get the view to display the web page you must substitute the references to “%2f” to have “/” in their place, “%20” to have “ ” in their place, and “%3a” to have “:” in their place
  • the Operations Manager 2007 R2 Resource Kit (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26139) includes a Scheduled Maintenance Mode utility enabling you to schedule and manage maintenance mode
  • Many organizations use Tim McFadden’s GUI-based remote maintenance scheduler, available for download at http://www.scom2k7.com/scom-remote-maintenance-mode-scheduler-20/.Microsoft does not recommend or support placing a management server into maintenance mode
  • The web version of the Health Explorer displays all health states unfiltered, as in OpsMgr 2007.
  • Resetting the health forces the monitor back to a health state.
  • Recalculating health forces the monitor to reassess what it believes is the current health state.
  • Recalculating health does not work for over 95% of all monitors in Operations Manager 2012
  • This view is extremely helpful when attempting to identify objects and whether they are discovered. Marnix Wolf gives a nice example of how this view is useful at http://thoughtsonopsmgr.blogspot.com/2010/04/where-are-my-counters-for-windows.html,
  • The most effective use of the Monitoring space is a combination of configuration decisions involving these features:Let’s begin with personalizing the properties of the Active Alerts global view. This view does not include two very useful fields for reviewing active alerts—the Last Modified field and the Repeat Count field. These fields are helpful when identifying recurring alerts and when alerts last reported a modification
    • Personalizing the global views and other default views
    • Creating new global views and views in child view folders
    • Creating new child view folders or hierarchies of view folders
    • Creating new tasks, specific for your environment, that automate actions related to the object(s) selected in console views
  • the ReSearch This management pack
  • Other community-created management packs perform actions such as calling Green Machine to reset health state, executing Windows administration tasks, forwarding alerts via email, running tools from the PsTools Suite (available at http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx), and more. To download these and other examples, go to http://tinyurl.com/SCCMPs.
  • When creating new management packs it is important you have thought through a plan for creating them and establish a strict naming standard for your management packs
  • When creating a distributed application in System Center 2012 Operations Manager, first create the service that defines the distributed application monitoring object at a high level.
  • use the Distributed Application Designer to define the individual components that are part of the distributed application you want to monitor.
  • As a best practice, your groups should automatically populate with objects of the type you are interested in, rather than depend on manual population of the group using the explicit group membership step
  • System Center Central provides examples of how to create dynamic groups in OpsMgr, see http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/89416/Default.aspx.
  • Tip: How to Manage System Center Operations Manager using Groups: For additional information on groups and using them in OpsMgr, see the whitepaper at http://go.veeam.com/manage-scom-using-groups-wp.html.
  • Tip: Attributes Versus Properties: There is no difference between an attribute and a property—they are the same thing. Attributes are discovered properties of a class or type, which is made up of discovered instances or objects.
  • Tip: Automatically Grouping Servers in OpsMgr Based on Tier: For additional information on how to gather a custom attribute such as the tier of a server (as an example, a development system may be a Tier 5 and a production critical system would then be a Tier 1 server), see the blog post at http://blogs.catapultsystems.com/cfuller/archive/2009/01/16/automatically-grouping-servers-in-opsmgr-and-configmgr.aspx.
  • Tip: Avoid Creating Unnecessary Attributes: The Operations console does not let you delete attributes after they are created, so do not create attributes unless you know you will use them. (To remove an attribute, you must export the management pack, delete the attribute in the XML file, and reimport the management pack.)
  • For additional reading on using Service Level Tracking functionality in Operations Manager, seeTip: Finding Objects and Groups for a Report Before Running the Report: How do you know what to use as the “object” or “group” for a report? When you open a report, you must change parameters to specify the start date and the targeted groups or objects. Before you even run the report, review the text at the bottom (the report details section). It specifies which objects provide what information.
  • New reports include the Performance by System and Performance by Utilization reports, providing answers to some commonly asked questions such as How do you create a simple free disk space report
  • Tip: System Center Reporting Tips: For additional tips on using reporting in Operations Manager, see Cameron Fuller’s Windows IT Pro article on 10 OpsMgr 2007 Reporting Tips, available at http://www.windowsitpro.com/article/microsoft-system-center-operations-manager-2007/10-system-center-operations-manager-reporting-tips-140603.
  • Tip: Configuring Agent Proxying: Because this configuration change is extremely common and often must be performed on a large number of systems, there are a number of ways to configure agent proxying without changing systems one at a time in the Operations console. Here are several to consider:Enabling proxy allows a server to submit discovery data on instances that are higher in the hierarchy than the server itself is. This theoretically increases your attack surface, as it is possible a malicious source that gains control over a machine could inject false discovery data providing invalid information to your management group. While the authors have not heard of such a case occurring, it is important to be aware of the implications of this setting in OpsMgr.
  • During installation, nearly 90 management packs are imported into OpsMgr 2012, providing a minimal amount of monitoring (the number imported varies based on the service pack level you are installing).
  • Tip: Management Pack Naming Standards: Developing and using a management pack naming standard can save countless hours and problems when trying to find custom rules, monitors, or determining the appropriate place to store an override. From the authors’ perspective, you should to have a standard, document it, and store it somewhere easy to locate (such as in SharePoint with a web page view pointing to the document library). Pete Zerger from System Center Central has a good discussion on how to choose appropriate naming conventions, available at http://www.systemcentercentral.com/tabid/145/indexId/73805/Default.aspx.
  • The Operations console management pack download and import options only provide downloads for Microsoft management packs, not any by third parties available in the System Center Marketplace.
  • Tip: Providing Multiple SMTP Servers in OpsMgr Channels: OpsMgr supports up to three SMTP servers per channel to provide additional failover in situations where communication does not occur successfully to the primary SMTP server. The authors recommend using all these channels to provide failover even if the servers are highly available Exchange servers (such as an Exchange cluster). For details and why it is relevant in Exchange back pressure situations, see http://blogs.catapultsystems.com/cfuller/archive/2012/01/09/exchange-back-pressure-amp-opsmgr-notification-channels.aspx.
  • Command channel notification is like the Swiss army knife of notifications, as you can do pretty much anything with it as it is running a script. As an example, you can use the command channel to create a ticket as discussed at http://scug.be/blogs/dieter/archive/2011/05/11/scom-setup-command-notification-channel-subscriber.aspx.
  • create a unique email channel on a per-subscription basis and specify a different return address for each channel (for example, the SQL alerts return address could be SQLAlerts@odyssey.com). Add your OpsMgr administrators to each subscription and create Outlook rules to classify the alerts based upon the return address so your SQL alerts would route to a specific folder. This provides a quick way to identify what alerts were sent, to whom, and the subscription they came from.
  • The message format available in notifications is customizable on a per-channel basis depending upon your requirements. Kevin Holman has gathered a list of the parameters you can use at http://blogs.technet.com/b/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx.
  • While you can create subscribers for individual email addresses, the recommended approach is to use mail-enabled security groups to avoid the maintenance involved for individual subscriptions. Using mail-enabled security groups simplifies maintenance by using Active Directory to maintain the list of who receives subscriptions.
  • When defining subscriptions, understand you cannot exclude a specific alert from notification
  • Profiles: Run As profiles allow monitors, rules, and tasks to run as an account with sufficient privileges. As an example, a SQL Server instance may need a different account to provide sufficient access to the databases than the default agent action account.
  • You can create up to 254 custom resolution states; you will want to expand on the two built-in states (Closed and New). The authors suggest at least adding the new resolution states of Acknowledged and Assigned to help manage alerts
  • Tip: New Alert Resolution states in OpsMgr 2012 service pack: With the release of Service Pack 1 for Operations Manager 2012, several resolution states have been added, which include: Acknowledged (249), Assigned to Engineering (248), Awaiting Evidence (247), Resolved (254), and Scheduled (250).
  • Tip: Performance Signature data Grooming: While the user interface says two days is the default performance signature retention period, the actual retention period is two business cycles and these are groomed once per week.
  • The authors recommend enabling at least the CEIP and operational data reporting options; these do not affect the operation of the management group or its users, and they provide anonymous data to Microsoft that helps improve the quality of the OpsMgr product.
  • the default settings of OpsMgr will fire an alert on a down agent after approximately three minutes, which is the server missed heartbeat setting multiplied by the agent heartbeat interval.
  • one of the first views the authors will commonly create is an All Alerts view that displays all alerts regardless of their state. This view provides a quick way to see what alerts are in the database including those in a closed state.
  • Jalasoft Xian Wings: Xian Wings provides a mobile platform for Operations Manager that supports the iPhone, iPad, Windows Phone 7, Windows Mobile, Android, and Blackberry devices, displaying information from OpsMgr that includes alerts and performance data and allows you to interact using existing OpsMgr tasks from a mobile device
  • Source files for currently installed management packs are located on each management server at %ProgramFiles%System Center 2012Operations ManagerServerHealth Service StateManagement Packs
  • It is a best practice to import only the management packs required to meet your monitoring and management goals
  • The Web Application Monitoring template provides a quick way to add large numbers of URLs for monitoring in OpsMgr, with agents or resource pools serving as watcher nodes.

Chapter 08: Installing And Configuring Agents

  • The OpsMgr admin specifies if the management server action account or another account with administrator-level privileges will be used. The specified account is used for discovery with Active Directory and to push the agent to the system that will be monitored.
  • If the option to verify discovered computers was selected (the advanced computer discovery option in step 2), each client is contacted through ports 135, 137, 139, 445, and 5723.
  • The action account uses either Local System or the specified domain account to create tasks to deploy the agents
  • To discover machines residing in non-trusted domains and workgroups, provide the computer name in the format <domain><ComputerName> or <workgroup><ComputerName>.
  • Pete Zerger provides a two-part blog post with an example of how to identify those computers in Active Directory that do not have the Operations Manager agent (see part 1 at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/94221/Default.aspx). After identifying these computers, you can automate agent installation with PowerShell (discussed in part 2, at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/94248/Default.aspx). You can schedule these scripts to run on a recurring basis using the Windows task scheduler
  • Using these performance counters, you can determine the overhead added by OpsMgr. During testing by the authors, the OpsMgr processor impact to servers typically was less than 2%;
  • Microsoft has also added the Agent processor utilization monitor, which alerts if the agent utilization exceeds a threshold of 25% over a set of six consecutive samples.
  • Table 8.1. OpsMgr 2012 agent and agentless monitored resource requirements during deployment
  • Table 8.2. OpsMgr 2012 agent and agentless monitored resource requirements after deployment
  • OpsMgr 2012 supports up to 10 agentless managed systems reporting to a single management server, and 60 in a management group
  • With the release of System Center 2012 Service Pack (SP) 1, a Service Manager server can now have an agent installed that reports to Operations Manager in a multi-homed configuration.
  • Active Directory Integration (provides agent configuration information, but does not actually install the agent)
  • Although you can use OpsMgr to monitor client operating systems, most organizations typically only monitor servers (this is often a licensing-based decision)
  • This pack provides the ability to monitor the availability, configuration, and performance of Windows client operating systems
  • Tip: Extending Desktop Monitoring: At the Microsoft Management Summit (MMS) 2012, Infront Consulting Group demonstrated its Business Critical Desktop Monitoring management pack; this augments existing Operations Manager client monitoring by providingAdditional information on this pack and others available from Infront Consulting Group is available at http://www.infrontconsulting.com/software.php.
    • Monitoring for desktop and application health.
    • Identification for currently logged on users and systems pending reboot.
    • Associating users with their desktop for easier identification.
    • Tasks for remediation include the ability to reboot a workstation, enable remote desktop, set current user as registered owner, and explore the remote C: drive.
  • Tip: The “Universal Linux” Monitoring Packs: Support for the new UNIX operating systems added with SP 1 is implemented using the “Universal Linux” monitoring packs. Here are the MP files required to add monitoring for these operating systems:The Operations Manager management server must be able to resolve the name of the OpsMgr agent and vice versa. To validate name resolution is working correctly, ping the fully qualified name of the agent from the management server, and the management server from the agent.
    • Microsoft.Linux.Universal.Library.mp
    • Microsoft.Linux.Universal.Monitoring.mp
    • Microsoft.Linux.UniversalD.1.mpb (to support Debian and Ubuntu Linux agents)
    • Microsoft.Linux.UniversalR.1.mpb (to support CentOS Linux agents)
  • An account must exist with access to the system to install the agent. On Windows, the account requires local administrator rights. On UNIX/Linux systems, the account either needs to have privileged access or the rights to use sudo or su elevation.
  • Tip: UNIX/Linux system not Monitored: When a UNIX system shows as not monitored, this is usually because a Run As account is not assigned. As there is no local system account on UNIX, you must create a UNIX/Linux account and assign it to the UNIX/Linux Action Account RunAs profile.
  • This means traffic must be able to route between the two servers, and the port the agent communicates with needs to be open for communication and reachable by the agent. To validate communication is working correctly, telnet from the agent to the server or from the server to the agent on the appropriate communication port. (This is port 5723 from the agent to the management server for Windows, 1270 from the management server to the agent for UNIX/Linux.)
  • UNIX/Linux Management Pack Requirements: UNIX/Linux agents cannot have the Operations Manager agent installed until the appropriate UNIX/Linux OS management pack is imported. While the core UNIX/Linux libraries are imported when you install System Center 2012 Operations Manager, you must add the complete management packs for each OS version before attempting to monitor UNIX/Linux agents. These management packs are available on the installation media in the ManagementPacks folder or you can download them from the System Center Marketplace.
  • The list of currently available management packs for UNIX/Linux includes individual downloads for the different versions of AIX, HP, Linux, and Solaris. Separate management packs are also available for ACS functionality on these operating systems.
  • Agents deployed using the Discovery Wizard do not pull their information from Active Directory, even if Active Directory Integration is in place.
  • Agents deployed through the Discovery Wizard are defined to report to a specific management server. Should the management server fail, they fail over to another management server.
  • The best practice recommendation by the authors is to use the Discovery Wizard to discover and deploy agents in all but the largest of OpsMgr environments.
  • Tip: Avoid using the servers only Option in the Discovery Wizard: It is a best practice to not use the Servers Only option during a discovery as the filter requires contacting each machine for verification. This process slows down the discovery and can lead to discovery failures from timeouts. The Servers Only option is most useful when doing an extremely filtered LDAP query for specific machines versus a large-scale discovery.
  • Check the option Verify discovered computers can be contacted. This often increases the success rates of the deployment because only systems that can be communicated with over the network are listed for selection.
  • The discovery can return approximately 4,000 computers if the verify option is selected, and approximately 10,000 computers if not selected.
  • Note: Discovery Wizard Stuck on “Discovery is in Progress”Tip: Trust Requirements to Deploy Agents: Agent authentication in OpsMgr requires Kerberos or certificate-based authorization to provide mutual authentication. Use certificate-based authorization for gateway configurations where agents are in untrusted domains or workgroups. Within a forest, transitive two-way trusts are automatically created that support Kerberos.
  • Prerequisites for UNIX/Linux AgentsUsing the wizard is the easiest way for deploying OpsMgr agents to UNIX/Linux systems as well as Windows systems. Before running the wizard, import the appropriate UNIX/Linux management packs, create a resource pool to monitor the agents, create configuration certificates, define the Run As accounts, and identify the IP address(es) of the systems
    • For UNIX/Linux agents to be discovered correctly, here are several required steps before running the Discovery Wizard:
      • Import management packs required for UNIX/Linux monitoring, discussed in the “UNIX/Linux Management Pack Requirements” section.
      • Create a resource pool for monitoring UNIX/Linux servers, performed at Administration -> Resource Pools. Create a new resource pool and add the appropriate management servers to that resource pool.
      • Configure the cross platform certificates (export/import) for each management server in the pool. Information on this process is available at http://technet.microsoft.com/en-us/library/hh287152.aspx. Details on certificates, troubleshooting agent deployment, and other topics related to UNIX/Linux servers are discussed in Chapter 20, “Interoperability and Cross Platform.”
      • Create and Configure Run As accounts for UNIX/Linux systems; see http://technet.microsoft.com/en-us/library/hh212926.aspx for additional information.
  • Tip: Privileged and Unprivileged Accounts in OpsMgr 2012: A commonly asked question is What are the actual differences between a UNIX/Linux privileged and unprivileged account in OpsMgr 2012?
  • A privileged account needs to have root-level access to the system including access to security logs and Read, Write, and Execute permissions within the directories where the OpsMgr agent was installed.
  • An unprivileged account is a normal user account without root access or special permissions, but you can use the account for monitoring system processes and performance data.
  • Tip: Additional Cross Platform Discovery Wizard Information: There are some excellent additional resources available online for UNIX/Linux agent information. Here are some of the authors’ favorites:Tip: Upgrading Manually Installed Agents: Once an agent is installed manually, any update rollups must be manually applied. Cameron Fuller provides a method to update manually installed agents through the Operations console, available at http://blogs.catapultsystems.com/cfuller/archive/2012/04/27/how-to-upgrade-clients-to-cu5-which-were-manually-installed-in-opsmgr-scom-sysctr.aspx. This builds upon Kevin Holman’s article at http://blogs.technet.com/b/kevinholman/archive/2010/02/20/how-to-get-your-agents-back-to-remotely-manageable-in-opsmgr-2007-r2.aspx.
  • The recommended way to install the agent is running the Setup.exe program on the root of the installation media and choosing the Local Agent option. This runs the MOMAgent.msi file for the appropriate platform and turns on logging during the installation
  • Tip: When to Use Active Directory Integration: Jonathan Almquist provides an insightful blog article discussing when one should use Active Directory Integration in OpsMgr, available at http://blogs.technet.com/b/jonathanalmquist/archive/2010/06/14/ad-integration-considerations.aspx. His main point about AD Integration is that while it provides a way to facilitate including the OpsMgr agent in a server image, AD Integration is not very forgiving of mistakes made. In most cases, you can avoid AD Integration by using the command shell to assign primary and failover configuration, unless the goal is to include the OpsMgr agent in a server image.
  • Tip: How Active Directory Integration Works: Steve Rachui put together an excellent blog article explaining how AD Integration works in OpsMgr 2007. AD Integration has not changed significantly since OpsMgr 2007, so this article still applies to OpsMgr 2012 and is available at http://blogs.msdn.com/b/steverac/archive/2008/03/20/opsmgr-ad-integration-how-it-works.aspx.
  • Microsoft documentation provides a comprehensive list of ports that are required for Operations Manager 2012, available at http://technet.microsoft.com/en-us/library/hh205990.aspx. However, the most commonly asked question focuses specifically around what ports are required to install OpsMgr agents and those that are necessary to support OpsMgr communication from the agents. Here are the ports required to install OpsMgr agents:Note: Agent Push and Firewalls
    • Windows agent push installation, repair, or upgrade requires TCP 135, 139, 445, 5723, UDP 137, 138.
  • The OpsMgr agent is pushed using RCP/DCOM from the management server or gateway server to the system to which the agent will be installed. For agent push installation to succeed, the Windows Firewall on the server and agent must be configured to have exceptions allowing the appropriate management or gateway server(s) to communicate with the system. If the Windows Firewall is disabled on the system, the firewall exceptions are not required. The default “Domain Profile” Windows Firewall will allow agent push without modification.
  • UNIX/Linux agent push installation requires communication from the pool of management servers monitoring UNIX/Linux systems: TCP 22 (SSH), 1270 (inbound).
  • The required ports to maintain communication areTo change an agentless system to agent-managed, you must first delete the agentless managed system and then deploy the agent to the system
    • OpsMgr agent communications to management servers on TCP 5723.
    • If ACS is active on the agent, the ACS forwarder port is required to the ACS collector; this is TCP 51909.
    • IF AEM is active on a system, the AEM information port is required to the AEM server; this is TCP 51906.
    • UNIX/Linux agent communication from the pool of management servers monitoring UNIX/Linux systems; port TCP 22 (SSH), 1270 (inbound).
  • Here are recommended actions to check and verify the health of a Windows OpsMgr agent:
    • 1. First, verify agent health in the Operations console at Administration -> Agent Managed. If the agent is grey, this indicates it is not communicating with OpsMgr. If the agent is not monitored, it has not reached a monitored state or it is in maintenance mode.
    • 2. Verify agent health in the Monitoring pane under Operations Manager -> Agent Details -> Agent Health State view. This view provides health state information from both the agent and the Health Service Watcher.
    • 3. Check the Computer view in the Monitoring pane to verify that the agent and operating system are monitored. Here are some reasons the OS may not be monitored:
      • The system has not been identified with an OS that can be monitored with an installed management pack.
      • The system is agentless monitored.
      • The system is experiencing issues deploying the OS-specific management pack.
    • 4. Review the Agent Details -> Active Alerts view to review alerts that may be affecting the agent’s health.
    • 5. Access the Operations Manager log remotely or locally to identify critical or warning errors occurring on the system.
  • Here are recommended steps for checking and verifying the health of a UNIX/Linux OpsMgr agent:Steps to perform this action include using a SQL query to update the agent’s values for IsManuallyInstalled to 0. Making this change causes this agent to be seen in OpsMgr as a remotely manageable agent. Once an agent is listed as remotely manageable, it can be repaired for you to apply the current update rollup and then flush the health cache on the agent
    • 1. Verify agent health in the Administration -> UNIX/Linux Computers node. If the agent is grey, this indicates it is not communicating with OpsMgr. If the agent is not monitored, it has not reached a monitored state or is in maintenance mode.
    • 2. Check the UNIX/Linux Computer view in the Monitoring pane to verify the agent and the operating system are monitored. Here are some reasons the OS may not be monitored:
      • The system has not been identified with an OS that can be monitored with an installed management pack.
      • The UNIX/Linux Default Action Account has not been defined for UNIX/Linux systems.
      • The system is experiencing issues deploying the OS-specific management pack.
  • The exception to the default event log size rule may be applications that are extremely intensive on the application or system logs such as Microsoft Exchange (historically, this had a recommended 40MB application event log according to the Exchange Best Practices Analyzer information available at http://technet.microsoft.com/en-us/library/aa997362), or custom-built applications.
  • If there is a requirement to increase the log file sizes, you can do this directly through the event viewer application or by creating a group policy. For maximum recommended event log sizes per platform, see http://support.microsoft.com/kb/957662.
  • There have been discussions in the OpsMgr newsgroups about problems when the agent heartbeat frequency is set to less than the default of 60 seconds. Additionally, if this value is increased it delays any heartbeat alerts that may occur.
  • Agent failover is often a misunderstood topic in Operations Manager. To dispel a myth here first—agent failover is built into OpsMgr even without using AD Integration. If a management server fails in OpsMgr, the agent is moved to another management server. The challenge is that within the user interface there is no way to specify a management server. To define how agents fail over you must either use AD Integration or PowerShell scripts.
  • An Operations Manager agent stores data that must be sent to the management server in a queue file. The queues prevent loss of data when a management server is not available (such as when rebooted to apply patches and other maintenance).
  • These queues default to 15MB in size (15,360KB). For most systems, this should be sufficient to hold the OpsMgr data for several hours
  • You can change the size of this queue on a per-agent basis in the registry at HKLMSYSTEMCurrentControlSetServicesHealthServiceParametersManagement Groups<Management Group Name>MaximumQueueSizeKb.
  • Those systems monitored by Operations Manager that have their name changed must have the agent removed and reinstalled. If the renamed system does not have its agent uninstalled and reinstalled, the original system name still appears in the console, but no longer reports information back correctly to OpsMgr.
  • agentless managed systems are systems monitored by a proxy agent that performs the actual monitoring rather than deploying an agent to the system you are monitoring, while Agentless Exception Monitoring captures aggregates and reports on application crashes (Dr. Watson errors) within your management group.
  • Troubleshooting the Installation of the System Center Operations Manager Agent: http://support.microsoft.com/kb/2566152
  • Console based Agent Deployment Troubleshooting table: http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexId/60047/Default.aspx
  • Troubleshooting UNIX/Linux AgentsAgents and pools: Windows agents do not report to pools in Operations Manager 2012—they still report to Operations Manager servers. Cross platform agents do report to pools in Operations Manager 2012.

Chapter 09: Complex Configurations

  • When designing for OpsMgr, you should consider two areas: the functional area that identifies and describes the requirements, and the technical design that maps those requirements to a certain technical solution.
  • Using NLB, you can create an NLB cluster of some or all management servers. When the Operations console connects to that NLB cluster and a connection to a node in the cluster fails, it is automatically redirected to another management server.
  • Incorporating NLB makes the Web console more useful as you can also make it highly available
  • A two-node failover cluster requires at a minimum the enterprise version of the Windows Server operating system and the standard edition of SQL Server.
  • Microsoft officially supports failover clustering for the OpsMgr operational database, data warehouse database, and audit database
  • Microsoft does not support making SQL Server Reporting Services (SSRS) highly available for OpsMgr,
  • default, the OpsMgr databases are installed using the simple recovery model. Log shipping only functions when replay of the log can take place, which does not occur with the simple recovery model. This means you must change to a full recovery model for those databases, resulting in larger transaction log files, which requires more disk space for each SQL database and SQL Server system.
  • OpsMgr has specific requirements for SQL collation settings
  • The operational and data warehouse (OperationsManager and OperationsManagerDW) databases are installed using the simple recovery model. A simple recovery model results in an empty transaction log since transactions are truncated from the log once they are written to the database.
  • Tip: Online Resources for Log Shipping: For a detailed guide about configuring log shipping for OpsMgr, see http://social.technet.microsoft.com/wiki/contents/articles/11372.configure-sql-server-log-shipping-guide-for-the-system-center-operations-manager-2007-r22012-operational-database.aspx.
  • The console requires the System Center Data Access Service (DAS).
  • You can use Network Load Balancing to make the System Center Data Access Service highly available.
  • Here are the high-level steps to set up NLB for the DAS:Tip: Resources for Network Load Balancing the data Access Service: Microsoft TechNet is an excellent resource for information about network load balancing the DAS. You can begin with http://technet.microsoft.com/en-us/library/hh316108.aspx, which contains references to other TechNet articles about NLB. These are must-reads for anyone interested in using network load balancing for the System Center Data Access Service.
    • 1. Configure static IP addresses for all nodes participating in the NLB cluster.
    • 2. Enable NLB for each management server participating in the NLB cluster.
    • 3. Create the NLB cluster with its Virtual IP (VIP) address.
    • 4. Add one or more additional hosts—running the System Center Data Access Service (this could be any OpsMgr management server)—to the NLB cluster.
    • 5. Create a host record in DNS referring to the VIP address.
  • The procedure required to network load balance the Web console is similar to that used for the System Center Data Access Service. Here are the high-level steps:Neil Harrison of Microsoft has written a series of blog postings about ACS high availability; see http://blogs.technet.com/b/neharris/archive/2011/03/22/acs-forwarders-and-high-availability-part-1.aspx.
    • 1. Configure static IP addresses for all nodes participating in the NLB cluster.
    • 2. Enable NLB for each management server participating in the NLB cluster.
    • 3. Create the NLB cluster with its VIP address.
    • 4. Add one or more additional hosts—running the OpsMgr Web console—to the NLB cluster.
    • 5. Create a host record in DNS referring to the VIP address.
  • ACSConfig.xml is updated every 5 minutes by the AdtServer service.
  • A mechanism is in place (such as a scheduled task) that copies ACSConfig.xml every 5 minutes from the active to the passive collector
  • Anders Bengtsson of Microsoft has an excellent post on how to eliminate both SPOFs at http://contoso.se/blog/?p=831.
  • For information about configuring gateway server failover between management servers, see http://technet.microsoft.com/en-us/library/hh456445.aspx. Anders Bengtsson provides a blog posting at http://contoso.se/blog/?p=831 that also shows how to configure the agent for automatic failover
  • While OpsMgr 2012 lets you create your own resource pools, here are some considerations:If running an OpsMgr environment with more than two management servers and you want to divide the different monitoring workloads, you could create dedicated resource pools for monitoring things such as network devices or UNIX/Linux systems
    • Creating dedicated resource pools for UNIX/Linux, URL, and network monitoring allows you to scale out easily when having resource issues without affecting the other monitoring workflows.
    • Only create a new resource pool when there is a requirement for it and an additional pool makes sense.
    • Populate your new/custom resource pools wisely. For example, installing two additional management servers and placing them into three custom resource pools is counterproductive; those management servers would have to run the workloads of all three resource pools combined. A good rule of thumb is having at least one dedicated management server allocated to each resource pool you create.
  • Similar to any other OpsMgr agent, it compresses traffic sent to its management server
  • Helpful Resources for Multi-Homing Agents Using Scripting APIS
  • During agent deployment, its control panel applet is installed/registered with AgentConfigManager.dll. This DLL file contains useful .NET functions that you can reference and call using PowerShell, VBScript, and so on.
  • Here are some resources about how to use these .NET functions:The authors want to thank Kevin Holman for his posting about the agent control panel applet. The same posting also contains references about the .NET functions contained by the DLL file and using them; see http://blogs.technet.com/b/kevinholman/archive/2011/11/10/opsmgr-2012-new-feature-the-agent-control-panel-applet.aspx.
  • You cannot connect management groups of different builds. This also means an OpsMgr 2007 management group cannot be connected with an OpsMgr 2012 management group.
  • Microsoft provides documentation about OpsMgr connected management groups at http://technet.microsoft.com/en-us/library/hh230698.aspx. The authors strongly advise reading this article before connecting OpsMgr management groups.
  • Here are the high-level steps that describe an approach to use when designing and building a distributed OpsMgr environment:While often people think a minimum network speed of 64Kbps between a single agent and a management server is required, this actually is not true; this is the minimum connection Microsoft supports for an agent. Average traffic on a single agent is 500 bytes per second (~4Kb/s).
    • Start with design. Begin with placement of your management group, including required SQL servers. Provision enough room for growth on the database servers and for additional management servers. When a LAN segment has only four IP addresses available, it is best to use another LAN segment. When running a virtualized OpsMgr management group, ensure the hosts are not overcommitted and the storage area network (SAN) is not configured for best capacity instead of best IOPS, as that will seriously hamper I/O performance.
    • Place the servers hosting the OpsMgr databases and SSRS with your management servers in the same LAN segment. This way traffic will flow quickly without routers between them, benefitting the overall performance and stability of your OpsMgr environment. This guarantees the highest bandwidth and lowest latency.
    • Ensure the location where your management group resides is connected by high-speed WAN links to the other geographical locations. You will want to have the best WAN connections available for your monitoring environment. Often you will end up placing the OpsMgr management group in the corporate data center.
    • For each geographical location, inventory what needs to be monitored. In addition to the total amount of servers or network devices, it is important to know the applications and services you will be monitoring. The more there is to monitor, such as business critical applications, websites, and .NET applications, the more network traffic is sent over the WAN connection to the management group.
  • Refrain from installing management servers outside the LAN segment where the management group resides even when wide WAN links are in place. This will eventually hamper the overall functionality, availability, and stability of the entire management group.
  • This was true with OpsMgr 2007, but is even more so in Operations Manager 2012, as the resource pools require very low latency because of heartbeat detection between management servers in any given resource pool. The management servers need to be close to or on the same segment as the databases. There are no exceptions to this design principle; when a particular geographical location is large enough for its own management server, you may want to consider providing a dedicated management group at that location.
  • Keep your Operations consoles under tight scrutiny. Too many concurrent console connections can affect the overall performance of the management group. In addition, when these consoles require updates or extensions, you know exactly which consoles to update rather than having people complain that console functionality is broken. You will want to keep the installation bits required for the console installation at a location with limited access.

Chapter 10: Security and Compliance

  • Securing Operations Manager includes utilizing role-based security, Run As profiles, Run As accounts, and understanding the various OpsMgr service accounts.
  • The Operations console includes access to more than 150 available operations, which fall under the following categories:Role-based access control utilizes Microsoft’s Windows Authorization Manager (AzMan) framework
    • Monitoring: These operations include opening views, resolving alerts, executing tasks, and overriding monitors. These views help you analyze monitoring needs.
    • Authoring: Authoring includes creating and modifying objects to customize or supplement the default monitoring settings provided by management packs.
    • Reporting: Reporting operations consist of using and designing reports and managing report security.
    • Administration: Administrative operations include configuring security, importing, exporting, and removing management packs, changing global settings, discovering computers and devices, configuring notification, and installing agents.
  • The OpsMgr store contains user roles and their scoping. The store for OpsMgr 2007’s implementation of AzMan was an XML file named MomAuth.xml; in OpsMgr 2012, the store is maintained across multiple AzMan tables in the operational database.
  • It is a Windows Communication Foundation (WCF)-based web service that all data access in Operations Manager passes through, and represents a single point of control for security authentication and authorization checks
  • The Data Access Service accesses the database over ADO.Net (with a default port of 1433) using the security context under which the service runs
  • Out of the box, Operations Manager provides the user roles and profiles listed in Table 10.1. Information on specific operations associated with each is available at http://technet.microsoft.com/en-us/library/hh872885.
  • You can add Active Directory (AD) security groups or individual accounts to any of the predefined user roles or to a role that you create
  • Should you create a user role based on the Author or Advanced Author profiles, be sure these users have access to an installation of the Operations console to perform the tasks allowed by those profiles.
  • The Administrators role differs from other user roles as you can only add Active Directory security groups to this role, not individual users. In addition, when you add a group to the Operations Manager Administrators user role, you must restart the management server to which you are connected for the change to take effect.
  • Similar to Windows file system security, when a user account is a member of multiple roles, access is the combination of what is granted to all those roles.
  • Creating a Report Operator Role: The Report Operator role grants the users belonging to that role the ability to run audit reports; however, the Operations console does not include the capability of creating this role, nor does the new PowerShell Set-SCOMUserRole cmdlet support creating the Report Operator role.
  • The good news is you can still load the OpsMgr 2007 PowerShell snap-in to use the workarounds previously developed for this. This line of code tells PowerShell to load the Microsoft.EnterpriseManagement.OperationsManager.Client snap-in, so the old commands will be recognized:System Center Operations Manager 2007 Unleashed (Sams, 2008) discussed using a script provided by Eugene Bykov of Microsoft to create a Report Operator role in OpsMgr 2007, modified by Neal Browne to be parameter-driven. As discussed at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/94404/Default.aspx, by incorporating the OpsMgr 2007 PowerShell snap-in and changing the script to be a function, you can continue to use the 2007 code rather than delving into .NET methods to create a script that would accomplish the same thing in OpsMgr 2012.
    • Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
  • Management pack components such as rules, monitors, tasks, and discoveries require credentials to run on the targeted computer. These components run using the credentials of the MSAA by default.
  • A Run As profile allows a management pack author to associate an identity other than the default action account with a particular module, letting it run using the credentials of that entity. The account used must have the Allow Logon Locally right.
  • OpsMgr 2012 automatically creates a number of Run As profiles during setup. Unless otherwise specified, the default action account is used by a Run As profile if another account is not assigned to that profile
  • Rather than assigning additional rights to an action account, using Run As accounts and Run As profiles provides the ability to run a task, rule, or monitor using an account with the necessary rights.
  • When OpsMgr tries to use that account, it will generate an alert if the account is not configured properly. As a best practice, verify the account exists and its credentials are adequate before using it as a Run As account. The authors also recommend using an account with a non-expiring password.
  • Required Accounts: System Center 2012 Operations Manager uses a number of service and action accounts. Here are some things to keep in mind regarding these accounts:Table 10.4. Service accounts required for OpsMgr 2012 installation
    • If you use domain accounts and your domain group policy object (GPO) allows passwords to expire, you must either change the passwords on the service accounts according to your password expiration policy, override the settings for these accounts so the passwords will not expire, or use low maintenance system accounts. Password information entered for accounts is stored, encrypted, in the operational database.
    • You may want to consider using built-in accounts where that is practical, as the operating system maintains these accounts and they are not affected by password expiration policies. In addition, the passwords to these accounts are not exposed.
  • The action account is granted write access to the operational and data warehouse databases. The MSAA needs at least the following privileges:Tip: Best Practices for the Management Server Action Account: Microsoft recommends using the same MSAA on all management servers, which should be a domain account rather than Local System, except when used in a lab or very small environment.
    • Member of the local Users group
    • Read access to the Windows event logs
    • Member of the Performance Monitor Users group
    • Granted the Allow Logon Locally right
  • Using a Low-Privileged Account on the Agent: For older operating systems such as Windows XP, the agent action account must have administrative rights to the system. For other operating systems, you usually can use a low-privileged account for the action account. This is the preferred approach, as you can use Run As profiles for anything requiring a higher level of access. When using a low-privileged account, the account must have the following minimum privileges:These are the lowest privileges OpsMgr supports for the action account. Other Run As accounts can have lower privileges.
    • Member of the local Users group
    • Member of the Performance Monitor Users group
    • Granted the Allow Logon Locally right
  • When you specify a domain account for the action account, you may need to add privileges to the account for various management packs to function properly. Table 10.5 lists these privileges.
  • Table 10.5. Permissions required for the action account
  • The actual privileges necessary for the action account and the Run As accounts vary, depending on the management packs running on the computer and how those are configured.
  • Each management pack has its own profile; rights and privileges for each profile are added together, giving the effective rights.
  • You cannot enable Agentless Exception Monitoring (AEM) on a management server with a low-privileged action account.
  • For systems running Windows XP, the action account must be a member of the local Administrators security group or run as Local System. The Local System account has high privilege levels on the local system as it is a member of the Administrators security group
  • Newer operating systems have additional built-in accounts. The built-in Network Service account has fewer access privileges than Local System, but the Network Service account is able to interact throughout the network with the credentials of the computer account.
  • the requirement to communicate with the management server prevents use of the Local Service account, as it has no rights to communicate outside the local computer. The Network Service account has that right.
  • Real World: Using Local System for the Default Action Account
  • Microsoft recommends using Local System as the default action account:Both the System Center Configuration Service and System Center Data Access Service use the System Center Configuration Service and System Center Data Access Service account to update information in the operational database
    • It provides the necessary rights to monitor a local machine.
    • It is secure and low maintenance.
    • Many management packs require using Local System.
  • You can run this as Local System or specify a domain user account that has local Administrator privileges; a local user account is not supported
  • If you install the operational database on a server other than the first management server and select Local System for this account, the computer account for the management server is assigned to the sdk_user role in the operational database
  • The account used by the Computer and Device Management Wizard for computer discovery is either the MSAA or an account with administrative privileges on the targeted computer(s).
  • As this account installs the agent on targeted computers, it must have local Administrator rights on all systems to which the agents are deployed.
  • The Data Warehouse Write account is used to insert and update information in the data warehouse database. This account writes data from the management servers to the data warehouse and reads data from the operational database. The credentials used for this account are assigned to the OpsMgrWriter role in the data warehouse database, and the dwsynch_users role in the operational database.
  • The Data Reader account runs and manages reports. The credentials used for this account are assigned to the OpsMgrReader role in the data warehouse database, and are added to the Operations Manager Report Security Administrators role. The Data Reader account becomes the identity for the Report Server application pool in IIS
  • The System Center Management service account must run using the credentials of Local System. This account registers SPNs (Service Principal Names); using credentials other than Local System results in duplicate SPNs. Microsoft does not support running the System Center Management service account under any credentials other than Local System
  • Gateway Action Account: If you install a gateway server, you must provide credentials for an action account. This actually is an MSAA for the gateway server. Gateway servers in remote domains (and workgroups) will need their own unique action account, which functions as a Run As account for that domain, and allows you to monitor other servers in that external domain such as a DMZ (demilitarized zone).
  • The gateway action account can run with the credentials of Local System or a domain/local account. It is a best practice to use a low-privilege account. Using a domain account enables the gateway servers to have the permissions required to install agents and perform necessary actions.
  • The authors recommend using SQL authentication for ACS rather than Windows security.
  • An agent and management server use Windows (Kerberos v5) or certificate authentication to mutually authenticate before the management server will accept data from the agent.
  • After mutual authentication occurs, the data channel between the agent and management server is encrypted.
  • OpsMgr does not support unencrypted communications.
  • As an alternative to installing certificates on each agent in a remote domain, you could use a gateway server as the communication mechanism between two domains
  • When monitoring an untrusted domain, only two certificates need to be installed and updated (on the gateway server and a management server).
  • The advantage of using a gateway is only one certificate is needed in the second domain (Continent) and one port (5723) opened through the firewall,
  • The information is decrypted by the gateway, re-encrypted by the certificate, and then encrypted using the dynamically generated key pair, which is a function of the health service.
  • When an agent is deployed, it automatically generates a public/private key pair, sending the public key to the management server. Any time the management server will send user credential information to the agent, it uses that public key for an additional layer of protection
  • Although agents in a workgroup environment can use a gateway server, you must install certificates for communication between the agents and the gateway server to provide a secure channel. These certificates are in addition to the certificate installed on the gateway itself to communicate with the management server.
  • If you have installed SSL on your reporting server, you must configure the Operations console to use SSL
  • If you use the Add or Deny options, you must restart the System Center Management service for the changes to take effect.
  • This service communicates with the monitored computer through a WSMan layer that is on both the management server and the monitored system. Installation of the WSMan layer is a prerequisite. Communication between the WSMan layers occurs over TCP port 1270, originating from the management server or gateway server.
  • You can use SSH to install the WSMan layer or perform diagnostics.
  • The UNIX/Linux Run As Account Wizard is used to create two types of Run As accounts:Tip: Using sudo Eliminates the Need for Root in UNIX/Linux Deployments: Using elevation lets an unprivileged account assume the identity of a privileged account on a UNIX/Linux system. The UNIX su (superuser) and sudo programs use the credentials the management server supplies to perform the elevation process. For privileged agent maintenance operations that use SSH (such as discovery, deployment, upgrades, uninstalls, and agent recovery), support for su, sudo elevation, and support for SSH key authentication (with or without passphrase) is provided. For privileged WS-Management operations (such as viewing secure log files), support for sudo elevation (without password) is added.
    • Agent maintenance account: This account establishes SSH connections to the monitored computers. This account, which must be a privileged account, performs actions such as upgrading, uninstalling, or restarting the UNIX/Linux agent.
    • Monitoring account: Use this for ongoing monitoring. You will want to create Run As accounts both for unprivileged and privileged monitoring.
    • UNIX/Linux Privileged Account: This profile will be associated with a privileged Run As account (root or similar), or an unprivileged account that has been configured with elevation via sudo. This is what a workflow will execute, as that requires elevated rights.
    • UNIX/Linux Agent Maintenance Account: Use a monitoring Run As account to this profile that has privileged credentials or credentials that are elevated.
    • UNIX/Linux Action Account: This is used by your basic monitoring workflows. Add a monitoring Run As account with unprivileged credentials to this profile.
  • However, you must enable sudo for the user and turn off the prompt for password. This is not a security issue if intended use of Run As credentials is observed. If the UNIX administrators enter the sudo-enabled Run As account credentials, the no prompt requirement is of less consequence. For information on configuring sudo, see http://social.technet.microsoft.com/wiki/contents/articles/7375.configuring-sudo-elevation-for-unix-and-linux-monitoring-with-system-center-2012-operations-manager.aspx.
  • Cross platform security requirements are also discussed at http://technet.microsoft.com/en-us/library/hh212926.aspx and http://technet.microsoft.com/en-us/library/hh212886.aspx. Scott Weisler has an excellent discussion of cross platform security and discovery recommendations at http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/94460/Default.aspx and http://opsmgrunleashed.wordpress.com/2012/07/07/cross-platform-discovery-settings/.
  • Table 10.6. Ports across a firewall
  • The authors recommend using the Group Policy Management Console (GPMC) to create and deploy an OpsMgr firewall exceptions GPO in the domain(s) where OpsMgr will manage computers
  • By deploying and using the ACS features of Operations Manager, the organization achieves a crucial capability—being able to prove it is secure in some valuable measurements of security. ACS provides evidence of how well your environment complies with specific security policies. A question that often arises, particularly from administrators that already have security solutions deployed, involves where ACS fits in a layered security approach. Table 10.7 shows how ACS compares to a conventional intrusion detection system (IDS).
  • Consider ACS for augmenting your existing, conventional intrusion detection systems. IDS and ACS serve different purposes, and in some scenarios, ACS provides more meaningful or actionable data than an IDS
  • ACS provides invaluable intelligence in auditing targeted resources, such as changes to privileged groups, and knowing of unauthorized attempts to connect to hidden file shares.
  • You must manage the expectations of ACS report consumers such as auditors or network security staff, and match those to architecture decisions, audit policies, and reports during the planning process
  • To get audit data into the ACS database, auditing must be enabled at the Windows operating system level on each ACS forwarder. This means that you first cause the security audit events to exist, and then deploy ACS to transport security audit events to the ACS collector and write them to the ACS audit database. By default Windows does not perform security auditing; you must explicitly turn this on for ACS to collect the data. You enable auditing through security policies
  • Table 10.8. Windows Server audit policies
  • The authors do not recommend creating custom GPOs with security policies unless absolutely necessary; it is best to work within the default (single) domain security policy to have consistency across the enterprise
  • There are nine categories of auditing available in the Local Policy -> Audit Policy section of all types of security policies (domain and local) as they appear in the GPMC
  • In addition to deploying the appropriate audit settings through domain group policy or local security policy, you should enforce minimum security log sizes for domain controllers and other computers
  • A recommended initial setting for domain controllers is 160MB, with 16MB for non-domain controllers
  • Here are five questions for you to answer when making ACS architecture decisions:
    • Will you host any of your databases on clustered SQL servers?
    • Will you implement a security partition between your OpsMgr environment and the audit database?
    • Will you integrate the ACS reporting feature with the OpsMgr reporting feature by sharing the same SQL Service Reporting Server, or will you install ACS reporting to a dedicated SSRS instance?
    • How many ACS collector/database pairs will you deploy in your management group(s)?
    • Will you use SQL Standard or Enterprise edition for your ACS database server(s)?
  • Here are some reasons to consider clustering the ACS database server:Consider installing ACS reports on a dedicated SSRS instance if the consumers of ACS data, such as a security team, would be better served with not having access to “too much data,” that being all the reports already installed in the OpsMgr management group.
    • Cost of downtime and possible emergency system restore costs.
    • Loss of ability to collect or analyze security events while replacing or performing extended maintenance on a failed SQL Server hosting the audit database.
    • Liability or service level agreement (SLA) failure for possible loss of safeguarded audit data.
  • good metric to get a handle on is the number of events per hour that you expect to be written to the audit database.
  • A moderately busy domain controller generates over 500,000 security events in a day (about 21,000 events per hour).
  • Assuming high-performance server and storage resources are provided, a single ACS collector can support a maximum of about 150 domain controllers or 3,000 member servers simultaneously.
  • The Enterprise edition of SQL Server is recommended because of the stress of daily ACS database maintenance.
  • The ACS collector communicates with the ACS database server using an ODBC data source of the System DSN type.
  • ACS installation itself does not create or require any security groups. The group you create will contain the user accounts of the individuals authorized to browse to the ACS reporting SSRS website and run on-demand ACS reports
  • If you deploy ACS reporting on the same SSRS instance as OpsMgr reporting, the same role-based security applies to all reports. This means that ACS reporting users must be assigned to the Operations Manager Report Operator Role to access the ACS reports.
  • USE OperationsManagerAC UPDATE dtConfig SET Value = <number of days to retain data + 1> WHERE Id = 11
  • Restart the Operations Manager Audit Collection Service on the ACS collector for this to take effect.
  • Tip: About the Audit and Audit5 Report Templates: You may notice two cryptically named report templates in the Audit Reports folder: Audit and Audit5. These templates are used when you create a custom report. The Audit template has room for up to 22 security audit event strings, while Audit5 has room for only five strings. Shorter events index faster, and since most security audit events have five or fewer description strings anyway, select the Audit5 template for new reports unless you know the security event will contain more than five strings.
  • The primary tool for administering ACS is a command-line tool, AdtAdmin.exe. The program folder for ACS is %SystemRoot%System32SecurityAdtServer on the ACS collector
  • Create Windows Management Instrumentation (WMI) queries that limit the events stored in the ACS database. (-GetQuery, -SetQuery)
  • AdtAdmin -SetQuery -query:”SELECT = FROM * FROM AdtsEvent WHERE NOT (HeaderUser=’SYSTEM’ OR HeaderUser=’LOCAL SERVICE’ or HeaderUser=’NETWORK SERVICE’)” creates a WMI query that will discard security events when the user account is the local computer account of the ACS forwarder. This is useful in a setting where you are interested in tracking only the activity of actual user accounts, and not machine accounts.
  • it may be necessary to modify the security on a registry key as shown in Figure 10.27. The registry key is HKLMSystemCurrentControlSetservicesAdtServerParameters. The Network Service account needs to have the Set Value, Allow permission granted to the Parameters key.
  • Tip: Redirect Adtadmin -Stats to a CSV File and Open in Excel: The -stats switch for the AdtAdmin.exe tool dumps all statistics about ACS database records. Redirect the output of the AdtAdmin -stats command to a text file (append “> <filename>.CSV” to the AdtAdmin.exe command line), and open it in Microsoft Excel as a comma-separated value (CSV) file. Viewed as a spreadsheet, each forwarder is listed in a row, with 17 columns of detailed data for each ACS forwarder. A value to watch is the Average time to collector(in ms) column, which is a measure of latency between when events occur on forwarders and when the collector writes them to the database. This value should be 2,000 milliseconds or less under normal conditions.
  • The capacity of a given ACS collector is finite, and the administrator of the ACS collector (the OpsMgr administrator) should keep an eye on collector performance. Three registry keys at HKLMSystemCurrentControlSetservicesAdtServerParameters can be tuned to help performance (see the keys in the upper portion of Figure 10.27). These keys work in conjunction with one another:A default collector queue, allowing 262,144 events of 512 bytes each, means about 134MB of memory is available for the queue.
    • BackoffThreshold: Default is 75%. New forwarder clients not connected above this threshold.
    • MaximumQueueLength: Default is 262,144 events. (This registry value must be created manually.)
    • DisconnectThreshold: Default is 90%. Active forwarders are disconnected until below this threshold.
  • OpsMgr performance charts and reports are based on 5-minute samples
  • Tip: Detailed Logging on ACS Forwarders: If you are experiencing a performance issue with a particular forwarder, you might find it useful to enable detailed logging on the forwarder temporarily. To do so, create a new DWORD value named TraceFlags with a decimal value of 524420 in the registry of the forwarder at HKLMSystemCurrentControlSetservicesAdtAgentParameters. After you create the registry key, restart the System Center Audit Forwarding Service (AdtAgent.exe) on the forwarder. A detailed log will be created at %SystemRoot%TempAdtAgent.log.
  • Preferred solutions are to reduce the volume of events, add resources to the collector feature, or increase performance of the SQL Server.
  • for best system performance, minimize the number of auditing entries for a given folder or file by using Windows groups to contain all the users and groups to be audited—then specify just that group on the Auditing tab.
  • Additional information on Operations Manager security is in the Operations Guide for System Center 2012 – Operations Manager at http://technet.microsoft.com/library/hh212887.aspx

Chapter 11: Dashboards, Trending, and Forecasting

Chapter 12: Backup and Recovery

  • For further details on Web Application Availability Monitoring synthetic transactions on these dashboards, see Marnix Wolf’s article at http://thoughtsonopsmgr.blogspot.com/2012/06/how-to-use-web-application-availability.html, and the OpsMgr product team’s article at http://blogs.technet.com/b/momteam/archive/2012/05/31/using-the-web-application-availability-monitoring-to-monitor-web-applications-health.aspx.
  • the Operations Manager team recently released a series of dashboards for OpsMgr 2012 to display Windows Server 2008 information, available at http://blogs.technet.com/b/momteam/archive/2012/06/12/free-windows-server-2008-dashboards-for-opsmgr-2012-and-tool-to-help-create-your-own-customized-dashboards.aspx. This download provides two prebuilt dashboards for Windows Server 2008 (the Windows Server Summary Dashboard and Windows Server Task Pane Dashboard), and includes a tool called GMTTool. The GMTTool incorporates three items you cannot do from the Operations console:
    • Removes management group GUIDs from dashboards so that dashboard management packs can be shared
    • Gives the ability to add dashboard views to any folder in the monitoring pane
    • Provides the ability to launch a custom dashboard from the Task pane
  • Kevin Holman’s blog: Kevin Holman gathered a series of useful Operations Manager 2007 queries that are available at http://blogs.technet.com/b/kevinholman/archive/2007/10/18/useful-operations-manager-2007-sql-queries.aspx.
  • http://blogs.catapultsystems.com/cfuller/archive/2010/08/04/quicktricks-creating-really-easy-multiple-server-performance-reports-amp-how-to-create-a-report-for-multiple-objects-when-you-don%E2%80%99t-know-what-objects-to-choose.aspx.
  • This management pack is available free from System Center Central in the management pack catalog (http://tinyurl.com/SCC-HealthCheck).
  • This management pack is available at no cost from Veeam and is available at http://www.veeam.com/extended-generic-report-library.html.
  • Community MP: Daniel Savage of Microsoft wrote a sample management pack that provides forecasting in OpsMgr 2007, available at http://blogs.technet.com/b/momteam/archive/2010/04/29/reporting-scenarios-more-samples.aspx.
  • OpsLogix has written a management that provides the ability to project trends and forecast capacity for OpsMgr.
  • Information on this management pack is available at http://www.opslogix.com/products/capacity-management-pack.
  • Top 10 Reporting Tricks: Windows IT Pro article by Cameron Fuller, available at http://www.windowsitpro.com/article/microsoft-system-center-operations-manager-2007/10-system-center-operations-manager-reporting-tips-140603
  • Operations Manager does not include a backup process out of the box.
  • There are also critical files you will want to secure through backup. This includes customized management packs, reports, the encryption keys utilized by SSRS, and the Internet Information Services (IIS) metabase
  • Operations Manager-specific user databases include the operational database, data warehouse database, and audit database used by ACS. Installing the SQL Server Reporting Component (required for the OpsMgr reporting feature) creates two additional databases: the ReportServer and ReportServerTempDB databases.
  • The operational database (named OperationsManager by default): This database is installed in every management group, and is the most important user database to back up
  • The data warehouse database (OperationsManagerDW by default): This database stores aggregated data used for reporting, used by SSRS for trend analysis and performance tracking. Based on the amount of data you are collecting and the degree of aggregation, this database may be large and thus require special handling
  • The SSRS ReportServer database: This database is used by SSRS
  • The ReportServerTempDB database: The only reason to back up this database is to avoid having to recreate it if there is a hardware failure
  • The audit database (named OperationsManagerAC by default): This database is associated with the Audit Collector service, which runs on the ACS collector
  • If you installed the operational, data warehouse, reporting, or audit databases on separate database servers or instances, each will have a Master database that should be backed up.
  • If you have installed the operational, data warehouse, reporting, or audit databases on separate database servers or instances, each will have an Msdb database that should be backed up.
  • The authors recommend separate backups of non-sealed/customized management packs, as this provides the granularity to import them directly into Operations Manager if necessary and to save a self-contained copy of any management pack customizations.
  • You could back up the server including the metabase, or redeploy the Web console server as part of your disaster recovery plan.
  • Custom files include the encryption key file for the reporting server.
  • Table 12.1. OpsMgr databases with recommended backup schedule
  • Table 12.2. Significant files with recommended backup schedule
  • Updates to the grooming settings are applied immediately. Once the data is groomed, it is not recoverable unless it was previously backed up.
  • Note: Active Alerts
  • Active alerts are never groomed. You must close an alert before it will be groomed.
  • The Operations console does not include a graphical interface for modifying data retention settings for the data warehouse
  • Table 12.3. Data warehouse datasets, types, and retention periods
  • Performance, Alert, Event, and AEM data is groomed every 240 minutes (4 hours); State data is groomed every hour.
  • Each time the stored procedure runs, it will groom a maximum of 100,000 rows
  • You can use the standarddatasetgroom stored procedure in the data warehouse database to manually trigger grooming
  • performance counters to keep in the data warehouse. The setting applies to hourly performance aggregations, which can take up a considerable amount of space.
  • Both parameters are set to 91 days by default. Select an existing unsealed management pack or create a new management pack to store your overrides in, and click OK.
  • You cannot configure daily performance aggregations, which default at 182. However, daily aggregations use considerably less disk space than hourly aggregations.
  • With OpsMgr, Microsoft designed the databases to be self-maintaining to a degree
  • SQL Server Enterprise Edition continues inserting processed security events but only at 30% to 40% of the regular insertion rate.
  • The ACS collector is configured to queue 262,144 events by default
  • Microsoft built reindexing into Operations Manager for the more significant tables in the operational database; the Optimize Index rule in the System Center Internal Library management pack executes the P_OptimizeIndexes stored procedure daily at 2:30 AM, which cannot be modified. This means you must ensure no other SQL maintenance jobs are running at 2:30 AM.
  • The operational database needs 50% free space at all times for growth and for re-index operations to be successful. An alert is generated when free space falls below 40%.
  • Autogrow is turned off for the operational database. It should not be turned on.
  • Autogrow is turned on for the data warehouse database. The authors recommend changing this from the default (percent) to a defined number, such as 500MB for the database file and 100MB for the transaction log.
  • OpsMgr does support log shipping for redundancy on the operational and data warehouse databases. If you want to implement log shipping, set the database to full recovery mode. The authors do not recommend this for the audit database, as it already has high processing requirements. If you are looking for fault tolerance, clustering is a less resource-intensive approach.
  • you can use SQL Server’s backup feature to back up the databases to (local or remote) file or local tape, and then back up the resulting files during your normal backup process
  • Always perform a complete backup rather than an incremental or differential backup of the operational database; by default, Operations Manager supports a simple recovery from a full backup only, not a forward recovery using the transaction log
  • Additional information on recovery models is available at http://msdn.microsoft.com/en-us/library/ms189275.aspx.
  • The operational, data warehouse, and audit databases should be backed up daily
  • For general processing efficiency, the authors recommend performing backups during a period when you do not expect a high volume of updates on the database you are backing up.
  • After restoring the database, restart the System Center Data Access Service and launch the Operations console. Open the Administration node to verify it has the correct rule groups and configuration. You can also launch the Monitoring node to confirm the agents are sending heartbeats. This validates OpsMgr is operational.
  • In addition, you really should restore both the operational and data warehouse databases at the same time, from a backup taken at the same time. This is because many items are synchronized to both databases; therefore restoring only one of the databases creates a situation where the two will be out of sync, which can create issues with availability reports.
  • Browse to HKLMSoftwareMicrosoftSystemCenter2010CommonDatabase, and update the string called DatabaseServerName to reflect the name of the new database server.
  • Browse to HKLMSoftwareMicrosoftMicrosoft Operations Manager3.0Setup, and update the DatabaseServerName string to the name of the new database server.
  • Edit %ProgramFiles%System Center 2012Operations ManagerServerConfigService.config. In the <Category> tab for Cmdb, change the value for ServerName to the name and instance of the new SQL Server.

Chapter 13: Administering Management Packs

  • Update the operational database with the new database server name and the location of the APM tables
  • Enable the Broker service. On the new database instance, open a Query window and execute this command:
    • SELECT is_broker_enabled FROM Sys.databases WHERE name=’OperationsManager’
  • If the result is a value of 0, run these commands:Browse to HKLMSoftwareMicrosoftMicrosoft Operations Manager3.0Setup, and update the DataWarehouseDBServerName string to the name of the new database server. Use the ComputerNameinstance format if using a named instance of SQL Server.
    • Enable CLR to allow assembly execution. On the new database instance, open a Query window and execute these commands:
    • sp_configure ‘show advanced options’, 1
    • reconfigure
    • sp_configure ‘clr enabled’, 1
    • reconfigure
  • On the system hosting the Audit Collection service, edit the registry key HKLMSoftwareODBCODBC.INIOpsMgrAC.
  • If you have issues with the SSRS database or have to move it, the best practice is to simply reinstall SSRS.
  • The authors suggest creating separate management packs to store overrides for each of the various sealed management packs loaded into OpsMgr.
  • For purposes of regularly scheduled jobs, the authors recommend you back up your unsealed management packs in a batch mode, using PowerShell cmdlets to export the management packs.
  • export management packs using the Export-SCOMManagementPack cmdlet.To keep things simple administratively, the authors recommend you package your reports in management packs.
    • $all_mps = Get-SCOMM…
    • $all_mps = Get-SCOMManagementPack where-object {_.Sealed -eq $false}
    • foreach($mp in $all_mps)
    • {
    • Export-SCOMManagementPack -ManagementPack $mp -path “C:Backups”
    • }
  • Microsoft does not support including ACS custom reports in management packs, as by default an OpsMgr administrator does not have access to ACS reporting. Customized ACS reports should be extracted using Report Builder and stored in a separate folder
  • You can use the RSKeyMgmt.exe utility to extract a copy of the encryption key from the ReportServer database. The utility writes the key to a file you specify and scrambles the key using a password you provide. This file should be backed up as part of your backup and recovery procedures. You should also document the password used for the file.
  • Backing Up the IIS Metabase
  • The IIS configuration on Windows 2008 R2 and Windows 2012 servers is split between the web.config files and the applicationHost.config
  • appcmd add backup <backupname>
  • You need to develop a detailed plan for the various contingencies, and practice the various scenarios in a development environment until you (and others on your staff in case you are hit by the proverbial truck) are comfortable with the process.
  • After the installation completes, immediately stop the three OpsMgr services on the management server to prevent the management server from sending data to the operational and data warehouse databases, as you will be overlaying these databases as part of your recovery process.
  • you will need the SSRS encryption key and other files discussed throughout this chapter for a successful recovery
  • you can recover a failed management server by running setup.exe with the /recover switch in a command prompt window. For syntax examples, see http://technet.microsoft.com/en-us/library/hh531578.aspx and http://technet.microsoft.com/en-us/library/hh531577.aspx.
  • One of the strengths of Operations Manager is its management packs are often produced by the same engineers who wrote the particular application or service
  • OpsMgr ships with more than 200 monitor types; these are predefined workflows that monitor for specific types of instrumentation.
  • Overrides can be applied at several levels:
    • Type: A type refers to the type of object being monitored. Examples of types would be all SQL Server databases, all Exchange mail servers, all DNS servers, and so on.
    • Group: A group is a subset of a type. For example, rather than monitoring all Exchange mail servers, you may want to apply the override to only the back-end mail servers in a particular domain, or the DNS servers in a branch office.
    • Object: An object would be a particular instance of a type (class). You may decide to apply an override to a particular database—perhaps the operational database, or a specific DNS server.
  • The authors suggest you create a separate MP for each workload (Exchange, SQL Server, DNS, and so on), to simplify managing overrides.
  • Use a naming convention that follows the management pack holding the original settings.
  • Alternatively, you could create separate management packs for overrides only and prepend “Overrides – ” to the management pack name, such as “Overrides – Exchange 2010,” as Pete Zerger discusses at http://www.systemcentercentral.com/tabid/145/indexId/73805/Default.aspx.
  • You can also find management pack guides at http://technet.microsoft.com/en-us/library/dd347500.aspx.
  • The Microsoft System Center Marketplace at http://systemcenter.pinpoint.microsoft.com includes management guides as well.

Chapter 14: Monitoring with System Center 2012 Operations Manager

Chapter 15: Monitoring .NET Applications

  • System Center 2012 Service Manager Unleashed (Sams, 2013).
  • Real World: Best Practices for Overrides
  • Microsoft provides recommendations and best practices when creating overrides. This guide is available at http://support.microsoft.com/kb/943239.
  • Other best practices for overrides include
  • The best practice recommendation is to create separate override management packs for each management pack.
  • Document each override and custom management pack created based on the rule and explain why it was created
  • Configure overrides for groups or classes instead of specific instances whenever possible.
  • Tip: Why You Should Create Custom Alert Resolutions States
  • Custom resolution states are often used to categorize alerts that are being worked on by different groups within an organization. As an example, there is often a requirement to create a resolution state for OpsMgr Admins, Database Admins, Web Admins, and such. You can use these resolution states in subscriptions, or to create views targeted to a resolution state.
  • For additional information, see http://blogs.catapultsystems.com/cfuller/archive/2011/04/15/opsmgr-never-close-an-alert-for-a-monitor-%E2%80%93-the-exception-to-the-%E2%80%9Crule-of-the-monitor%E2%80%9D.aspx.
  • The option in Configuration Manager 2012 does not put the agent into maintenance mode in Operations Manager 2012 but will pause the OpsMgr agent so alerts are not generated during the software deployment.
  • One of the side effects of using maintenance mode is that all monitors are reset to a healthy state.
  • The System Center Operations Manager 2007 R2 Admin Resource Kit includes the following resource kit tools (utilities and their descriptions are a subset of the text provided by Microsoft at http://blogs.technet.com/b/momteam/archive/2011/06/03/system-center-operations-manager-2007-r2-admin-reskit-released.aspx):
  • The System Center Operations Manager 2007 Tools and Utilities include the following resource kit tools (utilities and their descriptions are a subset of the text provided by Microsoft at http://technet.microsoft.com/en-us/systemcenter/bb625978.aspx):
  • System Center Operations Manager 2012 (OpsMgr) introduces the .NET application monitoring capability to enhance monitoring by collecting application performance information, including performance violations and failure details from ASP.NET and MVC applications, Windows Communication Foundation (WCF), and Web Services hosted on Internet Information Services (IIS) 7 and 7.5 (and IIS 8 in Service Pack 1).
  • Application performance monitoring is a discipline within systems management that focuses on monitoring and managing the performance and service availability of software applications.
  • does not require code changes and recompilations. It monitors application runtime behavior by watching all requests coming in and out and collecting statistical information as well as detailed reports of the failures and performance issues.
  • APM in OpsMgr 2012 supports monitoring applications running on the Microsoft .NET Framework 2.0 and later, hosted inside IIS 7 and IIS 7.5. This translates into ASP.NET, Web Services, WCF hosted inside IIS, and MVC applications. System Center 2012 Service Pack (SP) 1 adds support for discovery and monitoring of MVC applications, IIS 8, and Windows services built using Microsoft .NET 4.5.
  • APM agent components include a Windows service and application monitoring core. System Center Management APM is a Windows service and is installed as disabled by default
  • The application monitoring core is a set of DLLs automatically loaded inside your .NET application when you enable it for monitoring.
  • This is implemented by automatic injection of monitoring JavaScript code into your application’s response; the script then runs in the browser, collects all details, and then sends the data back to the APM agent. To be able to collect that client-side data, APM installs an additional IIS web application, CSMCollector, on each IIS website where your applications are hosted.
  • You are required to install the OpsMgr Web console, as the OpsMgr Web console feature contains the Application Diagnostic and Application Advisor consoles; these are must-have features of APM.
  • The only additional action required is installing the following management packs:
    • Windows Server Internet Information Services 7.0 management pack
    • Operations Manager Web APM IIS 7 management pack
  • If monitoring IIS 8 applications, install the IIS 8 applicable management packs.
  • The name should reflect your line of business (LOB) application name or a subset of that. The authors recommend defining a name based on the application components you plan to place into that logical application.
  • This could be front-end components of one application, or middle-tier application components, and naming the application group accordingly.
  • Create a new management pack for each application to keep application settings separate
  • You can also tag this configuration by selecting the Environment drop-down in Figure 15.5 and assigning it to Production, Staging, Test, Development, or giving it a custom tag. This is useful when you have multiple environments hosting the same application that should be managed separately and potentially have different application monitoring settings.
  • By default, exception alerts include only security and connectivity failures and not application failures. To change these and other settings requires additional configuration.
  • Thresholds defined for business logic components such as web services or WCF should be less than those for the front-end application components, as front-end components call business logic and run slower since they contain their own logic in addition to those calls.
  • You must recycle IIS services on the monitoring servers to start .NET performance monitoring
  • Additional Reading on APM Rules, Monitors, and Workflows
  • Here is some recommended additional reading on APM rules, monitors, and workflows:
  • The most critical settings for application monitoring are performance thresholds and namespaces, as they control when to report a problem and what data to include per each incident.
  • The Application Diagnostics console is designed to provide reporting capabilities for devops, developers, and debug engineers to investigate the root cause of the failures or performance problems. It is a web console and requires Internet Explorer.

Chapter 16: Network Monitoring

  • All firewalls between the management servers in the resource pool and the network devices need to allow SNMP (UDP) and ICMP bi-directionally, and ports 161 and 162 must be open bi-directionally
  • These limitations suggest monitoring no more than 1,000 network devices in a single resource pool, and up to 2,000 network devices per management group.
  • Each management server (or gateway server) is limited to a single network device discovery rule.
  • OpsMgr also implements the AES protocol for encryption
  • OpsMgr agents are not installed on the device in network monitoring. Instead, SNMP is used, where Get requests are sent to the device and responses are returned to the management server or gateway server in the resource pool.
  • Since OpsMgr only reads the MIB on the device for monitoring purposes, all network monitoring workflows targeted at the device require only one Run As account
  • Network monitoring in OpsMgr requires one of two types of Run As accounts:The community string Run As account type is always used for SNMP v1 and v2c devices, in which the only required input in the configuration is the plain text community string
    • Community String
    • SNMPv3 Account
  • Network device discovery is performed by manually created discovery rules
  • each management server or gateway server can run only one discovery rule, you should plan how to make this work best for your environment.
  • There are two types of network discovery methods: explicit and recursive
  • An explicit discovery rule attempts to discover only those devices that you explicitly specify in the wizard by IP address or fully qualified domain name (FQDN).
  • A recursive discovery rule attempts to discover those devices you explicitly specify in the wizard by IP address. It also attempts to discover other network devices connected to the devices specified in the discovery rule. IP addresses of these neighboring devices are gathered through the seed device’s Address Routing Protocol (ARP) table, its IP address table, or topology MIB.
  • Sometimes it is best to consult with your network team and add only the devices necessary to create the network topology connecting the systems you are monitoring with OpsMgr.
  • Microsoft recommends using recursive discovery only in smaller environments and that explicit discovery is used in large environments.
  • Note: Guidance on Filtering
  • Filtering can be an area of confusion. The best place to get guidance is in the Discovery Wizard, which includes a link for information on device filters.
  • Three stages occur when a management server processes a discovery rule: probing, processing, and post-processing
  • If ICMP and SNMP are used as the access mode, OpsMgr first pings the device using ICMP. If the device does not respond to the Echo request, probing ends without proceeding to the SNMP Get request and the device is not discovered.
  • By default, the probing stage uses SNMP v2c first. If the device does not respond within the configured retry attempts, the management server attempts again using SNMP v1.
  • Once probing determines the device is reachable, OpsMgr attempts to match the sysObjectId returned in the GetResponse message from the probing stage to a device defined in an oid2type_*.config file hosted on the management server. If OpsMgr finds a match, the device receives advanced monitoring features. Otherwise, only availability monitoring will run on the device.
  • At a minimum, the following information is necessary to create a network device discovery rule:
    • The IP address or FQDN of each device you want to include in an explicit discovery, or as seed devices in your recursive discovery.
    • The version of SNMP each device uses (SNMP v1, v2, or v3). Remember SNMP v3 devices must always be explicitly added to your discovery rule, whether it is explicit or recursive.
    • The SNMP community string of each SNMP v1 or v2 device you want to discover.
    • The user name for each SNMP v3 device you want to discover. Optionally, if you require authentication and privacy, the authentication protocol, authentication key, privacy protocol, and privacy key are also needed. Check your device configuration to know which setting to select in the Discovery Wizard.
    • The name of the network monitoring resource pool that will monitor the devices discovered.
  • Before creating a network device discover rule, ensure your firewalls are configured properly as discussed previously in the “Firewall Requirements” section.
  • Note that the server performing the discovery will not be the server that monitors those devices
  • By default, the discovery rule will run every Saturday at 2:00 am
  • Read more about SNMP v3 Run As accounts at http://technet.microsoft.com/en-us/library/hh212920.aspx.

Chapter 17: Using Synthetic Transactions

  • If the device is the starting point for recursive discovery (seed device), you must remove the device from the discovery rule or delete the discovery rule.
  • Port and interface monitoring is only available for those devices implementing the interface MIB (RFC 2863) and MIB-II (RFC 1213) standards
  • OpsMgr 2012 does not currently support discovering network devices from a server using IPv6.
  • OpsMgr 2012 incorporates a change to the base class for network devices that is incompatible with any custom OpsMgr 2007 R2 network monitoring management packs.
  • Power Consumption: This template is added as part of the Power Management Pack. This template is used to define a collection of PDUs and computers running Windows Server 2008 R2 or 2012 that receive power from the PDU. For more information on this template, see http://technet.microsoft.com/en-us/library/ee808918.aspx.
  • Watcher nodes allow you to specify the computer(s) that will launch the simulation. The only prerequisite is that the computer you want to run the simulation from has an installed OpsMgr agent
  • Tip: Using the Web Recorder
  • When using the web recorder, the authors recommend performing the recording from an administrator’s workstation rather than a management server
  • UAC challenges, 3rd party browser extensions, IE enhanced security: Kevin Holman discusses these topics at http://blogs.technet.com/b/kevinholman/archive/2009/06/19/web-application-recorder-r2-the-recorder-bar-missing-in-ie.aspx.
  • Recorder bar missing: Kevin Holman discusses this topic at http://blogs.technet.com/b/kevinholman/archive/2008/11/15/recording-a-web-application-browser-session-driving-you-crazy.aspx.

Chapter 18: Distributed Applications

  • GSM delivers the external view for web monitoring by providing an outside-in perspective on your synthetic web transactions. GSM allows you to use an Azure-based service to monitor your websites from geo-distributed locations around the world. For more information on GSM, see the Operations Manager team blog entry at http://blogs.technet.com/b/momteam/archive/2012/06/19/global-service-monitor-for-system-center-2012-observing-application-availability-from-an-outside-in-perspective.aspx.
  • Tip: When to Use Web Application Availability Versus Web Application Transaction—it’s about Scalability
  • The greatest benefit of web application availability monitoring versus web application transaction monitoring is scalability. Scalability is gained from using resource pools to provide automatic workflow load balancing, and by achieving high availability without alert duplication.
  • If you are using a large number of URLs, the authors highly recommend using web application availability monitoring as a replacement for web application transaction monitoring. Web application availability is also the recommended replacement for the Bulk URL Editor in OpsMgr 2007 R2.
  • More information on write actions and other components of the OpsMgr workflow is available at the AuthorMPs site at http://blogs.technet.com/b/authormps/ and Brian Wren’s TechNet blog site at http://blogs.technet.com/b/mpauthor/.
  • The OpsMgr community provides additional examples of how to query SQL and use the results in OpsMgr, including how to perform checks for a SQL full or differential backup and how to monitor the default management pack:The default interval to run the OLE DB data source query is every two minutes.
  • The OLEDB module defined within the System Library management pack supports an additional level of monitoring. This module allows you to configure custom queries to run against the monitored database, meaning not only can you verify that the database is online, but you can also verify that the database is responding to queries
  • Kevin Holman provides an example of monitoring a non-Microsoft database at http://blogs.technet.com/b/kevinholman/archive/2012/03/19/opsmgr-how-to-monitor-non-microsoft-sql-databases-in-scom-an-example-using-postgre-sql.aspx,
  • Maarten Damen provides an example of how to monitor an Oracle database with an OleDB watcher at http://www.maartendamen.com/2010/09/monitor-an-oracle-database-with-a-scom-oledb-watcher/.
  • you can monitor any database that supports OLE DB as long as the OLE DB driver is installed where required
  • Real World: Monitoring Oracle with the OpsLogix Management Pack
  • The Oracle Intelligent management pack by OpsLogix provides a template allowing users to create rules and monitors specifically aimed at Oracle environments
  • Additional information on OpsLogix and their management packs is available at the website at http://www.opslogix.com/products.
  • The OpsMgr DA represents your best bet to define what you really need to monitor for delivering your business-critical services
  • By identifying those classes of objects that are involved in delivering the application (and their relationships) and collecting sets of targeted views that focus on the service delivery of the application, knowledge is encapsulated, preserved, and made portable.
  • Tip: Install an Agent on Your Domain Controllers First
  • If you import the Active Directory management packs before installing OpsMgr agents on your domain controllers, the DCs appear as Not Monitored in the Computers global view in the Operations console. This occurs because the Active Directory Topology Root DA discovers the DCs in the management group’s domain and makes them objects in the management group. However, without OpsMgr agents, the DCs, now identified as objects, show up as unmonitored. To prevent this from occurring, install an OpsMgr agent on your DCs before importing the Active Directory management packs.
  • Objects discovered by the Information Worker management pack are listed at http://technet.microsoft.com/en-us/library/dd351478.aspx.)
  • Importing the Microsoft Information Worker management pack adds two DA templates to the Distributed Application Designer
  • If your organization depends on information workers accessing a web-based application for a critical business function, consider using the Internet Explorer Service template to author a DA modeling that web access.
  • The authors recommend monitoring an external web server through different outbound Internet service providers (ISPs). You should also consider monitoring an internal web server from watcher nodes at each branch office or outlying building
  • By default, the web query runs every 2 minutes.
  • You can find an example of using Visio integration with the Visio Add-in for Operations Manager (official name) at http://blogs.catapultsystems.com/cfuller/archive/2011/08/16/opsmgr-dashboard-integration-creating-a-visio-integrated-diagram-from-a-distributed-application.aspx.
  • While this is an older management pack, it provides excellent templates that can be used to demonstrate functionality useful to include within a distributed application.
  • The default interval to run the OLE DB data source query is every 2 minutes
  • Cameron Fuller’s blog posting at http://blogs.catapultsystems.com/cfuller/archive/2010/09/13/using-distributed-applications-to-generate-actionable-alerting.aspx.

Chapter 19: Client Monitoring

  • Real World: Using the SDK Versus a DA
  • If your organization is critically dependent on a complex custom application, sometimes known as a Line of Business (LOB) application, consider creating a health model programmatically using the SDK as a long-term solution.
  • when using the .NET Application Performance Monitoring management pack template, OpsMgr identifies .NET components in App Controller, Configuration Manager, Orchestrator, and Virtual Machine Manager that OpsMgr 2012 can monitor using application performance monitoring (APM) components.
  • The only constraint with the Blank template is you can only add objects to components matching the type (or class) for which the component was created.
  • Real World: Dynamic Distributed Applications
  • For distributed applications to be even more useful, they should be designed so they can dynamically adjust to changes in their membership
  • Implement this functionality in Operations Manager 2012 using a group with dynamic membership based upon a registry key on the system and embed this group into the design for the DA. This enables the DA to adapt as group membership changes. For further discussion on this topic, see http://blogs.catapultsystems.com/cfuller/archive/2011/11/28/opsmgr-dashboard-integration-server-health-creating-a-health-state-for-a-group-of-servers-in-a-dashboard.aspx.
  • OpsLogix has a free ping management pack that provides ping level monitoring for network devices (such as those not supported by the out-of-the-box network monitoring functionality in OpsMgr 2012
  • more information about MDOP DEM, see http://www.microsoft.com/en-us/windows/enterprise/products-and-technologies/mdop/default.aspx.
  • Implementing AEM involves just two steps: activating the AEM feature on an OpsMgr management server, and deploying a group policy object (GPO) with AD.
  • When you deploy AEM polices via a GPO, it configures registry keys on the client computer with values that change the behavior of Watson or WER.
  • The WER collection component is an HTTPS listener end point, by default on port 51906.
  • You will want to initiate the AEM feature of OpsMgr to detect application hangs and OS crashes on computers with or without OpsMgr agents
  • The selected management server must have at least 2GB free disk space and cannot have an existing file share named “AEM,” as this is created during AEM activation.
  • Tip: Install GPMC on the AEM Management Server
  • If your OpsMgr administrator account is also a domain administrator, save time by installing the Group Policy Management Console (GPMC) on the management server that will have AEM enabled. You will need to import, link, and edit domain group policy.
  • Enabling AEM on a management server by running the Configure Client Monitoring wizard also saves a group policy template with the .ADM file extension. The file name will be the FQDN of the management server;
  • Because there is only one AEM server per management group and since you want to include all computers in the domain, you will usually link the GPO at the root of the domain.
  • As the OpsMgr administrator, you may want to verify AEM is working and familiarize yourself with the console and reporting options available to view crash and hang information
  • Working with the AeDebug Registry Key
  • Installing other applications with debugging features such as Microsoft Visual Studio can modify the default debugger setting, resulting in a loss of AEM reporting functionality from that computer. To restore Watson as the default debugger and thereby enable AEM, you can run this .REG script on the Windows XP or 2003 computer (this does not apply to Windows Vista, Windows Server 2008, and later systems, which use WER and not drstsn32.exe):
  • Tip: File and Share Security on the AEM Server
  • The file shares created when enabling AEM on a management server have share permissions of EveryoneFull Control. Security is enforced at both the file and folder level. AEM setup creates two local computer security groups on the AEM server: AEMAgent and AEMUsers:
    • The AEMAgent group membership consists of the local Administrators group with Full Control file and folder permissions.
    • The AEMUsers group membership consists of all Authenticated Users—effectively all computer and user accounts in the domain—with special file and folder permissions.
  • These permissions allow error reports to be uploaded by client computers and processed by the management server. You should not need to modify these permissions.
  • The server processes collect reports on a timed basis—it can take up to two minutes from the moment the client transmits the error report until you see the error reflected in the console
  • Incorporating Surveys
  • Consider employing a web-based survey technique to help solve particular errors in custom applications. You can stage a short automatic interview with the end user to gather targeted information. Here are some sample questions that might be helpful for a survey:
    • What other applications (besides the one that crashed) were you running at the time of the crash?
    • What steps can the IT department take to reproduce the crash that occurred?
    • Will the application crash consistently if you follow the preceding steps? (Yes, Sometimes, or Never)
    • Are you running any macros, COM add-ins, or templates?
    • Does the crash occur for other people who log in to this computer? (Yes, No, or Unknown)

 

Chapter 20: Interoperability and Cross Platform

  • Tip: Community Resources on OpsMgr Reporting
  • For ideas on how to make OpsMgr reports more useful in customer environments, consult these community resources:The transmission uses outbound TCP port 51907
  • you can have your clients send their CEIP data to the AEM server as a central collection point for the organization
  • You must install the OpsMgr reporting feature for ODR to function
  • The authors recommend Operations Manager administrators enable some or all of the Microsoft forwarding features, particularly those that apply to OpsMgr itself.
  • There is also a specific Microsoft System Center Operations Manager 2012 Privacy Statement at http://technet.microsoft.com/library/hh321008.aspx. The specific OpsMgr privacy statement includes sections that address the privacy issues of each component described in this chapter, including CEIP, ODR, and WER.
  • A single-server OpsMgr management group can easily handle 50 client computers; however, somewhere on the road toward and above 500 computers, a single management server will begin to slow down.
  • deploying an agent to any computer incurs acquisition costs for the agent license, an incremental cost of resources consumed in the Operations Manager management group, and an ongoing cost to support the agent in terms of licensing, maintaining, and upgrading.
  • The authors recommend selecting at least one client computer at each branch or remote office for Business Critical Monitoring. You generally want to know if these computers go offline—you monitor them like servers for high availability.
  • This is a random, proportional sampling of client computers within each client population
  • You can easily deploy multiple, smart sets of watcher nodes to measure the end-to-end service delivery of distributed enterprise applications.
  • Very large environments should consider a dedicated management group for AEM. The guidelines at http://technet.microsoft.com/en-us/library/bb735402.aspx apply to AEM for OpsMgr 2007 and OpsMgr 2012.
  • the Business Critical management pack allows for individual alerting.
  • Note: About the Information Worker Management Pack
  • There is a legacy information worker management pack available in the online catalog. This management pack includes monitoring of Office 2003 and Office 2007 applications. Microsoft has deprecated the Microsoft Information Worker management pack, and no further management packs for Office applications will be delivered.
  • reports built on aggregated data require at least 24 hours of collection. Many of these reports are designed to trend data over large time-frames, such as three to six months, so there may not be much useful data for several weeks after installing the Client Monitoring management packs.
  • You can only bring client computers into Business Critical Monitoring after discovery takes place and the clients have an agent installed on them
  • some monitors that are data-processing intensive are turned off, even for Business Critical Monitoring. It is up to you to identify any Advanced Monitoring features you need and enable them on a case-by-case basis.
  • An example of Advanced Monitoring is the Network Adapter state and performance views
  • You cannot select client computers to be watcher nodes for your distributed applications unless you have deployed an OpsMgr agent to them.
  • The authors recommend all client computers selected as distributed application watcher nodes also are subject to Business Critical Monitoring
  • enables you not only to monitor UNIX and Linux platforms using OpsMgr, but application workloads on non-Windows operating systems, such as Java enterprise applications, sometimes known as JEE.
  • Cross platform security has been enhanced as well with the introduction of sudo functionality, which eliminates the need for root credentials.
  • For those platforms not supported by the OpsMgr 2012 release, Microsoft has published the Cross Platform Providers on CodePlex (http://scx.codeplex.com) as open source (MS-PL license).
  • Microsoft support for UNIX and Linux versions is aligned to the vendors’ support rather than an N-1 strategy. New versions of operating systems are supported within 180 days of release. Old versions are supported as long as the vendor provides support for that version.
  • Import the following MP files to enable monitoring of the new Linux operating systems:
    • Microsoft.Linux.Universal.Library.mp
    • Microsoft.Linux.Universal.Monitoring.mp
    • Microsoft.Linux.UniversalD.1.mpb (to support Debian and Ubuntu Linux agents)
    • Microsoft.Linux.UniversalR.1.mpb (to support CentOS Linux agents)
  • For additional information, see http://technet.microsoft.com/en-us/library/jj656654.aspx.
  • Detailed cross platform OS monitoring capabilities in OpsMgr 2012 include
    • CPU monitoring
    • Disk monitoring
    • Logical disk (file system)
    • Physical disk
    • Log file monitoring
    • Memory/swap monitoring
    • Network adapter monitoring
    • Process monitoring
  • In addition to the cross platform monitoring features carried forward from OpsMgr 2007 R2, there are several new features in OpsMgr 2012, including
    • File system nodes monitoring
    • “Three state” file system free space monitors
    • All new reports
    • All new MP knowledge
    • Java Enterprise Edition (JEE) application performance monitoring
  • The cross platform agent, which leverages OpenPegasus and supports the Distributed Management Task Force (DMTF) and Common Information Model (CIM), operates much differently.
  • In this architecture, the agent is a listening agent that is called by a management server to collect performance and availability data. This means the cross platform agent is a lightweight; there is less code and less processing on UNIX/Linux systems than the Windows equivalent.
  • Cross platform operating systems are discovered via SSHD (the standard secure shell daemon), and monitoring data is collected by management servers using the WSMan protocol, implemented via Windows Remote Management (WinRM) on the management server
  • For detailed instructions in configuring certificates across the resource pool for high availability UNIX/Linux monitoring, see http://technet.microsoft.com/en-us/library/hh287152.aspx.
  • It is important to note sudo must be enabled with no password required in order for privilege elevation to function as designed
  • Kerberos authentication is not possible when deploying agents to UNIX- or Linux-based computers, so certificates are used between the management server and these systems
  • Certificates are not automatically deleted when you uninstall an agent; you must manually delete the certificates that are listed in the /etc/opt/microsoft/scx/ssl folder. To regenerate the certificates at install, you must remove this folder before agent installation.
  • If you have a firewall on your UNIX- or Linux-based computer, you must open port 1270 (inbound). This port number is not configurable. If you are deploying agents in a low security environment and use the Discovery Wizard to deploy and sign the certificates, you must open the SSH port. The SSH port number is configurable. By default, SSH uses inbound TCP port 22.
  • Each of the systems you want to discover with OpsMgr must be able to resolve their Internet Protocol (IP) address to their host name
  • Discovering and deploying the cross platform agent requires a username and password for those systems to which you are deploying the agent
  • The root account typically does not have access rights to log in via Secure Shell (SSH), which is the approach OpsMgr uses to deploy the agent. The cross platform agent installation executes the scripts using the sudo command (The “Notes on UNIX Commands” section includes details on this command) as part of the installation process.
  • Before OpsMgr can discover any UNIX/Linux systems, WinRM must be configured to allow basic authentication.
  • There are three accounts you must define as part of the cross platform functionality:
    • Linux Unprivileged Monitoring Account: A monitoring Run As account for unprivileged monitoring
    • Linux Privileged Monitoring Account: A monitoring Run As account for privileged monitoring
    • Linux Agent Maintenance Account: An agent maintenance Run As account for upgrading, uninstalling, and other agent maintenance operations
  • the Distribution Security page, define whether these credentials will be stored in a less- or more-secure configuration, as shown in Figure 20.7:
    • More secure: With the more-secure approach, you select the computers that will receive the credentials.
    • Less secure: With the less-secure option, the credentials are sent automatically to all managed computers.
  • The more-secure approach is strongly recommended, targeting the Cross Platform Resource Group for distribution.
  • You can also download the latest version of the cross platform MPs from the Microsoft website at http://www.microsoft.com/en-us/download/details.aspx?id=29696.
  • You now have prepared to discover the UNIX/Linux systems. You have worked through name resolution, gathered account information from the UNIX/Linux systems, updated WinRM, configured accounts and profiles, and imported the UNIX/Linux management packs.
  • Another option is to reissue the certificate and restart the cross platform agent, discussed at http://technet.microsoft.com/en-us/library/dd891009.aspx.
  • Tip: Using a Dedicated Management Pack
  • The authors suggest using a dedicated management pack for the output of the UNIX and Linux monitoring templates.
  • If you require deeper monitoring, Microsoft offers a Java Management Extension (JMX) application called BeanSpy (known during the OpsMgr 2012 beta period as the JMX Extender) that you load on the Java application server.
  • Information collected from the application server instances includesThe application developer must choose to create custom MBeans and populate them with relevant statistics as the application runs.
    • Applications deployed in the application server
    • Number of garbage collections per second
    • Time spent in garbage collection
    • JVM memory usage and capacity
    • Number of class loaded in the JVM
    • Number of active threads
  • Before deep JEE application monitoring can begin, you must install and configure BeanSpy on the target Java application server
  • OpsMgr requires that you specify the FQDN, instead of the host name or localhost, in the CN field of the Java application server certificate.
  • Security Roles Required by BeanSpy
  • You can find the security roles required for accessing and invoking methods in BeanSpy in the web.xml file (see Figure 20.48) located in the <Tomcat_Install_Directory>webappsBeanSpyWEB-INF directory on any Java server where BeanSpy is installed. The security roles are defined in this file between the <security-role></security-role> tags. The roles for BeanSpy are the JEE monitoring and JEE invoke roles. You must define a user account with membership in these roles in the Java server installation and provide it to OpsMgr in Run As accounts associated with the appropriate Run As profiles.
  • Real World: Avoid Mixed Case User Names
  • While most JEE platforms (including Tomcat 7.x, used in this chapter’s examples) support mixed case user names, OpsMgr does not seem to handle them well. A user name of OpsMgrJEE resulted in authentication failures. Switching the username to opsmgrjee (in both the tomcat-users.xml and Tomcat JEE Run As account) resolved the issue.
  • the JEE management packs for OpsMgr 2012 are not available in the catalog; you must download them from http://www.microsoft.com/en-us/download/details.aspx?id=29270.
  • Here are the management packs you should import to support all platforms:
    • Microsoft.JEE.Library.mpb
    • Microsoft.JEE.Templates.Library.mpb
    • Microsoft.JEE.Templates.Library.xml
  • If your Java applications run as Windows services, discovery will fail and manual discovery is necessary. Manual discovery requires running a PowerShell script to add the Java application servers to OpsMgr manually.
  • For more information on the manual discovery process, see Christopher Crammond’s article at http://blogs.technet.com/b/random_happy_dev_thoughts/archive/2012/05/21/manually-discovering-jee-application-servers-with-scom-2012.aspx.
  • You can use telnet to verify ssh connectivity to the UNIX/Linux system on port 22

Chapter 21: System Center 2012 Integration

  • For the System Center Operations Manager Configuration Item (CI) Connector to work as expected, you must first import a set of management packs into Service Manager
  • Before configuring the OpsMgr CI connector, you must first import the appropriate OpsMgr library management packs (MPs). The steps for importing management packs for OpsMgr CI connectors into Service Manager are discussed at http://technet.microsoft.com/en-us/library/hh519707.aspx.
  • Note: Security for the Connector Role To ensure full functionality of the connector, the account supplied should be a member of the Operations Manager Operators user role.
  • See the “Accounts Required During Setup” section in the Planning Guide for System Center 2012 – Service Manager at http://technet.microsoft.com/en-us/library/hh495542.aspx, also available for download at http://www.microsoft.com/en-us/download/details.aspx?id=27850.
  • Tip: Recommendations on Alert Closure In testing, the authors discovered that if you select the Close alerts in Operations Manager when incidents are resolved or closed option on the Create a Schedule page in the OpsMgr Alert Connector Wizard, analysts could close alerts in OpsMgr that should remain open because the root cause of the alert has not been resolved.
  • This generally does no real harm with rule-based alerts, as rules will simply raise another alert if necessary. However, when you close an alert for a monitor, the result is a monitor that remains in an error state without an associated open alert. This becomes a blind spot, as the monitor will never raise another alert until it has transitioned back to a healthy state and then back to an error state again. To avoid this risk, you could opt to only check the box labeled Resolve incidents automatically when the alerts in Operations Manager are closed,
  • Real World: Use of Alert Resolution State for Sending to a Connector A strategy the authors have found effective is to use alert resolution state as the sole criteria. Using custom resolution states enables granular control over which alerts are forwarded to Service Manager with relative ease.
  • Since you are configuring OpsMgr integration with VMM, it is assumed you have deployed an OpsMgr agent to the VMM 2012 Server, all Hyper-V hosts, and VM guests.
  • You need to install the System Center consoles to facilitate SDK access:
  • Integrated Maintenance Mode (Hyper-V Host and Host Cluster Patching) When you patch a Hyper-V host cluster (described at http://technet.microsoft.com/en-us/library/gg675088.aspx), VMM contacts OpsMgr 2012 using an internal connector created when you configure VMM/OpsMgr integration and places the Hyper-V host in maintenance mode in Operations Manager while it is out of service and being updated. When patching is complete and the host is returned to service, VMM contacts OpsMgr to end maintenance mode for the Hyper-V host.
  • This is required for the forecasting reports in the OpsMgr VMM 2012 management pack to be functional, and requires SSAS Analysis Management Objects (AMO) be installed on the Operations Manager reporting server
  • Enter the SSAS server, SSAS instance, and SSAS port: The instance name must be the same as the SQL Server Reporting Services (SSRS) instance, which is MSSQLSERVER by default.
  • Several hours after configuring SSAS integration in VMM 2012, the forecasting reports in the VMM 2012 Management Pack for OpsMgr 2012 should be functional.
  • The Disable Operations Manager alerts while software updates run option triggers the ConfigMgr client to pause the OpsMgr agent during maintenance mode.
  • The authors do not recommend using this option; it is better to use scheduled maintenance mode scripts with OpsMgr instead
  • The authors suggest that in most cases, using the reporting capabilities of ConfigMgr to identify failed updates would suffice, making OpsMgr alerts on the condition unimportant.
  • Number of community resources are available to help you get started, including these tutorials, available at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/92651/Default.aspx:
  • Install the System Center Operations Manager console on each computer where a runbook server or runbook designer is installed that will interact with System Center Operations Manager.
  • The third-party connectors available in OpsMgr 2007 R2 (at substantial additional cost in their original incarnation) have been replaced by integration packs in Orchestrator 2012 designed to support forwarding alerts to a number of third-party monitoring systems.
  • OpsMgr with the VMM 2012 Management Pack is the best tool for monitoring not only resource performance and utilization in your Microsoft private cloud environment, but capacity as well

Chapter 22: Authoring Management Packs and Reports

  • Before writing a management pack, you should understand the concept of the health model
  • To make full usage of the health model in OpsMgr, you should be aware of the different types of monitors
  • Aggregate monitors are only used to roll up health; they do not monitor components by themselves
  • Once you understand authoring concepts, the next step is gathering information about the application or device you want to monitor. This step is the most crucial in the entire process
  • This means you should start by gathering monitoring requirements and designing a model before beginning to write the actual management pack.
  • you need to identify the monitoring requirements of an application or service. This means being able to identify requirements and map them to the OpsMgr health model.
  • pinpoint the exact components crucial to the application
  • You cannot monitor a component for problems if it is not creating or logging events that you can check.
  • For each component in your Visio diagrams, ask whether the component is significant and whether it requires monitoring. If so, what can be checked to monitor the component—services, processes, performance, or events?
  • Here are examples of questions you could ask:Information must be usable to be valuable, or the result is a repository of all events ocurring in your environment.
    • How does the application run?
    • What does the end user expect to occur with the application?
    • What services are running for the component?
    • Are processes involved?
    • Do you know of performance counters that could be of interest?
    • How does the application perform logging? Does it log errors, or only informational events?
    • Does the application currently log events in the Windows event logs?
    • How can you tell the application is failing or know when it is about to fail?
    • Have you experienced any significant outages for the application recently? Could these be detected, or avoided?
    • How do you think the application can be monitored effectively?
  • Verify the components in your Visio diagram are discoverable. This can be difficult for inexperienced authors. You must be able to discover the class and its relationship
  • Before writing the management packs used in the examples, you must first install Visio 2010 Premium Service Pack (SP) 1 and/or Visual Studio 2010; then install the extensions.
  • The System Center 2012 Visio MP Designer is available at http://www.microsoft.com/en-us/download/details.aspx?id=30170.
  • Download the System Center 2012 Visual Studio Authoring Extensions from http://www.microsoft.com/en-us/download/details.aspx?id=30169.
  • Caution: Connector Mode Default
  • The connector mode, listed in Table 22.1, is set to true by default, which means the tool will generate a connector management pack. Change this to false, since you want to generate a monitoring management pack.
  • For a full pattern overview, see the TechNet wiki at http://social.technet.microsoft.com/wiki/contents/articles/6939.pattern-reference-for-visio-management-pack-designer.aspx.
  • the Authoring guide at http://technet.microsoft.com/en-us/library/hh457564.aspx)
  • best practice is including a description with a meaningful name so the operator understands what he is looking at.
  • Visio Studio can automatically seal your management pack after you create a key file.
  • It is a best practice to seal those management packs containing classes, as a management pack must be sealed to reuse its classes in other management packs.
  • Before sealing the management pack, you must create a key file. Jonathan Almquist documents the process for creating a key file at http://blogs.technet.com/b/jonathanalmquist/archive/2008/08/19/seal-a-management-pack.aspx.
  • Creating a key file requires sn.exe, part of the .NET Framework SDK downloadable at http://www.microsoft.com/en-us/download/details.aspx?id=19988. After obtaining sn.exe, run this command to create the key file Unleashedkey.snk, which you can use to seal MPs:
    • sn.exe -k D:MPkeyUnleashedkey.snk
  • The project creates unsealed and sealed versions of your management pack in the location of your project
  • Registry discoveries have the lowest performance impact; the authors recommend checking the registry first for application-specific parameters to identify your application when writing a discovery rule
  • The authors recommend being as precise as possible when targeting a discovery.
  • For a complete overview on the settings and configuration references for the Visio MP Designer, see the TechNet Wiki page at http://social.technet.microsoft.com/wiki/contents/articles/6938.monitoring-and-modeling-shape-reference-for-visio-management-pack-designer.aspx.
  • Find a complete list of alert description variables in Kevin Holman’s blog at http://blogs.technet.com/b/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx.
  • Be sure you understand how property bags work, as they are a powerful tool to change regular scripts into OpsMgr-compatible scripts. You only need several lines of code to make the script OpsMgr-aware
  • For further reading on property bags and scripting in OpsMgr, refer toRules are primarily used for data collection or alerting only
  • To seal a Visio created management pack, refer to http://technet.microsoft.com/en-us/library/hh457550.
  • To test the Windows event monitors, use the EventCreate tool, which is part of Windows.
  • Building reports with Report Builder by Stefan Koell: http://www.code4ward.net/main/Blog/tabid/70/EntryId/81/How-to-use-Report-Builder-to-create-custom-reports-in-SCOM-2007.aspxA big issue with custom reporting in OpsMgr is using the correct class and performance rules and targeting the reports. To target your reports correctly you must identify the target class and the performance collection rule.
  • The easiest way to determine the correct target is to open the performance view and look at the different performance rules
  • Tip: Targeting in Reports
  • The most difficult part about reporting is defining the correct target and performance rule. Use the Monitoring pane to verify you have the correct information. Navigate to the performance view containing the rule you want to report on, select the properties of the rule to determine the target class, and note the performance rule name. With the target class and rule identified, you can create any report.
  • Another more advanced option is writing reports based on groups. Be sure you are targeting properly. If the performance counters are targeted at the logical disk and you want to create a group, only add logical disks in this group and target your report on this group for free disk space.
  • The advantage to groups is they can be populated dynamically, so you only have to create a single report. If a new instance is added, the dynamic population rule automatically adds the instance to the group. The only downside is you generate the report based on the overall performance of the group and have to run a child report to get the information per instance.
  • This information is also is described in the article at http://www.bictt.com/blogs/bictt.php/2010/11/28/scom-reports-on-performance-counters-for-large-groups-of-servers.

Chapter 23: PowerShell and Operations Manager

  • Use a self-signed certificate, using the .NET Framework 2.0 software development kit (SDK) to create the certificate
  • Here are two great resources that discuss using Microsoft’s certificate creation tool, makecert.exe, to generate certificates to create self-signed PowerShell scripts:
  • If you have an existing PKI infrastructure that can be utilized to generate a certificate, there is a great two-part series on signing PowerShell scripts with an enterprise PKI from the Microsoft Scripting Guys, http://blogs.technet.com/b/heyscriptingguy/archive/2010/06/16/hey-scripting-guy-how-can-i-sign-windows-powershell-scripts-with-an-enterprise-windows-pki-part-1-of-2.aspx and http://blogs.technet.com/b/heyscriptingguy/archive/2010/06/17/hey-scripting-guy-how-can-i-sign-windows-powershell-scripts-with-an-enterprise-windows-pki-part-2-of-2.aspx.
  • Tip: More Information on the Pipeline
  • A discussion about the PowerShell pipeline is beyond the scope of this chapter. For more information about the pipeline, PowerShell MVP Don Jones provides several resources:
  • Two common uses of variables are to store information that will be later utilized within a script and to store information that is a result of running a script.
  • You can also read more about variables in the tutorial at http://www.powershellpro.com/powershell-tutorial-introduction/variables-arrays-hashes/.
  • Tip: $True and $False
  • To get the full story on Boolean values and operators see Jeffrey Snover’s blog post at http://blogs.msdn.com/b/powershell/archive/2006/12/24/boolean-values-and-operators.aspx.
  • An example of computer discovery and push install of the agent through PowerShell is demonstrated in greater depth in the posting on automating agent discovery and deployment with PowerShell at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/94248/Default.aspx.
  • The performance difference is due to that when the criteria parameter is used, the value passed is provided directly to the SQL Server database, and only the relevant data is returned. This means the data is filtered before it is returned to the PowerShell session, reducing the number of objects that must be passed back to the Windows PowerShell console.
  • Tip: Collection of OpsMgr 2007 Single Line Examples in OpsMgr 2012
  • For examples of OpsMgr2007 PowerShell examples migrated to OpsMgr 2012, see the collection of updated single line PowerShell scripts (one-liners) at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/89870/Default.aspx.
  • Three resource pools are created by default: AD Assignment Resource Pool, All Management Servers Resource Pool, and Notifications Resource Pool. The memberships of these three groups are set to automatic, meaning any management server added to the environment takes part in these resource pools.
  • Backing Up Unsealed Management Packs Nightly
  • Part of a comprehensive backup strategy for OpsMgr would include backing up unsealed management packs on a nightly basis to the file system
  • This is to ensure changes made to the OpsMgr environment, such as overrides, custom rules, and monitors, are captured and backed up. Chapter 12 includes a nice script that does just this job using the OpsMgr cmdlet Export-SCOMManagementPack.
  • With a bit of effort, you can update agent failover settings in bulk as described in the article on updating agent failover settings from a spreadsheet with PowerShell at http://www.systemcentercentral.com/tabid/143/indexid/95393/default.aspx.
  • Fortunately, with the OpsMgr Shell, you can easily balance the agent load across multiple management servers. The sample script referenced in this section evenly distributes agents across two or more management servers. Running this script as part of a schedule task can ensure the agent load is balanced as your environment grows and evolves.
  • While it is relatively easy to balance agents across two management servers with PowerShell, the script logic becomes significantly more complex when you need to support 2–N management servers. Fortunately, that did not bother Andreas Zuckerhut, who routinely writes PowerShell-based automation solutions for OpsMgr that rate at the high end of the complexity scale. You can find a copy of this community-developed solution in the OpsMgr by Example series at http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/96292/Default.aspx.
  • The following is a list of considerations and preparatory tasks to ensure your Orchestrator runbook server can successfully run OpsMgr Shell scripts:
    • Enable script execution for the 32-bit PowerShell instance on the Orchestrator runbook server. While your runbook server is running 64-bit Windows Server 2008 R2 or 2012 (with System Center 2012 SP 1), Orchestrator is still a 32-bit application, and as such, always launches a 32-bit PowerShell instance.
  • For details on how to set PowerShell script execution policy, see the “PowerShell Execution Policy” section.
    • Install the OpsMgr Operations console on your runbook servers. Without the OpsMgr Shell present on the runbook server, OpsMgr PowerShell scripts will fail every time.
    • Configure a connection to your OpsMgr management group(s) in the Global Configuration area of the Orchestrator Runbook Designer, available on the Tools -> Options menu. To ensure all scripts have adequate permissions contained within runbooks, you will need to provide an account with OpsMgr administrator privileges. For details on how to configure OpsMgr connectivity from Orchestrator, refer to Chapter 21.
  • You will find detailed examples of Orchestrator runbooks interacting with OpsMgr via PowerShell in System Center 2012 Orchestrator Unleashed (http://www.amazon.com/System-Center-2012-Orchestrator-Unleashed/dp/0672336103, Sams, 2013).

Chapter 24: Operations Manager for the Service Provider

  • The maximum number of supported agents per management group is somewhere between 6,000 and 15,000, depending on factors such as the number of management packs and connected consoles.
  • Remembering no single management server should exceed 3,000 downstream agents even when one management server has failed.
  • The limitation comes from the quantity of manageable records in a data warehouse database, which is about 15,000
  • Specifically, the total number of managed objects in all connected management groups cannot exceed 15,000 using a shared data warehouse database.
  • Self-renewal features and require little administrative work for up to 20 years, the maximum recommended lifetime of a root certificate.
  • The OpsMgr authentication certificate generally has a lifetime of two years.

Appendix A: OpsMgr by Example: Configuring and Tuning Management Packs

Appendix B: Performance Counters

  • NONE

Appendix C: Registry Settings

  • NONE

Appendix D: Reference URLs

Appendix E: Available Online

  • NONE

—————————————————————

Don’t forget to check out the following:

CANITPro: Did you know there is a site dedicated to Canadian IT professionals? You can win a 3D movie prize package by upgrading your IT skills with Microsoft. Check out CANITPRO At The Movies, either in English: CANITPro At The Movies or French: CANITPro At The Movies

Azure: Sign up for a FREE trial and get $200 to spend on Microsoft Azure cloud computing services. Full access, no strings.

MSDN: Ever wanted to work with the latest Microsoft technologies, without having to spend thousands of dollars? Now you can, with the MSDN subscription

One thought on “Book Review: SAMS System Center 2012 Operations Manager

Share Your Thoughts

%d bloggers like this: