Exchange ActiveSync Script To Grandfather Existing Devices


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.

  1. This post which covers background and my personal recommendations for ActiveSync global settings. 

  2. What is the impact of changing these settings when devices are already synchronising with your Exchange infrastructure.

  3. 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.

Download ActiveSync Script To Allow All Currently Synchronising Devices

Please leave comments and feedback as a comment to this blog post or as Q & A on the scripting gallery.

 

Cheers,

Rhoderick

Comments (22)

  1. anonymouscommenter says:

    The default settings in Exchange 2010 and 2013 allow any user to synchronise any device. Depending upon

  2. anonymouscommenter says:

    It has been 5 years since Exchange 2010 was released and there is still a very common item that a lot

  3. anonymouscommenter says:

    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

  4. 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

  5. anonymouscommenter says:

    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!!!!

  6. anonymouscommenter says:

    This should work for 365 also right?

  7. Yes, one of my colleagues has used it for 365.

    Cheers,
    Rhoderick

  8. anonymouscommenter says:

    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

  9. Yes that was a decision so it would just work with 2010, 2013 & 365 without doing version checking.

    Cheers,
    Rhoderick

  10. anonymouscommenter says:

    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

  11. How exactly is MobileIron allowing or blocking devices right now? Is it configured to allow/block the device in Exchange?

    Cheers,
    Rhoderick

  12. anonymouscommenter says:

    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.

  13. anonymouscommenter says:

    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

  14. 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

  15. anonymouscommenter says:

    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.

  16. anonymouscommenter says:

    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

    1. 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

  17. ramkumar nagaraj says:

    hi mate,

    what does the script above actually do? will it not touch the existing devices??

    1. Hi Ramkumar – take a look at the details in the post. It should answer the question.

      Cheers,
      Rhoderick

  18. doug says:

    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

    1. 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

  19. Nico says:

    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

Skip to main content