Exchange Server Connector (for SCCM)

I was “given” the task of finding an easy way for the IT supporters to check whether or not a user has configured his/her mobile phone (Nokia Lumia) against our Exchange server. We’re checking this mostly because the user agreement states that every user should have an Exchange account configured. With an Exchange account configured, it’s possible (for the Exchange/SCCM Admins) to remotely wipe the phone (among other things).

The Exchange Server Connector is by no means a full blown MDM solution (for SCCM), but it can handle the basic tasks. If you want a solution with all the bells and whistles, have a look at Microsoft Intune instead. On the positive side, Exchange Server Connector is free and Intune is not. Some differences between the MDM solutions can be found here for example:

The above links include tables which will help you decide what mobile device management methods support the mobile device platforms you have in your environment. They can also help you decide between in Depth vs. Light Management and so on. All in all the links gives you an idea of what you can and cannot do with the Exchange Connector.

The short version is that SCCM 2012 (R2) is out-dated in terms of MDM management. You only have support for limited devices by default, check: (Mobile Devices Enrolled by Configuration Manager and Mobile Device Legacy Client). By adding the Exchange Server Connector you’ll get support for more devices (all Exchange Active Sync devices), but the configuration on these devices is limited to the same things that can be configured on the Exchange Server (“light management”). The settings are listed in the table “Choose a mobile device management solution based on management functionality” from the page . As you can see, you can’t install software or make a software inventory but things like Remote wipe and settings management are possible. I’ll attach a screenshot of the things you can configure:


Fig 1. Mobile device access (EAS settings)


Fig 2. Mobile device mailbox policies

These same settings apply to SCCM once you have the connector set up correctly. That said, let’s set it up!



First some reading for you all:

I used tips from the guides but overall it was an easy task. Here are my steps:


Fig 3. Accounts in SCCM

  • Started SCCM, then navigated to Administration –> Overview –> Hierarchy Configuration –> Exchange Server Connectors


Fig 4. Exchange Server Connector.

  • Added a new connector with the default values. Properties from the newly created connector below:


Fig 5. Properties, General

Note: There are problems with the URL if using load balancers. I had to change the URL to one of our CAS servers (and not pointing to the single namespace/autodiscover URL in DNS). Check the problems and gotchas-chapter below for more details.



Fig 6. Properties, Account



Fig 7. Properties, Discovery



Fig 8. Properties, Settings

If you change a setting here, that setting will be changed from Configured by Exchange Server to Configured by Configuration Manager from now on. In other words, you are giving the SCCM server authority to handle these settings instead of Exchange. Also note the “Allow external mobile device management”: xxxxx” –option, and read the text above it. I changed mine to Allowed.



Fig 9. Properties, Access Rules



Theoretically everything should now be set up and working. Unfortunately, that wasn’t the case for me. I immediately noticed that no devices showed up under “Devices/All Mobile Devices” in SCCM. I had configured all steps correctly, and SCCM didn’t complain. Luckily there are logs (EasDisc.log on the SCCM server) so you can have a better understanding what’s going on behind the scenes. That said, I noticed some problems in the log straight away:


Fig 10. EasDisc.log: the problems

Some googling led me to Someone had a similar setup and suggested using the FQDN of one of the CAS servers instead of the NLB URL. Tried that – success! 🙂 (almost…)


Fig 11. EasDisc.log: problem solved, everything looks good. Log also reported INFO: Total number of devices discovered 357       SMS_EXCHANGE_CONNECTOR        x.x.2015 11:57:48 which is not visible in the screenshot.


View from SCCM

Let’s have a look at the whole thing in action from SCCM:


Fig 12. All Mobile Devices.



Fig 13. Another view



Everything APPEARED to be working fine now. After a while I noticed it wasn’t. I configured a test-device with my own account, but it DIDN’T show up in Assets and Compliance –> Overview –> Devices –> All Mobile Devices in SCCM (Fig 11). However the list with All Mobile Devices (Fig 10) got updated (correct number of devices). Very strange.

Some head scratching and googling later I ended up at

Well, well, well. Problem with load balancers. Duh. My solution: Added another connector for our second CAS. Well, that didn’t work. It was still showing the same amount of devices 😦 My test-device wouldn’t show up either. It was now unfortunately time to state that the Exchange Connector won’t work if you have more than one CAS in your environment. Too bad 😦

Update: Currently I’m using an EAS device report script on the Exchange server for collecting miscellaneous information about mobile devices. More on that in a blog post later on…


Search queries in SCCM

(Even though the connector didn’t work as expected, I had already made a couple of queries before noticing the problem…)

It’s always nice to get a list of devices, but in most cases you’ll want to have the list sorted in some way. I was requested to sort our list by the Windows Phone OS. I used a slightly modified query from:


select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like “%Windows Phone%

Using this query, I got all Windows Phones listed:


Fig 14. Query for Windows Phones

Instead of using Reporting, I find it much easier to just mark the whole list and copy/paste it into Excel (or another document). Some sort of “export to .csv” right-click plugin for SCCM would be awesome though.