System Center Configuration Manager 2012 Beta 2 VHD Now Available

We have posted the ConfigMgr 2012 Beta 2 VHD. You can download the files here.

With this release you can also test out the Forefront Endpoint Protection 2012 Beta which integrates with ConfigMgr 2012. Take a look at the link at the bottom of this post for more information on how to get the FEP 2012 beta.

System requirements

Supported Operating Systems: Windows Server 2008 R2 Enterprise

Hyper-V is required to run this virtual machine. In addition to Hyper-V, you will need a 64-bit system with hardware-assisted virtualization enabled, as well as data execution prevention (DEP).

Hyper-V can be run from one of the following environments:
– Windows Server 2008 SP2
– Windows Server 2008 R2
– Windows Server 2008 R2 SP1

Prerequisites, installation steps, OS recommendations and known issues of Hyper-V can be found here.


1. Download all parts of the VM archive
2. Run the self-extracting RAR archive.
3. When prompted, accept the EULA. The VM will now be extracted.
4. Import the VM into Hyper-V

By default, this VM comes configured without a virtual NIC assigned. If you do not have a virtual NIC already defined in Hyper-V Manager, you will need to configure one. This is required in order to activate your 180 day trial period. You will have 10 days to activate.

Also, if you want to add more memory beyond the defaulted 4GB, do so before you launch the VM (Note: You can add a virtual NIC while the VM is running, but you cannot alter the memory)

Specific details on how to add this image to the Hyper-V library can be found in the README file included in this VM package.

If you have any questions, please contact

Additional information

Forefront Endpoint Protection 2012 Beta can also be evaluated using this VHD. FEP 2012 Beta software is available for download here. More information on FEP 2012 and its integration with System Center Configuration Manager 2012 is provided on the technet documentation site.

How to Install Secondary Sites in System Center Configuration Manager 2012

In prior versions of ConfigMgr, you had the ability to install a secondary site in multiple ways. The method that I always chose to install a secondary was to copy the installation bits down to the server and install via setup.exe. The other method was using the ConfigMgr admin console which would copy the content from the primary server down to the secondary server and do the installation for you.

In ConfigMgr 2012, there no longer is an ability to manually copy the bits to the server you would like to make a secondary and run setup.exe. The only way to install a secondary is via the Admin console. You can, however, still use source files that are located via a UNC share on another server (either at the secondary site itself or in some software repository).

Active Directory Forest Account

Now before we actually get into the installation of the secondary, we should talk about publishing sites to active directory and a new feature that lets us specify an Active directory forest account.

An active directory forest account is a new feature that connects to an active directory forest and does two things:

  1. Discovers AD Sites and IP subnets to automatically create boundaries
  2. Publishes site information to the AD forest

The second item is what I want to focus on.

In the past, when setting up a ConfigMgr site server, the computer object needed full rights to the System\System Management container in AD. With the AD Forest account, this is no longer the case as you can create a service account and give it full rights to the System\System Management container.

In order to specify your Active Directory Forest Account, do the following:

  1. Open the ConfigMgr Admin Console
  2. Click on the Administration node
  3. Drill into Overview, Site Hierarchy, Active Directory Forests
  4. In the pane on the right, right click your forest (in my case richbal.local) and select Properties
  5. At the bottom of the Forest Properties window specify your Active Directory Forest Account

It’s not mandatory that an account be specified, as you can still use computer accounts to publish to the System Management container, however I think using a service account will make things a lot easier with admins not having to remember to populate a group with computer objects and wondering why Hierarchy Manager is giving an error after every site being built.

Installing the Secondary

Now that the AD Forest account has been created, we can install the secondary and be sure that it will be able to publish to AD.


On the computer you plan to use for a secondary server, make sure to configure the following

  • The user account to install the secondary server must be a local administrator on the secondary server
  • The computer account of the primary server must be a local administrator on the secondary server
  • Remote Differential Compression (RDC) must be enabled
  • BITS must be enabled


To install a secondary site:

  1. Open the ConfigMgr Admin Console
  2. Click on the Administration Node
  3. Expand Site Operations
  4. Click on Sites

You should see all of the sites in your environment (and if you’re reading this post, you likely have only one primary which should be listed in the right pane). In the ribbon you should see a number of actions, one of which is Create Secondary Site.

Click on Create Secondary site to begin the wizard

Click Next at the welcome screen

Fill in the appropriate information. If you would like to have the default secondary settings, click Summary, otherwise click Next.

