System Center Mobile Device Manager 2008 – Install Guide (No Gateway) – Part 3

If you’re still following me, and you’ve finished the first and second part this is where we reach a conclusion for this scenario. So you’ve run the BPA, and you may or may not have a number of warnings/errors. I said we’ll try to get rid of them here.

Actually I was sort of misleading you here when I gave the impression there is a lot to figure out. I ran the BPA after installing Enrollment and Device Management, I then installed the MDM Console, ran BPA again, and most of the warnings had solved themselves. Presumably the console runs a few PowerShell cmdlets on it’s own when you install it. So I really did not have much to worry about in that department, but for completeness sake, I’ll follow you through them. You might run into the cmdlets not being run for some reason, or some other issue occurring requiring you to understand them. (Obviously there are a lot of different warnings and errors BPA can produce – I can only go through a few of them here.) If you are not interested skip along to the next step.

We’ll do the warnings one by one:
”MDM services might not start correctly if you do not install the .NET Framework language in the same language as MDM. You can download and install the .NET Framework Version 2.0 Language Pack from the Microsoft Download Center at this Microsoft Web site: Make sure that you select the correct language and then choose Update to refresh the page before you choose Download.”
This one is actually a bug in BPA. Ignore it.

”The host names that are mapped to the loopback address can not connect to Web sites on your computer.
This may result in following error. “HTTP 401.1 – Unauthorized: Logon Failed”.
Refer to the following Microsoft site for correcting the Loopback
This one’s fair enough. Follow the link provided, in this lab I’m going for Method 1 and disabling the loopback check.

3 warnings regarding enrollment passwords.
These are probably good recommendations. It’s not that important for testing purposes, but if you want to get rid of the warnings use the Set-EnrollmentConfig cmdlet – 

4 warnings regarding SMTP/E-mail settings for enrollment.
Ah, yes, SMTP… Well, we don’t have an Exchange server at the moment, and we don’t have any other mail server either. We’ll leave this be for now. It will be populated with default values, which will not actually work. The feature means that when you enroll a device the user is sent an e-mail with all the information they need. We’ll cover this later (in a different post).

”Gateway URI is empty. This setting would allow managed devices to connect to Mobile Device Manager (MDM) Device Management Server directly by using the LAN or WLAN, instead of connecting through MDM Gateway Server.
Gateway URI should be the name, IP address, or Domain Name System (DNS) name of the virtual private network (VPN) gateway. This must be an address available from the public Internet.”

This is sort of exactly what we want in this scenario, but in a later scenario (with Gateway) we’ll reconfigure this.

“ActivateVPNbyDefault is not set to True. Setting this to True would make enrolled managed devices to connect to the company network by default through the VPN connection to MDM Gateway Server.
To set it to true use the following command: -ActivateVPNbyDefault or -ActivateVPNbyDefault:$true;”

This is another of those settings we want to an “unrecommended” value when we don’t use a gateway. Actually we run the following cmdlet: 
Set-EnrollmentConfig –ActiveVPNbyDefault:$false

That wasn’t so bad was it? (If you didn’t do any preparation, and just went ahead with the install you’d probably have more errors to deal with.)

Ok, now we are ready to start testing with a device. This consists of creating the pre-enrollment record, and enrolling the device from client side.

Pre-Enrollment Wizard

By launching the MDM Console, and choosing “Device Management” on the left hand side, you’ll be able to click “Create Pre-Enrollment” on the right hand side. Pre-Enrolling means you create the device in AD before it’s actually joined. (This is what you should be doing with your computers/servers as well, but some lazy admins create the computer account automatically when the computer is joined to the domain. Not a best practice, but that’s another topic entirely.) This also means a user cannot just pick up a WM 6.1 device and decide to join it, there needs to be a record server side expecting the device/user to connect in.


Press “Next”.


First we choose a name. Any old name will do, but please follow a naming standard for your own sake. Using the IMEI from the device would be a good identification. (You can’t reuse names easily so you should keep this in mind.) Names should be 15 characters or less.


Click browse to get a list of users in Active Directory. We don’t have an Exchange server in our lab, so you’ll get an error stating that there is no e-mail defined for user, and because of this the e-mail address will not work as enrollment id. Well, we’ll just “fake an Exchange account” by adding an e-mail address to the user properties in AD. (SCMDM is likely to be deployed in an infrastructure where Exchange is also deployed, but it’s not a requirement.) This also means you shouldn’t check the box about “Sending an e-mail configuration…”



Should be everything we need, so click “Create”.


You’re provided with a summary, and the info that the pre-enrollment was successful. Since we have not set up SMTP the Enrollment password is only provided on this page. If you click “Finish” you don’t have it anymore, so either jot it down in Notepad, or keep this page open when you perform the next steps.

