Historical walkthrough for a single-server System Center 2012 Operations Manager deployment on Windows Server 2008 R2, covering prerequisites, service accounts, SQL choices, agent connectivity, and the post-install tasks that made the platform usable.
This post now preserves the intent of the original deployment without burying it under a long series of screenshots. The core build is historical. System Center 2012, SQL Server 2012-era dependencies, and Windows Server 2008 R2 are out of support. Keep this guide as archive material, not as the foundation for a new monitoring platform.
Beginning: what this SCOM build was designed to do
The original objective was a compact, all-in-one Operations Manager lab that could demonstrate the full flow:
- Management server
- Operational database
- Data warehouse
- Reporting
- Web console
- Basic agent deployment
For a proof of concept that made sense. For production, it never did. The first lesson from the old design is still the right one: a single-server install is a learning tool, not an enterprise architecture.
The example server looked like this:
| Server | CPU | Memory | Disk |
|---|---|---|---|
OM01 | 4 vCPU | 8 GB RAM | 120 GB |
Middle: the parts of the deployment that mattered
1. Get the service-account model right before setup
Operations Manager becomes difficult quickly if the account plan is vague. The original build separated the main identities into distinct roles:
- Action account
- SDK / configuration and data access account
- Reporting read account
- Reporting write account
- SQL service account
The practical point was not just separation for neatness. It was traceability, least privilege, and making later troubleshooting possible. In smaller environments the SDK account often ended up with more privilege than ideal, but even then it should have been a deliberate exception rather than an accident.
2. Treat prerequisites as a real deployment stage
The all-in-one SCOM build depended on a mixture of Windows features and application prerequisites:
- .NET Framework 3.5.1
- .NET Framework 4.0
- IIS
- MSXML 6.0
- Report Viewer 2008 SP1
- SQL Server 2008 R2 with SSRS and Full-Text Search
For the web console, IIS needed more than the default role install. Static content, ASP.NET, ISAPI Extensions, ISAPI Filters, Windows Authentication, and IIS 6 compatibility all had to be present.
The original PowerShell step is still worth keeping because it captured the intent clearly:
Import-Module ServerManager
Add-WindowsFeature `
NET-Framework-Core,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing, `
Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering, `
Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net, `
Web-Windows-Auth -Restart
If .NET 4 was added before IIS or the web console still failed after role installation, the classic repair step was:
cd \Windows\Microsoft.NET\Framework64\v4.0.30319
aspnet_regiis.exe -i -enable
That was one of the most common fixes in early SCOM 2012 web-console deployments.
3. Understand the network paths before importing a single management pack
SCOM is never just "install the server and point agents at it". The port model matters. In the original design the key flows were:
- Agent to management server:
5723 - Management server to operational database:
5724 - Reporting components to SQL / warehouse:
1433 - Web console browser to web console:
51908 - SNMP monitoring to network devices:
161and162
The exact numbers are historical, but the real lesson is current: monitoring platforms fail quietly when administrators ignore the traffic model and only troubleshoot after agents stop appearing.
4. SQL was part of the platform, not a side dependency
For the lab build, SQL 2008 R2 sat alongside the management server. That was acceptable for training, but the install still needed to be thought through:
- Database Engine
- SQL Agent
- Full-Text Search
- Reporting Services
- A supported collation
The original guide also called out Named Pipes in SQL Server Configuration Manager. Whether or not that setting was ultimately required in every environment, it reflects the general truth of old SCOM builds: SQL connectivity assumptions should be validated early, not discovered during reporting setup.
5. Create the AD container before expecting clean discovery workflows
For administrators integrating with Active Directory, the MOMADAdmin.exe step was a real part of the deployment, not an afterthought. Creating the management-group container in AD DS and assigning the correct delegation made discovery and management-pack workflows far more predictable.
That was one of the more useful parts of the original article because it moved the post beyond "wizard complete" and into actual operational readiness.
6. Install first, then import the management packs that matter
Once the platform was up, the next milestone was not simply opening the console. It was proving the management group worked:
- Create or validate the AD DS container.
- Import the required management packs.
- Confirm the console can see them.
- Deploy at least one agent as a smoke test.
That final smoke test mattered. A SCOM deployment without successful agent onboarding was not finished, regardless of how many install wizards had completed.
End: what remains useful from this build
The most durable parts of the article are the deployment habits:
- Separate the service accounts deliberately
- Prepare IIS and .NET properly
- Validate the port model early
- Treat SQL as part of the design
- Finish with AD, management-pack, and agent validation steps
Those habits still hold up.
What no longer holds up is the exact product stack. A supported Operations Manager deployment today belongs on a modern Windows Server release with a current System Center version, current SQL guidance, and current identity and certificate practices.
Closing thoughts
SCOM 2012 was part of an era where Microsoft wanted one monitoring platform to cover servers, applications, reporting, and network visibility through a central management group. That operating model is still recognisable. The technology baseline is not. Keep this post for historical context and migration planning, not for greenfield deployment work.
The Installer will run prerequisites for the hardware and software configuration requirements.
Enter the management group name you would like. You can either add to an existing management group or create a new one.
Agree to the terms and conditions.
Enter the SQL server name.
The SQL databases are the key core components to Operations Manager as they store the data and It is vital the details you enter are correct.
The SCOM installer uses the Database name of OperationsManager. if you have various instances installed on you SQL server , ensure you put the SQL nameInstance
The database size is set to 1,000 MB and you can change this to suit your environment requirements.
You can also change the Data file folder and the log file folder target address.
Select the SQL instance for reporting.
Choose the website and select the Enable SSL if required.
You should enable this feature in a production environment to protect network traffic.
Select Mixed Authentication.
Mixed Authentication
Network Authentication: users have to enter network credentials to login.
Enter the Active Directory service account details.
If you do not want to manualy update operations manager it is suggested that you select on.
Check the installation summary.
Adding the AD Management Pack
To create an Active Directory Domain Services container for a management group
Open the command window.
At the prompt, type the following:
_Cd\Program Files\System Center 2012\Operations ManagerServer\Momadadmin.exe Messageops System Center abc-training.ac.uk\scomaction abc-training.ac.uk_
Example:
"C:Program FilesSystem Center Operations Manager 2012serverMOMADAdmin.exe" "Message Ops" Domain(account) DomainmessageMOMAdmin account(account) Domain
Run the MOMADAdmin.exe utility from the command line.
Create the "Message Ops" Management Group AD DS container in the AD DS schema root of the Domain. To create the same Management Group AD DS container in additional domains, run MOMADAdmin.exe for each domain.
Add the DomainMessageAdAcct domain user account to the DomainMessageMOMAdmin AD DS security group and assign the security AD DS group the rights necessary to manage the AD DS container.
For more information on creating AD DS containers for managerment groups please see the link below:
How to Create an Active Directory Domain Services Container for a Management Group
Once the management group is created you then can import the Active Directory management pack.
You can download management packs from the online catalogue or from the local disks.
Management Pack install completed.
Deploying Agents
You can deploy agents using the deployment wizard located in the Administration menu.
Select the devices you would like to deploy agents to , in this case we will be wanting to deploy a windows agent to the Domain Controller.
Select browse for, or type-in computer names and select the Domain controller.
Use the Default setting and click discover.
Keep the default settings and click next.
Click finish.
As you can see from the screen shot above, SCOM is deploying the agent to DC01.
The screen shot above shows the monitoring agent running on the client.
Once the Active Directory Management Pack is installed and configured, you will be able to monitor the Active Directory environment.
References
Chris Amaris, Rand Moriomoto, Pete Handley, David E. Ross (2012). Microsoft System Center 2012 Unleashed. USA: SAMS. 664-760.
Microsoft. (2012). Microsoft System Center 2012. Available: https://web.archive.org/web/20210125153234/http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx. Last accessed 24 Jun 2012.
Microsoft. . How to Create an Active Directory Domain Services Container for an Operations Manager 2007 Management Group. Available: http://msdn.microsoft.com/en-us/library/bb309685.aspx. Last accessed 15 july 2012.
Microsoft. (April 1, 2012). How to Create an Active Directory Domain Services Container for a Management Group. Available: http://technet.microsoft.com/en-us/library/hh212738.aspx. Last accessed 15 july 2012.
Microsoft. (2012). System Center Technical Documentation Library. Available: http://technet.microsoft.com/en-us/library/cc507089.aspx. Last accessed 15 july 2012.
SatyaVe. (1st April 2012). System Center: Operations Manager Engineering Blog. Available: https://web.archive.org/web/20220624134033/https://blogs.technet.com/b/momteam/archive/2012/04/02/operations-manager-2012-sizing-helper-tool.aspx . Last accessed 15 july 2012.
