As mentioned in the previous posts in this services, the configuration of Exchange ActiveSync was something that is commonly overlooked by many a consultant. Exchange ActiveSync allows any user to synchronise any device by default. If this is what your organisation wants to do, then you are good to go. If not, then changes must be made. The issue is that if you simply change the global ActiveSync DefaultAccessLevel and set it to quarantine, then if that was the only rule that allowed the device to access ActiveSync then the devices will be set to quarantine even if they had already successfully connected and configured themselves.
-
This post which covers background and my personal recommendations for ActiveSync global settings.
-
What can we do to automate such issues (this post)
Please see the earlier posts in the series for more details on the default configuration, and the issues caused if the DefaultAccessLevel is changed from allow to either blocked or quarantine.
In this post we want to look at how to easily grandfather all existing devices using a script prior to changing the DefaultAccessLevel. This allows currently synchronising devices to function after the organizational ActiveSync settings are changed.
Assumptions
The below are some assumptions made for the provided script:
-
You will take the below script and thoroughly test it in your test lab prior to executing it in production.
-
Script has received minimal testing. You acknowledge this and will thoroughly test it.
-
You do not have any other MDM solution in place. We are only discussing native Exchange ActiveSync management.
-
This is to grandfather in *ALL* existing devices that are currently synchronising. No exceptions. The default time value specified is 30 days. This can be edited as needed.
-
The intent is to run this to allow all devices currently synchronising access to Exchange after the DefaultAccessLevel has been changed.
- Script is to be executed prior to changing the DefaultAccessLevel.
-
Script is executed from an existing Exchange Management Shell session.
- Script is for Exchange 2010 and 2013.
-
Script is executed using an account that has the capability to make necessary changes
-
Minimal error handling is present. You can add it if required.
Script Logic
As discussed above, if we simply just change the ActiveSync DefaultAccesslevel then devices that are currently synchronising will be quarantined if there is not other rule to allow them access. To work around this we can either create rules to match all of the existing devices, or grandfather in all current devices. The approach to take will depend upon how your organisation wants to manage devices. The intent with this post is to grandfather in all of the current devices. This will not be done using access rules, rather each device that is currently synchronising will be added as a allowed device to that specific user. This allows for flexibility when creating new device rules.
Note that the above paragraph said “currently synchronising”. Users will have devices associated that have not synchronised in months or years, so the script has an option to ignore devices that have not synchronised for a configurable time period.
Script Download
Download the sample script from the TechNet scripting gallery.
Please leave comments and feedback as a comment to this blog post or as Q & A on the scripting gallery.
Cheers,
Rhoderick
The default settings in Exchange 2010 and 2013 allow any user to synchronise any device. Depending upon
It has been 5 years since Exchange 2010 was released and there is still a very common item that a lot
Rhoderick, thanks for this excellent script. We are most likely going to use it in our organization. I had a quick question about what the end user experience will be like for a user that has both a device that is currently synchronizing, and one that
is old and not synchronizing. Will they receive an email from exchange about their old device, or is that email only generated upon the device talking to exchange?
Thanks,
Ed
Hi Ed,
I don’t recall seeing mails referring to the old device when I tested this. I assume that email would be fired when the device tries to connect when it is dusted off and attempts to sync.
Cheers,
Rhoderick
We have XenMobile 9 in place but also use a Mail Manager that takes advantage of Exchange 2010 quarantine mode and in turn we have to change our default access from Allow to Quarantine and was very happy to find this post from a technet blog vs random
sites on the web. I’ll post a follow up once we try this out this week.
thanks for the post! also.. why hasn’t microsoft realized that most companies that have devices syncing prior to changing this setting WOULD ALWAYS WANT TO HAVE THEM MARKED AS ALLOW…? i understand best practices but why can’t Microsoft understand realistic
practices that us admins have to abide by? example, Group Policy.. why can we have an option to set a value as default but still allow user to modify (ie trusted websites in IE)??
Back on topic, thanks for the info!!!!
This should work for 365 also right?
Yes, one of my colleagues has used it for 365.
Cheers,
Rhoderick
Thanks for blazing fast reply
that’s what I thought, might change it to not get the "use the new get-mobiledevice…" warnings
Thanks again
Yes that was a decision so it would just work with 2010, 2013 & 365 without doing version checking.
Cheers,
Rhoderick
Hello, we have a MobileIron in place for our mobile devices and we are looking forward to block our Active Sync via exchange – I see the script but in assumptions it says no MDM in place. What can we do to in place exchange active sync with third party
MDM and not interrupting existing users when we enable the policy.
Thank you
How exactly is MobileIron allowing or blocking devices right now? Is it configured to allow/block the device in Exchange?
Cheers,
Rhoderick
In Exchange I have not configured anything for Active Sync and it is all Allowed. From Mobile Iron it is not blocking or quarantine any device. We don’t have the Mobile iron server – we are only using the Core system to install mobile iron on client device
and manage emails from our company. We can only Retire and wipe our users phone via mobile iron but we don’t have any blocking from mobile iron.
Thanks for these posts, very helpful! I have a question though, I wish to quarantine all devices but I dont have a test environment so Im not willing to run this script. I do have a list of all devices which we have authorized access for. If I set the
policy to quarantine, I assume its just a case of manually allowing all those devices to connect, is this correct?
Cheers,
Dave
You really should get a lab provisioned Dave – that’s how we should roll……….
If you look at the second post in this series:
http://blogs.technet.com/b/rmilne/archive/2015/01/26/impact-of-changing-activesync-defaultaccesslevel.aspx
it goes through the 9 steps in the EAS connection process.
If the only thing allowing the device to connect is the global allow setting, then setting that to quarantine will mean that you have to approve the devices one by one.
Alternatively you create device access rules which can allow certain device types to connect, or blocked.
Cheers,
Rhoderick
Thanks Rhoderick! A lab environment is on its way but I need to lock this down ASAP. I wanted to make sure I could approve after (as opposed to reconfigure) . Its only 70 or so staff and I have a list so its not a huge task.
Hi,
great post thank you.
i do have a quick question if you could possibly help.
every device that we currently have configured with ActiveSync has a policy that is applied upon allocation of the device, the IT department helps with the initial setup after applying the policy, so the device immediately requests a user sets a PIN number
on the device.
if i were to now add a quarantine devices policy, via the ECP portal, would this effect all currently configured devices, or just any newly added devices?
i would basically like to control all newly added devices as BYOD seems to be heading in strong, and bring some process into the department.
Regards
G
G – Depends upon what device rules you have deployed. If you look in this series of posts, you will find the steps that the EAS client request goes through when it connects in. If you change the rule applying to the device it will then apply.
Cheers,
Rhoderick
hi mate,
what does the script above actually do? will it not touch the existing devices??
Hi Ramkumar – take a look at the details in the post. It should answer the question.
Cheers,
Rhoderick
Couple of Questions if I may
If I Have about 1,000 devices, how long do you think it would run for?
After it runs, how do I check an account to see if it is grandfathered?
Thanks
Doug
Hi Doug,
It should run in a matter of minutes.
You can check the individial mailbox to check what devices are statically allowed.
Cheers,
Rhoderick
Rhoderick, thanks for this excellent series of articles.
Are the information above valid for devices that rely on REST API to connect to Exchange Online?
Thank you. Nico
I have a question regarding this script. I am using this against Exchange Online logged into my powershell session of course. When I run this script it works and finds roughly 257 users to grandfather in which is great. But, its not seeing all the enabled ActiveSync devices and I have 443 active users. I did a comparison of one user that was successfully grandfathered in and one that I know of that has ActiveSync enabled just like the grandfathered in device/user and I see no difference. I don’t have any policies in place, its set to Allow all devices.
I cannot figure out for the life of me why it’s only pulling some and not others, any ideas or maybe the script is out of date? I am not the greatest on PowerShell, but I sure try. Thanks