Domain Enrollment

Now you can power up your device. I opted to fire up the Device Emulator since we don’t need GPRS, WLAN or similar technologies. I just cradled it to ActiveSync so I got network connectivity through the host computer. Please make sure that you have network connectivity before moving on. Start Internet Explorer, and make sure you are able to either open a web site, or an intranet site.


Start->Settings->Connections->Domain Enroll.




Yes, we know someone else is controlling us… “Next”.


Your device will look up (at least for this e-mail address). If for some reason the device is not able to contact the Enrollment Server at this address you will be prompted to provide the server address manually.


Type in the password you got while creating the pre-enrollment.


And when you get to this point you’re good. On my emulator I don’t get the next notification that would normally tell me to reboot the device. (On an HTC TyTN II I got the notification some hours later after already running some DM sessions, and not requiring a reboot.) I attribute this to a couple of details; I’m not providing the device with a gateway, and I’m not establishing a VPN tunnel. I’m just connecting directly to the Device Management server.
You should probably do a soft-reset anyway’s. (Clue me in if I missed an important detail in this “explanation”.)

Looking at the server console we can see that the device is enrolled, and info has been collected from the device. You’ll notice that the device is listed both under “All Managed Devices” and “Pending Enrollments”. This is because the device never got the reboot notification, and thus it was never removed from the pending enrollments. It should be removed from the pending enrollments list when the enrollment time-out kicks in (8 hours down the line). Remember – we’re not exactly running an optimized configuration here so we are bound to hit a few snags 🙂


And a quick look in ADUC shows it’s a citizen in our domain as well:

At this point you can start tinkering with the console, investigate what SCMDM has collected of information from your device. Try out specifying settings through the Group Policy Extensions. Maybe distribute some software with Software Distribution Console/WSUS. I’m not going to cover usage of these features, at least not in this post. Do remember as I mentioned in Part 1 that when you’re running a wipe, it will not be “Wipe now” as the console leads you to believe. This is not a bug, this is the way it’s supposed to be when you’re not using a gateway server. The device will be wiped on the next scheduled connection (8 hours default).

There is no way to make the device connect manually by default, so when you’re testing and don’t want to wait for the next schedule you should have a look at “MDM Connect Now” from SCMDM Resource Kit.

That’s it for now. You should hopefully have a working little lab if you’ve followed my instructions. You may provide feedback if there’s any errors or omissions in my guide. I’ll follow up with another post detailing the addition of a gateway to the infrastructure.

System Center Mobile Device Manager 2008 – Install Guide (No Gateway) – Part 2

We are now ready to do the fun part which is installing SCMDM. There are a few main areas covered in this part:
– Configuring Active Directory for MDM
– Installing the Enrollment Server
– Installing the Device Management Server
– Running a Post-Deployment scan with SCMDM BPA to make sure everything went smooth.

There’s plenty of screen shots, and maybe that’s not your cup of tea, but I believe a picture’s worth a thousand words.

Configuring Active Directory
Active Directory needs to be configured for including mobile devices in your domain. This includes creating groups/OUs, preparing the CA, etc.
Logon to “md-scmdm” as the domain admin. (You need domain admin, and schema admin to perform these actions.) I’m not detailing everything in this section, it can be found in the reference material from Microsoft (TechNet Library).
Fire up a command line and execute the commands as shown below: 
adconfig /


adconfig /createtemplates

adconfig /enabletemplates /ca:”\MobilityDojo Root CA”


adconfig /gpsecurity:all

adconfig /gpsecurity:default

Ok, it’s been smooth sailing so far. On to the actual SCMDM components. We’ll start installing the enrollment server, followed by the device management server.

Installing the Enrollment Server
After prepping AD, you need to logoff and logon again. This is because some new security groups have been created, and membership is applied when you logon to the domain. (And you need to be a member of one of these new groups to be able to install.)

First we have to provide the SQL Server location. Do type in the full FQDN. Do not type localhost even if this is the case as in our lab. (This will give errors later on in the process.)


For some reason I could not get it working when I provided the instance name (like above). Even if BPA said ok, and everything. I don’t know why, but it worked when I just provided the FQDN (see below). (Maybe because it’s running on the local host with only the one default instance?)


Next you provide the DNS addresses for external and internal access. The external one has to be, but the internal can be a different one. The internal DNS name does not have to match the host name (SSL requires a match between the certificate common name and the address DNS provides). In our lab environment the two addresses are the same. DNS resolution will also be verified (unless you check “Skip Enrollment FQDN validation). I logged on to the Domain Controller,  and created an A record for If you’ve already tried pressing “Next” and got an error you probably have to do an “ipconfig /flushdns” on the command line.


