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.

Prerequisites

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