Note: Something to consider, if you are installing CM12 in the same domain as a CM07 site, you will need to have different site codes in order to prevent issues with publishing to AD (amongst other things).

If you would like to prestage the content on the secondary, you can do that and specify the source files location using a UNC path. You can also use a UNC path that might be a software repository location in your environment. In my case, I’m going to let ConfigMgr copy the installation source files over the network from the parent site.

New to ConfigMgr 2012 is the need for secondary site servers requiring a SQL database. By default, we’ll use a local copy of SQL Server Express (and do the install for you). However you have the option of using a full install of SQL server on the secondary server itself, or using an existing SQL server remote to the secondary. In my case I will allow ConfigMgr to configure a local copy of SQL Server Express on my secondary server.

Another new feature in the secondary site installation is the ability to create the addresses during installation for both the address going FROM the secondary TO the primary, and the address going FROM the primary TO the secondary. In ConfigMgr 2007 you had to create the address going from the primary down to the secondary which wasn’t exactly something a new ConfigMgr administrator would remember.

One thing you’ll see a lot in ConfigMgr 2012 is this concept of groups. In the past we had DP groups (and in 2012 we have enhanced those), but now in 2012 we have this concept of Boundary Groups.

I won’t detail boundary groups in this topic since there’s enough for a separate topic on that, but suffice it to say that boundaries can now be used hierarchy wide and are no longer to be used at the site specified. In order for a boundary to actually be used, a boundary group needs to be defined and applied to a site system (either distribution point or state migration point). In my case for this post, I have not created a boundary group for this site.

Review the summary and click next and at the completion screen click close.

In your ConfigMgr console you should now see something similar to the above picture. In the past, you wouldn’t have any installation status of the secondary site if installing from the administrator console. Notice at the top on the ribbon there is an option for Show Install Status? If we click on that we see the following:

Wow! We actually have the ability via the console to see exactly what’s going on during a secondary site installation!

But what about that failure on the first line? Why did we fail? If we dig a little into the above window, we can see that we failed in a few places:

  1. Configuration Manager Setup requires that the logged on user possess administrative rights on the site server computer – Well, this can’t be true, since we do have domain admin rights and those rights are on the server
  2. Short File Name (8.3 support) – Setup could not determine if 8.3 support is enabled, or couldn’t contact the server – this is possible
  3. Firewall is on and ports 1433 and 4022 are not open – this can prevent sites in different domains from communicating

So these are the three main failures, but the installation status doesn’t give me all the information I want. So where would I go to look at that?

The first place I would look is in the hman.log (located at <installdir>\logs\hman.log).

And here we found an issue where the prereq check didn’t pass, secondary site installation will be cancelled. Please check configMgrPrereq.log for results.

The ConfigMgrPrereq.log is located at c:\ConfigMgrPrereq.log. Opening that log gives us a little more information:

Here’s our message about not having user administrative rights, which is not true.

The next error talks about short file name support not being verified. This error is actually the following:

Short File Name (8.3) Support (Site system); Error; Setup either could not verify that short file name (8.3) support is enabled on the computer specified for site system installation or the server could not be contacted to determine short file name support information. No further prerequisite checking rules can be evaluated on the specified system. Setup cannot continue.

The next error talks about the Firewall exception for SQL server. Since we’re not in a cross domain situation, we can probably throw this one out. But we also have one last error to look at that wasn’t listed in the status:

Failure to insert DRWCfg registry key, values, and subkeys; error = 3.

So in total, we have four errors. What do we do to fix this?

We should either open the firewall ports for SQL (or disable the firewall if it’s not needed). We should also give local administrator rights to the primary server computer object. So once that’s done, we need to reinstall the secondary.

Unfortunately, to reinstall the secondary, we have to go through the wizard again. So if you run into issues installing a secondary site, delete the failed to install entry you have for the secondary you just installed and re-run the secondary install (you may have to refresh your view to see the Failed to Install state).

When you delete a secondary site, you are presented with the Delete Secondary Site Wizard:

The difference between uninstall and delete is simply that when you uninstall, it actually removes the bits and information about the site from the secondary site server itself as well as the hierarchy and AD. The delete secondary site option removes the information about the site from the hierarchy and AD, but doesn’t remove anything on the secondary server itself. In my case, I want to delete the secondary site since we didn’t communicate out to the secondary server and install anything.

Click next (or summary) to get through the rest of the wizard. Once finished, you may need to refresh your console view in order to see the secondary removed. Once it’s removed from the console, re-create the secondary site.

