Deploying System Center 2012 Virtual Machine Manager

This article has been rebuilt as a proper archive post rather than a screenshot dump. The original lab was valid for 2012, but System Center 2012 and Windows Server 2008 R2 are now out of support. Keep this for historical estates, documentation exercises, or migration planning. Do not use it as the design pattern for a new deployment.

Beginning: what this build was trying to achieve

The aim of the original build was straightforward: stand up a single System Center 2012 Virtual Machine Manager server that could manage Hyper-V, integrate with SQL Server, and optionally onboard VMware resources through vCenter. In a lab or training environment that was a practical way to learn the VMM fabric model without committing to a large multi-server design.

For this walkthrough the management server was sized as follows:

The software stack used at the time was:

• Windows Server 2008 R2 Datacenter
• .NET Framework 3.5.1 SP1
• Windows Automated Installation Kit (WAIK) for Windows 7 x64
• IIS with ASP.NET, ISAPI, IIS 6 compatibility, request filtering, and static content
• SQL Server on the same server for a small lab deployment

The account model was equally simple:

• One domain administrator-style account for the VMM service and console administration
• One Run As account for Windows hosts
• One Run As account for VMware, usually root in smaller environments

Middle: the deployment sequence that mattered

1. Prepare the operating system first

The cleanest SCVMM 2012 installs started with the OS, .NET 3.5.1, IIS, and WAIK already in place. If one of those components was missing, setup usually failed late and forced a rollback. Treat prerequisite validation as a real step, not as something to fix mid-install.

For IIS, the important point was not just "install the web server role" but "install the exact VMM-facing feature set". ASP.NET, ISAPI Extensions, ISAPI Filters, IIS 6 Metabase Compatibility, and IIS 6 WMI Compatibility were the settings most often missed.

2. Decide whether SQL belongs on the same server

In this lab the SQL instance lived on the VMM server itself. That was acceptable for proof-of-concept work, but it was always the first part of the design to split out in a larger environment. If your objective was availability or growth, SQL deserved its own server and its own operational model.

For a single-server deployment the practical rule was:

• Keep SQL local for a lab
• Separate SQL for anything that needs scale, backup discipline, or resilience

3. Install VMM with the service account and database choices already agreed

The VMM installer itself was not especially complex once the prerequisites were right. What mattered was entering the correct service account, validating the database target, and understanding what the deployment was supposed to manage after setup. Too many early builds installed VMM successfully but had no account plan for host onboarding, library sharing, or delegated administration.

At this stage the build should finish with:

• The VMM management server installed
• The console opening successfully
• The VMM database reachable
• The library share created and available

4. Add fabric resources in a controlled order

Once VMM was live, the sensible next step was to add the fabric incrementally:

1. Start with Windows-based virtualization resources first.
2. Validate Run As accounts before adding large host groups.
3. Only then add VMware resources through Fabric > Add Resources.

That order mattered because troubleshooting Windows host onboarding inside VMM was easier than troubleshooting third-party integration at the same time.

5. Be realistic about VMware integration in early SCVMM 2012 builds

This was one of the biggest caveats in the original article and it still deserves to be stated plainly. Early SCVMM 2012 builds exposed limited VMware integration and support statements changed across service packs. In practice you could discover vCenter, enumerate clusters and hosts, and perform some management tasks, but this was not feature parity with native vSphere tooling.

If a VMware host showed a limited management state, the usual remediation was to revisit the host properties, re-enter the VMware credentials, and accept or revalidate the certificate chain. That was often enough to move the host from partially managed to usable.

6. Integrating VMM with Operations Manager was useful, but opinionated

The VMM to SCOM integration path delivered real value: health, alerting, and service-state visibility for virtualization objects. The catch was that the management packs and console components had to be aligned correctly. If that wiring was wrong, the integration existed on paper but never became operationally useful.

The important outcome was not merely "integration completed". It was being able to open VMM and use monitoring data to troubleshoot host and virtual machine issues without bouncing between separate consoles all day.

End: what still matters and what does not

The most useful lesson from this old deployment is not the click path. It is the design order:

• Prerequisites first
• Accounts second
• Database placement third
• Fabric onboarding fourth
• Monitoring integration last

That order still applies to modern management platforms even though the products have changed.

What does not carry forward cleanly is the exact product baseline. SCVMM 2012 on Windows Server 2008 R2 belongs to a historical estate now. If you are maintaining one, document it carefully and plan the exit path. If you are building something new, use a supported System Center release or reassess whether you still need the same management model at all.

Closing thoughts

As a historical lab guide, SCVMM 2012 still tells a useful story about how Microsoft expected administrators to think about fabric, Run As accounts, and multi-hypervisor management. As production guidance in 2026, it has reached the end of its useful life. Keep the architecture lessons, not the platform choice.