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: http://go.microsoft.com/fwlink/?LinkId=105268. 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 http://support.microsoft.com/kb/896861”
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 – http://technet.microsoft.com/en-us/library/cc138215.aspx
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:
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.
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.
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.
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.
Yes, we know someone else is controlling us… “Next”.
Your device will look up mobileenroll.mobilitydojo.net (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 🙂
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.