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:
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.
“Enroll”.
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 
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.
Hi, I’m a new user, I followed the steps you provid to build the connection, the device cannot be enrolled to the domain,it shows:Error, can’t enroll this device into the corporate domain, but the device can recognize the server and password, could you please give me a hand,thx, Feng
I’d follow the steps in this article: . Start out with the “Unable to Enroll Device in Domain” section.
Hi,Andreas,I have some question when I use the management console:
1.Does it support to deploy or copy a xml to a specific folder in managed device?
2.Must the package have a CA certificate? And if I have a cab file which has been signed by other CA certificate, can the cab package be distributed?
THX
Hi Feng,
1. No, you cannot distribute files to specific folders on your device. If you need files in a specific folder you need to package them in a cab file, and have the cab specify the folder for the files.
2. The package must be signed, either by yourself or another CA. If it is signed by a commercial CA you also need to import these certificates. Commercial applications will normally be signed by a so-called M2M certificate, and this is already trusted on your Windows Mobile device, so you just have to install the root certificate on your DM server.
Thank you, Andreas
And if a cab file was signed and approved, will it be installed into the managed device immediately or at a scheduled time/interval, if at a scheduled interval, can I modify the setting and make it installed immediately?
There is no “push” functionality in SCMDM so you’re not able to install things immediately. Everything is based on the server waiting for the clients to make connections on a pre-defined schedule. The software distribution mechanism is run on the same schedule as the device management sessions. If I remember correctly the default schedule is set to 8 hours, but this can be reconfigured through powershell cmdlets. You should however keep in mind that setting this too low will create a lot of extra management sessions on the server. And if you set the schedule to anything lower than an hour you risk running into a limitation that will install applications more than once. (Basically the inventory isn’t updated and software distribution isn’t able to realize that the application has already been installed.)
Hi Andreas
I got another problem,I followed the steps Microsoft TechNet states and imported the CA certificates and PFX certificates, then began to create a package, the TechNet states that there should be a Sign cabinet file and Private key buttons in Software Package page,but I didn’t see them.
BTW,I tried to reset the connect interval, I tried this cmdlets:Set-DeviceManagementConfig -ConenctInterval (New-TimeSpan -hours 1), but it didn’t work.
Thank You
Feng
The buttons for “Sign cabinet…” and “Private Key…” were introduced in Service Pack 1, so if you have installed RTM they will not be available.
Do you get an error when running the cmdlet? Have you tried specifying in the format -ConnectInterval “01:00:00″ instead? Are other cmdlets working ok? And are you running it from the Mobile Device Manager Shell (not the standard PowerShell shell)?
Hi Andreas,
If the two buttons are not available,how to finish the packgae creating, you know there is a step in the end of process to verify the signature
I didn’t get an error,I tried the format -ConnectInterval “01:00:00″,still no message appears.
I’m running it from the Mobile Device Manager Shell and I tried the two cmdlets:Get-MDMDevice and Get-MDMStatus -owner “feng”, they works correctly
Thank you
Feng
I have covered all the steps needed for software distribution in this article (was done on SCMDM RTM not SP1):
SCMDM – Distributing Software
If you’re not getting an error it should mean that it went through. Do you get the new value when running Get-DeviceManagementConfig? Note: it will not apply to devices before you have run “Update-MobilePolicyCalculation”, and the device has connected once. I’m assuming you followed these steps:
http://technet.microsoft.com/en-us/library/dd261788.aspx
Thx a lot, Andreas
I’ll try it
When i setup an pr-enrollment for device MDM Enrolment Server gives me this error:
Failed to send email after create pending enrollment request.
SendTo: name@domain.com
Error: System.Net.Mail.SmtpException: Mailbox unavailable. The server response was: 5.7.1 Client does not have permissions to send as this sender
at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response)
at System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, SmtpFailedRecipientException& exception)
at System.Net.Mail.SmtpClient.Send(MailMessage message)
at Microsoft.Mobile.ManagementServices.EnrollmentServer.AdminUtility.SendMail(EnrollmentRequest er, String sendTo)
The “quick fix” would beto uncheck the option to send an email to the user when enrolling – unless you need to use this of course. (If you are performing testing/evaluation this would probably be less critical.)
The default smtp configuration will not work, so you need to configure a working configuration. There are different options here – send through a generic smtp server, send through Exchange with differences if you’re sending to external addresses or internal addresses. The specific error you see here indicates that there is a permissions issue where the user trying to send does not have send-as permissions on the address being used.
i did the configurations on the smtp side and that is what i got after get-enrollmentconfig:
GatewayUri : 192.168.1.1
EnrollmentServer : name.domain.com
CertificationAuthority : CA.domain.com\Certificate CA
SetPasswordLength : 10
PasswordCharacters : 2
ExpirePasswordAfter : 08:00:00
Enabled : True
ForceEnroll : False
ActivateVPNbyDefault : True
SmtpServer : name.domain.com
EmailSubject : Auto email for pending enrollment
EmailBodyTemplate : Your mobile device has been enabled for enrollment to
the device management system. You should enter the fo
llowing details when prompted by the device enrollment
client:
EmailSender : name@domain.com
And the user have permissions at the Exchange server and the email address is valid.
I’m assuming that the smtpserver and the enrollmentserver is not the same server, and that it’s just a fake name in both fields? The user sending the mail is the user account used for SCMDM – not the user actually enrolling. Which basically means if you are using Exchange that the SCMDM account must have a mailbox. You have tested that the enrollment server is able to reach the Exchange server over port 25? (I don’t know how your Exchange is configured, but if you have multiple Exchange servers this might need to be the one hosting the hub transport role.)
Other than that the output from get-enrollmentconfig looks good.
Hi Andreas,
Thank you for the install guide published, I found it very useful.
I would like to know how can I block signed RAM applications in Windows Mobile. In theory, you can apply Windows PC Software Restriction policies by setting a Disallowed security level and adding to the whitelist the XML hash rules calculated with SCMDM Applications Hash Code Tool. I tried to set this policy in User and Machine Configuration but is not applied in the Windows Mobile Device. It has proper rights and delegations, because it belongs to the same GPO with Windows Mobile (mobile.adm) policies which are in fact applied successfully.
I followed the procedures explained in Applications Hash Code Tool Guide (Resource Kit – Server Tools) but no luck.
mobile.adm policies allow to block and configure whitelists of unsigned RAM applications. However, I’d like to block pre-installed signed RAM applications, such as Opera or TomTom.
Is there any way to apply Software Restriction policies in Windows Mobile with SCMDM?
Thank you.
Oh! My last comment was deleted?
I wanted to add that I was able to block signed RAM applications by removing all unmanaged (pre-installed) certificates from the PDA (GPO extensions allow to that) and activating the block unsigned applications policy, however it’s not a very elegant solution. At the same time I can install my own managed certificates in the PDA via GPO extensions so all RAM applications signed with this certificate will run.
This may be helpful for other SCMDM administrators so feel free to keep it posted…
I didn’t think the Group Policy behaved different when it came to blocking preinstalled apps depending on signing. But then I haven’t been testing it much either, as I usually get rid of the preinstalled apps in othere ways if necessary.
As far as I can tell from the docs on MSDN you don’t even need the hash of preinstalled apps to block. (If this is effective depends on whether the user is able to change the filename or not – some preinstalled files are write protected.)
If you are familiar with CSPs the following are of relevance:
Changing the block list:
http://msdn.microsoft.com/en-us/library/cc515001.aspx
Loader revocation:
http://msdn.microsoft.com/en-us/library/bb737649.aspx
When it comes to blocking Opera you’ll potentially open a different can of worms as many file extensions (like html, etc) are wired to open Opera.
Thank you Andreas. I will give it a look to CSPs. Now that I think it is true that it can very easy to modify a RAM executable in order to alter the hash code and avoid the blocking policy, I attempted to change TomTom’s .exe name and succeeded. The certificate revocation plus activating the block unsigned applications policy will do the thing but maybe getting rid of useless preinstalled applications is better.
Opera is installed in the system, but html files are wired to iexplore.exe and therefore blocked. I don’t have any problem with this file extension or others, these are blocked for sure.
Thanks
Hi,
Just want to check, is it possible to enroll 2 different device with the same username/account in scmdm?
As long as the devices have unique names a single user can have plenty of enrolled devices.
Hi Andreas,
Finally I couldn’t remove unmanaged certificates to block pre-installed RAM because my own application included some Visual Studio .dll that used these certificates too.
I gave it a look to CSPs and was able to unistall TomTom and Opera by using XML Provisioning. I created a setup .dll and embedded the XML code following this tutorial, then created a CAB file and installed it remotely via SCMDM/WSUS. One the cab is installed, the setup .dll is executed and the RAM applications are uninstalled successfully.
Thank you very much for the clue.
Cheers.
Some times one has to be clever creating workarounds
Glad to be of help if I pointed you in the right direction
Thank you Andreas… I setup and configured my lab exactly as your instructions except I installed MDM SP1.
The BPA Predeployment and Postdeployment test returned no errors. However, the Active Directory Validation had one error on the MDM Instance Property; Keyword portalurl was not created.
I have not found any reference to this error.
Then, when I do the device Pre-Enrollement and select a user from AD then click the CREATE button, it gives the following error;
Error Contacting Server https://mobileenroll.domain.com:8445/MDM/enrollmentadminservice/admin.armx
The request failed with HTTP status 401: Unauthorized
I am a domain admin and also in the SCMDS Server Admins group.
I don’t know where to look for this or whether the AD Validation error is related to the failure to Pre-Enroll the device.
I would be most grateful for some direction.
Further troubleshooting, I attempted to access the enrollment directly through https://mobileenroll.domain.com:8445/MDM/enrollmentadminservice/admin.armx and I get a message indicating that I am not authorized. I am a domain administrator as well as a member of the scmdm server and security groups.
If I try to access the link from the hyper-v host (also a machine on the virtual network) I do get access to the Enrollment Admin web site with several links to enrollment administration . However, if I select any of the links it tells me that “this test form is only available from the local machine”.
The AD error regarding the portalurl not being created sounds like it’s related to the self service portal although I have not seen that error before. (In MDM SP1 the portal is included by default, wheras in RTM it was an optional download.) While this might mean that the SSP is not working it should not affect the enrollment.
Provided you aren’t trying to run them both on port 443 or a similar conflict. The SSP can be run on a different port, but the enrollment site needs to run on port 443 for devices to be able to enroll. Port 8445 is for the admin part of it, and it is correct that some of the web service methods can only be run from localhost. I have another post detailing how the web services work, and how they can be used.
Are you running multiple MDM roles on a single box (like in my test scenario) or have you split the roles over different boxes? Are you running the DC and MDM on the same server? This may create access issues. I cannot remember any issues using the domain admin account for administrating the MDM servers as long as this account is also a member of the MDM groups. (Remember to logout and login for the membership to apply.) I usually attempt device enrollment with a normal user account though.
If I were to troubleshoot the issue I’d have a crack at the following steps:
- Check Event Viewer for any suspicious error messages.
- Check that you have the correct DNS entries. Records for mobileenroll, for the SSP, for MDM, etc. You can have multiple records pointing to the same IP address.
- Double check that certificates are installed, and are valid.
- Check IIS that the host names apply to the correct web site, the correct ports, and that there are no conflicts in the IIS setup.
If all is good you could attempt a repair install of the enrollment role.
Thanks for the reply. I’ve been pulled into another project. I’ll get back to MDM in a couple weeks, I hope.
I’ve run into a snag that despite putting a substantial effort into searching through on-line and performing some tasks suggested therein, I’ve been unable to resolve. Any pointers of where to look would be appreciated.
When I go to enroll a device I receive the following:
Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00
Enrollment Data
Failed
Error:
You are not authorized to perform this action.
Mobile Device Manager Shell command attempted:
New-EnrollmentRequest -Owner ‘CN=Domain Username Removed,CN=Users,DC=domainname,DC=ca’ -Name ‘TouchPro2′ -Container ‘OU=SCMDM Managed Devices (ALLSOL),DC=domainname,DC=ca’
Elapsed Time: 00:00:00
—
BPA comes back with 4 warnings that are performance related (I’m setting the servers up in VMWware (SCMDM = 2003 x64 Enterprise / Cert Server on Server 2003 x86) such as low ram, disk space, and processor speed. Everything else has green checkmarks.
I’m running MDM Console as Aministrator and have ensured that account is part of the 5 crucial SCMDM groups and Domain Admins.
Well seems I missed a step in a technet article in while you linked to, heh.. I’m up and going; however, I am unable to get my phone (Touch Pro 2) to enroll. I’ve entered the credentials as per the pre-enrollment wizard, but get:
“We are unable to localte a server successfully, but enrollment could not complete. Verify your e-mail address and enrollment password, and then try again.”
I’ve entered the information correctly..
Hold on, you’re nearly there by now – it’s no fun if you don’t run into a couple of obstacles along the way
When it fails during enrollment with an error like this the steps you should check are:
- You have a valid SSL certificate for the enrollment site. (Should be fixed during install but you never know.)
- If you don’t use mobileenroll.contoso.com as the address you will need to type it in manually on the device.
- The certificate will be checked so if you type in 192.168.x.y it will fail if the certificate isn’t issued to this name.
- Are you using multiple domain names and e-mail addresses? Always test using the primary address if you’re having problems.
Still no go? You could test the webservices on a desktop to see if you are eligible for enrollment.
Hi Andreas,
I have followed through all the steps but I seems to be having a problem connecting to the enrollment server from the mobile emulator. I came across a tool called EM IP Utility, installed it on the emulator and scaned it for assigned IP but the IP assigned to it is wrong. I have enabled the NE2000 PCMCIA network adapter and bind it to the VMWare Accelerated AMD PCNet Adapter.
Any reason why the emulator is not picking the IP address assigned to the server?
Assigned IP is 192.168.55.101
Expected IP is 192.168.10.xxx
I’ve posted a reply over at the TechNet SCMDM forums:
http://social.technet.microsoft.com/Forums/en-US/SCMDM/thread/262dfe22-e334-42a4-afc8-de82fcd8c650
I am trying to connect a iPhone to the MDM (while this may not work) when I run the device emulator for a windows mobile phone I do not seem to have the “domain enroll” in the settings of my device. When I try and put the server address in manually I get the iis website, but it never has a box or anything that pops up wanting a un and pw. It looks to be more of the “test” site with “shouldenroll” links and “enroll” links etc. I am sure you guys know the one. What am I missing? Do I have to use the domain enroll feature? The MDM sends me the email etc. It seems like to me I am just missing one step somewhere … any help still out there? Thanks James
As a followup, I followed the guide on technet you posted
Andreas
Mar 12th, 2009 at 5:06 pm
I’d follow the steps in this article: . Start out with the “Unable to Enroll Device in Domain” section.
with no luck. I am still holding out hope this can be done with a iPhone becuase I get the same website on my windows mobile emulated device that I do from a web brower on my iphone.
The iPhone will not work, so don’t spend any more time on that
You will not be able to enroll via the web page either – that’s just used for test purposes and a simple “instruction” to the web service. To enroll a device you will need the domain enroll feature, which is only available on WM 6.1/6.5. If you’re using the Windows Mobile emulator and can’t see this icon check with OS version you are using. If it’s WM 6.0 or earlier it is not present.