You can accept the default port for the administration web site.


We use the same CA for both devices and servers.



And then we are ready to hit the install button.


Hopefully it will end like this:

No point in waiting, so we’ll just move right along to installing the Device Management Server.

Installing the Device Management Server

The SQL Server location has already been filled in for us this time (and you can’t change it).

With the DM server we can choose the actual FQDN of the server. (It will not be exposed externally.)


Accept the default ports suggested.


Same CA.


Also ending with the “Install” button.


And hopefully you’ll get this screen here as well 🙂


Maybe it’s just me, but I like a fresh reboot after installing servers, so while it’s probably not necessary it is nonetheless my next action.
Next item on the menu is running SCMDM BPA again, this time choosing the Post-Deployment Scan. What we are looking for here are errors, and hints on how to correct them. If you get an error on the DM server saying something about .NET Framework Language – ignore it, it’s a bug in the BPA. You’ll probably get a number of warnings as well, but this is expected since we haven’t configured our servers yet. (BPA will give you helpful hints what you should do – after all that is why it’s called “Best Practices”.)

All of this will be covered in the next part, but before moving on to the configuration part you should install the last SCMDM component for now; the “Administrator Tools”. Don’t check the “Group Policy Extensions” item – we’ll install these on our Domain Controller later on. (GPMC which is required for using these extensions only runs on 32-bit, so it will not install on the SCMDM server.)


You may find it very tempting to boot up a device at this point, and start pressing it’s buttons. Please resist the urge – it is better to make sure the server is correctly configured than pulling your hair afterwards when you’re not getting the device to work 🙂

Ok, on to the part where we smooth out the edges of our installation, and try to test with a device.

Part 3:

System Center Mobile Device Manager 2008 – Install Guide (No Gateway) – Part 1

I mentioned it only briefly in my last post, but Microsoft has a product in the System Center family that let you take control of your Windows Mobile devices, and make the mobile devices part of the domain just like any other computer in your LAN (and WAN). And obviously once they are part of your network you can distribute software, configure settings on the device, etc. This product has the tongue-twisting name of System Center Mobile Device Manager 2008, or SCMDM2008 for short. (Some refer to it as MDM, but since this acronym can also mean Mobile Device Management in general, it’s better to use it only in a given context where it’s implied there’s an SC in front. Apologies for being a nit-picker 🙂 )

I’m not going into all the features and sales “fluff” here however, and intend to provide a practical and technical hands-on approach instead. If you have no knowledge of what it’s all about I advice you have a few looks on the product page (and then return here):

If you look into the TechNet Library you’ll find lots of documentation on the product, how to plan for implementation, architecture, deploying, reference materials, etc. And the documentation is good, but there’s a lot of it, and if you just want to test drive it for yourself you might not be interested in reading 200 pages of architectural considerations. Participating in the TechNet forums I see a lot of people are having problems evaluating this product since it is a pretty complex solution, with a lot of steps that need to be performed in specific orders. With this in mind I decided to write some how-to’s hopefully helping someone along the way. I don’t claim to have all the answers myself, and I have also struggled with some issues, but I’ll try to produce a guide that will let you set it up in your own lab and actually get it to work 🙂

I’ll probably divide this into several guides, detailing different scenarios, and maybe going in depth regarding some aspects of the solution. In this first scenario I’ll try a very basic scenario:
– All devices connect through LAN. No GPRS, or other external access.
– No gateway or VPN tunnel. All devices connect directly to the Enrollment and Device Management server.
– “Everything” installed on one server. This includes Enrollment Server, Device Management Server, SQL Server and WSUS Server. The exception is the Domain Controller which is a separate server (also hosting a Certificate Authority).
I call this the “SCMDM – No Gateway”-scenario.

One caveat with this scenario is that you will not be able to use the “Wipe now”-feature. Your devices will be wiped on the next scheduled connection to the server. This is because this feature is dependent on the Gateway server. (I will not go into further details, the technical reasoning behind this is explained in the TechNet Library.)

I know there are a lot of different network setups out there, with different firewalls, routers, etc. And this makes writing generic guides difficult. The scenario I walk through here should however be fully reproducible in your lab since it is a very stripped down setup. No firewalls, no routers, no Internet – just two virtual servers and a few innocent mobile devices.

This would be how our tiny little infrastructure looks like 🙂