If the c:\Configmgrprereq.log passes the checks, you can watch the <ConfigMgr Install Dir>\Logs\Hman.log to see the secondary install package creation process (this may take a few minutes). You can then skip ahead to watching the sender.log which will ultimately send the package to the secondary site.

So for your perquisites for a secondary server, make sure to configure the following (as referenced above) to prevent any of the above issues from happening.

  • The user account to install the secondary server must be a local administrator on the secondary server
  • The computer account of the primary server must be a local administrator on the secondary server
  • Remote Differential Compression (RDC) must be enabled
  • BITS must be enabled







How to Install a System Center Configuration Manager 2012 Primary Site (Beta 2)

System Center Configuration Manager (ConfigMgr) 2012 primary site installation isn’t that much different than in ConfigMgr 2007, however there are some differences. The aim for this post is to show you the basics of primary site installation and what to look for post installation.


ConfigMgr 2012 has nearly the same prerequisites as ConfigMgr 2007, with the difference being that in 2012 we no longer require WebDAV to be present for MPs or DPs. This makes the installation on 2008 and 2008 R2 servers much easier.

  • Requires both .net 3.5 and .net 4.0
  • SQL 2008 SP1 with CU 10 or Greater (SQL 2008 R2 is NOT supported in the beta, but will be at release, and likely at RC)
  • WSUS 3.0 SP2
  • Remote Differential Compression
  • BITS Installed/Enabled
  • Computer account of the site server needs to have Full control rights to the System Management container and all child objects in active directory (this is unchanged from previous versions of SMS/SCCM)

Site Installation

Install Screenshots

Assess server readiness does not currently function in beta 2 (at least it didn’t for me).

I chose to download the latest ConfigMgr updates, however during the install it will ask you to download them, or provide a path where the latest updates have been downloaded.

Get the latest Configuration Manager updates downloads the following prerequisites:

  • Microsoft Remote Differential Compression Library (32 and 64 bit versions)
  • Windows Update Agent 3.0 (32 and 64 bit versions)
  • WMI Redistributable Components version 1.0
  • Silverlight Runtime
  • .NET Framework Client Profile 4.0 RTM
  • SQL Server 2008 Express
  • MSXML 6.0 Service Pack 1
  • SQL Server 2008 Native Client
  • SQL Server 2008 System CLR Types
  • SQL Server 2008 Management Objects
  • SQL Server 2008 Replication Management Objects

Click Install after the updates are downloaded.

Click Next

Click Next

Accept and click Next

Either download or specify the location of the updates and click next

Note: In beta 2 there is currently a bug when specifying a folder with spaces to either download, or use a previous location that you may have downloaded the updates to earlier. Make sure to use a folder with no spaces in the path.

Click next

Fill in the items and click next.

Since I don’t have an existing hierarchy, this will be a standalone site for now. Click Next.

By default the SQL server, the database, and the SQL replication snapshot folder will be filled in for you. I choose to have SQL installed on my E:\ drive, and will also have the replication snapshot location there. Click Next.

At this point, if you don’t have SQL 2008 SP1 with CU10 or greater installed, you will get an error. You MUST have SQL 2008 SP1 (no R2).

Click Next unless your provider location is another server

Native mode has changed since SCCM 2007 (it’s not even called Native Mode anymore). We now are allowed to use either HTTP or HTTPs (or a hybrid of both methods). In my test environment, I’ll be using HTTP communication since I do not have PKI certificates.

Click Next

By default a Management Point and Distribution Point can be installed. You also have the ability to select the protocol, either HTTP or HTTPS.

Click Next

Click Next at the Customer Experience Improvement Program

Click Next at the summary screen

I purposely configured my server with the bare minimum configuration to see what prerequisites the prerequisite check would find. These are the four that showed up on my Windows 2008 R2 SP1 server that I only installed .net 3.5, .net 4, SQL 2008 SP1 and SQL 2008 SP1 CU13.

Fix any issues, click run check, and click next

Click Begin

As the progress is being monitored, you can click the view log button to see what the installer is doing. The log is located at C:\ConfigMgrSetup.log

Pro tip: If you go to the directory where you extracted the beta, open the Tools folder, and you will find a new version of trace32.exe. This is actually called System Center Trace now and is a 64 bit version of the application (it should probably be renamed to trace64 or something else).

And if all goes well, you should see the above screen.

Click close and the console should open up.