And moving to the “wrapping up phase” of this installation we have just one final step to cover, which is getting a Gateway Server in place. There are two dependencies you need to get in place before you can start the install however.

The multi-instance feature requires the Gateway Server to have knowledge of the specific instance it belongs to. The Gateway Server is not a member of Active Directory, and thus cannot learn anything from the instance information there. You will need to supply this information in an xml-file, which you can either create yourself, or more preferably create on the Device Management Server and transfer to the GW Server.
Run the Export-MDMGatewayConfig cmdlet on the DM server to create a file.
If you decide to open it up, it will look something like this:

Second thing you need to do is create certificates and install these on your GW Server. This is covered in my previous post,
(http://mobilitydojo.net/2008/09/24/system-center-mobile-device-manager-2008-install-guide-no-gateway-part-3/), or you could go with the TechNet documentation:
Creating the MDM Gateway Certificate Request and Certificate
Exporting the Certification Authority Certificates
Create and Import Certification Authority Certificates onto the MDM Gateway Server

You should run the Best Practice Analyzer before deployment on this server as well. I had to enable ASP.Net web extensions as this was disabled by default, but that’s about it. There is also an error because I do not have a public IP address assigned to one of the network interfaces, but this is a lab with no public access so it does not matter.

After these steps are in place this is also one of your average “Click Next”-installs Screenshots below, that I hope are self-explanatory.

Installing the Gateway Server

After this procedure has finished you’ll want to login to your Admin Console, and add the Gateway Server by following the Wizard.

Looks like everything is in order:
 

And if you also want the device to be able to locate the Gateway when enrolling you’ll want to run the following cmdlet in the MDM Shell:
Set-EnrollmentConfig –GatewayUri md-gw-eu.eu.mobilitydojo.net substituting your own Gateway Server FQDN instead of mine.

I always have to verify that things are working like they should, so I’ll also enroll a device just for the sake of it. I’ve created a pre-enrollment request on the Enrollment/DM Server, and have fired up a device. I’m using a Windows Mobile 6.1 Standard this time, although I’m not a big fan of those devices for testing due less utilities available, less typing-friendly form factor (even though newer devices have an actual keyboard they are more phone-type devices than email-type devices). Nonetheless, we should be able to enroll it at least

Enrolling a device





 

And that concludes the scenario basically.

Ok, there are some questions left unanswered Yes, it’s all nice and dandy to have one server located at .eu.mobilitydojo.net, and another at .na.mobilitydojo.net, and so forth. But our email addresses are mobilitydojo.net – how does the device know which server to hit? The device has limited ability to guess which server is the right one, and bases itself on the address the user specifies (looking at the right hand side of the @). It will work if the user specifies the enrollment server manually, but we can agree that is not ideal either. I don’t know if it could be solved by using ISA Server (or a similar product) to publish multiple enrollment servers, and direct the user to the correct one. This is a scenario I will be testing closer though.

I haven’t really touched any specifics regarding firewall, internally or externally, either and solved this in a “hackish” way here by having all servers connected to the same two networks. Conveniently this also reduces the need to configure routing – but you still need to define a route to and from the device subnet mind you.

If you also install a Gateway for the SCMDM-NA instance you should now have a fully working lab with multiple domains, multiple CAs, and multiple instances.