Some technical details regarding how I configure these “boxes”:
– Everything is virtualized on a single physical computer with one physical NIC, running Windows Server 2008 with Hyper-V. As far as I know it’s not supported in a production environment to do this, but it’s not a problem for lab work. System Center will install with less than the recommended/required 4GB, but obviously the more the better. I’m using a quad-core Xeon with 8GB RAM as the host machine, but I’ve done some testing previously on a Core 2 with 4GB which also works albeit somewhat more “sluggish”.
– The Domain Controller is Windows Server 2003 R2 32-bit Enterprise Edition with 512MB RAM. 32-bit is required to use the Group Policy tools, so unless you have any other compelling reasons to go 64-bit stick with 32-bit for this scenario.
– SCMDM Server is Windows Server 2003 x64 Enterprise Edition with 2GB RAM. 64-bit is a requirement, which means Hyper-V is the only option if you’re using virtualization from Microsoft.

The domain controller has to be Enterprise Edition because of the Enterprise CA we are running. You can install an Enterprise CA on Standard Edition as well, but you will not be able to define your own certificate templates, which is something we need for SCMDM. (The certificates for the mobile devices are based on a custom template generated by the SCMDM install process.)

I’m using the English version of Windows Server 2003, and SCMDM. You can use other languages, but keep in mind that you can’t mix language components. So if you have another language of Windows Server you need to check you are installing the same version of ASP.NET, etc. Since English is the default in a Microsoft world I stick with that all the way through.

The servers have the following network setup:
Domain Name:
Domain Controller name: md-dc-ca
Domain Controller address:
SCMDM Server name: md-scmdm
SCMDM address:
Since it’s all on a LAN without routing you don’t need a default gateway defined.

Getting your Domain Controller ready
– Make sure your domain is at “2003 Functional Level”. (If you installed a new domain it will be at “2000 Functional Level” by default.) Update: Make sure it’s 2003 Native level, not 2003 interim (which is used for support Windows NT 4 servers). Also make sure your Forest Functional level also matches and is running 2000 or 2003 functional level. (If you installed a domain from scratch like I have done in my lab you don’t need to touch the Forest Functional Level.)
– Install IIS.
– Install Certificate Services choosing “Enterprise Root CA” as the type. If you don’t want to get some extra configuration hassle afterwards make sure the previous step is performed before this step – the order of these two steps is not random.
– You’ll need the name of your CA later, so make a note of it – I use “MobilityDojo Root CA”.

Getting your MDM server ready
– Install IIS.
– At this time you should make sure that IIS/.NET is running in 64-bit.
Run the following command (from command prompt):
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
Change to C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727
Run: aspnet_regiis –i
Run iisreset

– Install SQL Server 2005. Not SQL Server 2008, and not SQL Server Express. Standard Edition should be ok, as well as Enterprise and Developer. Default settings should be good, if you don’t have any preferences stating otherwise.
A few extra steps must be performed on your SQL Server install to enable use for SCMDM.
– Set the “SQL Server Agent” service to “Automatic”.
– Set the “SQL Server Browser” to “Automatic”.
– Enable Remote Connections for TCP/IP. You can do this via “SQL Server Configuration Manager” or “SQL Server Surface Area Configuration”. MS has a good explanation here:

Then there’s some small applications you need in addition (remember to get the 64-bit versions where applicable):
– Install PowerShell 1.0:…/powershell/download.mspx
– Install MMC 3.0 (if necessary – if you’re running 2003 R2 it’s already installed):
– Install Report Viewer 2005 SP1:
– Install MBCA (Microsoft Baseline Configuration Analyzer):

We then proceed to installing WSUS 3.0 SP1. There is an important step in the install wizard – you should create a separate web site for WSUS. If you don’t there’s a chance it will interfere with the enrollment web site we’re creating later. Accept the default port the wizard suggests for the new web site.

All should be good with regards to the software you need before installing SCMDM, but you should run SCMDM BPA, (Best Practice Analyzer), to make sure everything is in order before you start installing. Actually you should go ahead and download all the Resource Kit Tools (only install BPA for the moment):
The type of scan you’ll want is the “Pre-Deployment Scan”. You might get an error stating “Scan failed”. This means you have to change a policy in Powershell. Run the following cmdlet in the Powershell console: “Set-ExecutionPolicy RemoteSigned”.

Make sure you get green lights on the Enrollment and Device Management role. (If you get warnings about CPU and/or RAM ignore this.) In this scenario you might get an error on the SQL role as we are installing SQL on the same box as SCMDM. Also make BPA check that AD and the CA is good to go.

I would have loved to have a screen shot with no warnings, but seems there’s a bug in the RAM detection scheme. I tried upgrading to both 4 and 5 GB temporarily and it still complained I didn’t have 4 GB…

As for SCMDM itself, it’s available on TechNet & MSDN, and as an evaluation version here:

Now that everything is in place we can proceed to the next step – actually installing SCMDM 🙂
This is covered in Part 2:
Part 3: