System Center Mobile Device Manager 2008 (SCMDM 2008) has recently seen the release of Service Pack 1, so I felt it was time for another multi-post series on how to perform an installation of this little MDM product from Redmond.

You can read more about SP1 here: What’s New in Mobile Device Manager 2008 SP1
Download an evaluation version here:
System Center Mobile Device Manager 2008 Service Pack 1 – Evaluation
And you can read my previous exploration of the install process here:
http://mobilitydojo.net/2008/09/22/system-center-mobile-device-manager-2008-install-guide-no-gateway-part-1/

If you’re entirely new to what SCMDM is all about you might want to give this link a look:
http://technet.microsoft.com/en-us/scmdm/default.aspx

One of the new features in System Center Mobile Device Manager 2008 Service Pack 1 is the ability to deploy multiple SCMDM instances in a single forest. Although my lab was working nicely with just one SCMDM deployment it was a feature I couldn’t resist testing, and documenting

Another new feature of SP1 is support for Windows Server 2008 Domain Functional Level, and Certificate Authority running on Windows Server 2008. I had to include this in my new lab as well.

So before installing SCMDM I have setup a new forest with a root domain, and two sub-domains. I installed this using three Virtual Machines all running Windows Server 2008 SP2 (Beta) Enterprise Edition.

As you can see MobilityDojo.net has expanded geographically for the sake of this article and we now have a presence both in EU and North-America:

The Domain Controllers are all connected to the same subnet, and in the same IP range. Both Forest and Domain are at the 2008 Functional Level.

And to match this domain structure we have a corresponding PKI infrastructure configured:

Root CA is running on the Root DC, EU Sub CA on the EU DC. You get the picture.

You might be thinking this is a strange PKI setup, or that it should have been designed in another way, or something. There isn’t really a single correct answer that stands out as to how you should implement the PKI infrastructure for SCMDM, and this is just one example. I could have opted for a stand-alone offline Root CA, I could have had two separate Enterprise Root CAs in each domain. I might reflect further on this at another time, but not for now.

We are then planning to install two SCMDM servers in each of the sub-domains. One server for the Gateway, and one for Device Management and Enrollment in each domain. These servers still need to be running Windows Server 2003 x64 though since there is no support for running SCMDM itself on Windows Server 2008.

I’ll skip running through the details of the pre-requisites for the W2K3 servers, as this has been covered previously: SCMDM 2008 (RTM) Install Guide
One thing to take note of though is that you need the newer versions of some of these, so a quick summary goes like this:
Device Management Server
IIS 6.0
.NET Framework 2.0 SP1
WSUS 3.0 SP1
Enrollment Server
IIS 6.0
.NET Framework 2.0 SP1
Gateway Server
IIS 6.0
.NET Framework 2.0 SP1

I’ll never be able to keep track later when configuring the servers, so here’s a summary of what we will have of servers and IP addresses:
Domain Controllers (and CAs):
MD-DC
Internal IP: 192.168.10.10
MD-DC-EU
Internal IP: 192.168.10.15
MD-DC-NA
Internal IP: 192.168.10.20

Enrollment & Device Management Servers:
MD-MDM-EU
Internal IP: 192.168.10.30
MD-MDM-NA
Internal IP: 192.168.10.31

Gateway Servers:
MD-GW-EU
External IP: 172.16.x.y
Internal IP: 192.168.10.40
MD-GW-NA
External IP: 172.16.x.y
Internal IP: 192.168.10.41

We’ll start by running ADConfig to prepare our forest and domains before installing. As we will be running two instances the first thing to do is coming up with names for these. Let’s go crazy in the naming department and call them “SCMDM-EU” and “SCMDM-NA”. To make it clear, you can have multiple instances in a single domain as well as far as I know. You do not need different domains, but it was the route I felt like going down for this lab.

I’ll be running ADConfig both on the root domain controller and on the two sub-domain DCs. This is because some tasks require you to be domain admin, and some enterprise admin. I could have just added admin accounts to the corresponding admin groups, but I decided to keep it clean. I have indicated what the task requires, and on which Domain Controller I am running it on.

Here’s what it looks like setting up the EU instance. (I’ll be performing the same steps for the NA instance, but you only need the screenshots once:) )

ADConfig /createInstance:SCMDM-EU /domain:eu.MobilityDojo.net
Requires Domain Admin
Run on EU Sub DC

ADConfig /enableInstance:SCMDM-EU /domain:eu.MobilityDojo.net
Requires Domain Admin
Run on EU Sub DC

ADConfig /createTemplates:SCMDM-EU
Requires Enterprise Admin
Run on Root DC

ADConfig /enableTemplates:SCMDM-EU /ca:”MD-DC-EU.eu.MobilityDojo.net\EU Sub CA”
Requires Enterprise Admin
Run on Root DC

ADConfig /enableGPSecurity:SCMDM-EU /gpo:default
Requires Schema Admin
Run on Root DC

ADConfig /enableGPSecurity:SCMDM-EU /gpo:all /domain:eu.MobilityDojo.net
Requires Domain Admin
Run on EU Sub DC

After performing these steps we run ADConfig /listInstance on the Root DC to verify that we have the following two instances:

You should also run ADConfig /validateInstance on the two sub domain controllers. (ADConfig /validateInstance:InstanceName /domain:FQDN).
This will give you info if there are any errors in your AD relating to your instances. You will need to pay attention to what the warnings/errors actually say though. When I had it validate SCMDM-EU it said there was something wrong with the SCMDM-NA instance, (like I actually told it to check this), and the other way around on my SCMDM-NA instance. I don’t consider this an error in my deployment, but rather the ADConfig tool not fully taking to my multi-instance lab environment

Then we’re off to the next stage – installing all the good bits and bytes.