Category Archives: Client Access

How to Bypass MFA for Autodiscover and Activesync in Windows Server 2016 Using Access Control Policies

ADFS, Client Access, MFA, Office365

Had trouble finding any info on this besides using the version of ADFS that comes with 2012 R2, configuring the exceptions through powershell. In ADFS in Windows Server 2016, you can know utilize Access Control Policies to configure rules around how users authenticate to ADFS. In our setup, we have a classic example where when client’s are in the office, they should automatically login using Windows Integrated Authentication (essentially that they are not prompted for credentials). When the users are not on the corporate network, they should be forced to utilize Multi-Factor Authentication (MFA for short).

Note there are some requirements for this setup.

  • You need to have ADFS deployed utilizing an ADFS proxy server to the internet (or some other proxy that can add the required headers to the internet based requests)
  • If your using multi-factor authentication it is assumed you are using Modern Authentication on your Outlook Clients

If we open up ADFS MMC, navigate to Access Control Policies:



There are several pre-canned policies on the left, but we are going to create our own by clicking Add Access Control Policy in the upper right hand.

Give the policy a meaningful name and description, and then build your policy as follows:




Note that it works similar to a firewall rule. We have the most restrictive policy at the top. Meaning if a user is a member of the AD Group DualAuth in this case, and they are logging in from outside the corporate network, they will be forced to use multi-factor authentication. The processing of rules for that user will stop. The Permit Users is required for ALL other users to be able to login without issue from the Internet, but also to allow ALL users to login using Windows Integrated Authentication from within the corporate network.

The initial problem with this policy is that not all applications have the ability to perform multi-factor authentication. The classic ones or Exchange Activesync and Exchange Autodiscover. So we need to exclude those from this processing.

If we select our initial rule block and click edit, we can select under the except tab, the with specific claims in the request checkbox.



Next, click on the link in the word specific. Select the claims radio button. Under claim type, change this to read client application -> contains -> Microsoft.Exchange.Autodiscover. Add another row and change the Claim Value to be Microsoft.Exchange.Activesync.



Hit okay, save your changes and your good to go!

Book Review: Citrix XenMobile Mobile Device Management by Akash Phoenix

ActiveSync, Client Access, Netscaler, Security, Xenmobile

I reviewed the book, Citrix XenMobile Mobile Device Management by Akash Phoenix, published by PACKT Publishing. The book is about one of the hot issues in the world of IT, BYOD and/or Mobile Device Management.  The appropriate audience for this book would be Director level’s, or Engineers who are brand new to XenMobile.  Engineers that are looking for a much deeper 300 level, technical deep dive will most likely be disappointed with the material however, as it serves as an introduction and 1,000 foot view of what Citrix XenMobile product can do. 

The book starts out with a good explanation of the different components that make of XenMobile, which frankly can be difficult to understand and grasp their function.  The book better explains in a concise, business fashion which components are required based on business needs than most of Citrix’s own materials do.

The author does a good job of explaining and walking through the basic installation, and also does a good job of explaining App Controller, which is generally a difficult topic to grasp for admins. I would have liked to see more info on the session policies for AppController with Netscaler but, the book is clearly a higher level overview versus the nitty gritty details.

Overall, Akash does a great job of explaining what XenMobile does, the components that make up the XenMobile solution, and how your individual business needs will drive your implementation design and requirements. It also does a good job of explaining the flexibility that XenMobile gives you, as well as an understanding of the overall capabilities of the system. For technical deep dives on each topic however, you may need to augment it with outside resources to get the complete picture.


Here is a link to the book so you can purchase it directly from Packt: 

And here is a link to some of the XenMobile resources on the site:

How to Install XenMobile 8.6 with XenMobile Netscaler Connector and XenMobile Mail Manager–Part 4

ActiveSync, Blackberry, Client Access, Exchange 2010, Exchange 2013, Hosting, Netscaler, Security, Xenmobile

See the previous posts in the series:

Part 1

Part 2

Part 3


In this post, we will configure the XenMobile Netscaler Connector and configure the Netscaler itself to query the Netscaler Connector on ActiveSync Connections. 

Lets download the Netscaler Connector from


Copy the installer to PHDC-XENNC01.  We need to ensure that we have Net Framework 3.5 installed before we install Netscaler Connector.  But once that is done, lets begin the install.

This is a very simple, next, next finish install:


Next, lets run the XenMobile Connector Configuration:

On the Web Service Tab, select HTTP and leave it as the default port of 9080


Next, go to the Config Providers tab and click add.  Fill out the information for your Device Manager Server:


Leave everything else default and click save.

Next navigate to the Path Filters tab. Select the only path there, and select edit.

Change the policy to be Static + : Block Mode


What this does is tell the system that it will check local rules on the Netscaler Connector, then the Device Manager.  If neither of those rules apply, it will deny the connection. 

After you have made your changes, start up services.msc and manually start these three services:


Next, we configure the Netscaler to check in with the Netscaler Connector during ActiveSync connections.

Log into the Netscaler and go to Service Groups.  Select Add.  Name it NETSCALER-CONNECTOR

Add in your netscaler connector IP and set the Port to 9080, and protocol HTTP


Next go to Virtual Servers and click add to create a new one.

Name it NETSCALER-CONNECTOR, select the protocol as HTTP.  Also uncheck “Directory Addressable” which will clear the IP address and port.  This is completely expected.

Add the service group you created to the server:



Next go to AppExpert->HTTP Callouts->Add

Create the name as active_sync_filter.  Set the virtual server to the NETSCALER CONNECTOR server you created earlier.


Click on Configure Request Attributes:

Method –> get

Host Expression – > “callout.asfilter.internal”

URL Stem Expression-> “/services/ActiveSync/Authorize”


user-> HTTP.REQ.HEADER(“authorization”).AFTER_STR(“Basic”).B64DECODE.BEFORE_STR(“:”).HTTP_URL_SAFE

agent –> HTTP.REQ.HEADER(“user-agent”).HTTP_URL_SAFE







Under Server Response:

Return Type –> Text

Expression to extract data from the response –>HTTP.RES.BODY(20)


Now, create a second callout called active_sync_filter_deviceid.  Create everything identical to the callout active_sync_filter, except under Parameters, add one additional


Next go to Responder->Policies->Add

Create a new policy named active_sync_filter

Select Action = Drop

Expression equals below:


HTTP.REQ.URL.QUERY.CONTAINS("DeviceId") && HTTP.REQ.URL.STARTSWITH("/Microsoft-Server-ActiveSync") && HTTP.REQ.METHOD.EQ(POST) && HTTP.REQ.HOSTNAME.EQ("callout.asfilter.internal").NOT && SYS.HTTP_CALLOUT(active_sync_filter).SET_TEXT_MODE(IGNORECASE).CONTAINS("allow").NOT


Create a second policy named active_sync_filter_deviceid

Again, set the Action = Drop

Expression equals below:

HTTP.REQ.URL.QUERY.CONTAINS("DeviceId") && HTTP.REQ.URL.STARTSWITH("/Microsoft-Server-ActiveSync") && HTTP.REQ.METHOD.EQ(POST) && HTTP.REQ.HOSTNAME.EQ("callout.asfilter.internal").NOT && SYS.HTTP_CALLOUT(active_sync_filter_deviceid).SET_TEXT_MODE(IGNORECASE).CONTAINS("allow").NOT 



Okay, hang in there, we are almost done.  Now, we need to find our Exchange Load Balancer server in the Netscaler.

Navigate to the Policy tab, select Responder.  Add the policies so that active_sync_filter_deviceid is lower number priority than active_sync_filter


Okay, that’s enough for now.  Next time we will configure Device Manager to deny certain devices based on set criteria and test it out!

How to Enable MAPI over HTTP (MAPI/HTTP) in Exchange Server 2013 SP1

Client Access, Exchange 2013, Managed Availability, Netscaler, Security

Decided to take the new SP1 for a spin tonight in the lab, and the first thing I wanted to play with was the new MAPI over HTTP functionality introduced in SP1 for Exchange Server 2013.  There are a couple of things we are going to need to get this setup:

There are a couple of things to note. 

  • Currently the ONLY Outlook clients that support this are Outlook 2013 SP1
  • There CAN be issues connecting to Public Folders if they are NOT running on Exchange 2013 Modern Public Folders (more on that later)
  • There can be issues connecting BACK to Exchange 2010 mailboxes through Exchange 2013 SP1 CAS servers if you JUST have MAPI/HTTP enabled.  RPC over HTTPS or Outlook Anywhere is here to stay for a bit.

Alright, so let’s set this up.  It’s actually really simple.  First, on your Exchange 2013 SP1 CAS servers, note that we have a new virtual directory named MAPI:


Okay, so open up the Exchange Management Shell.  We can inspect the setup of the MAPI virtual directory with the new Get-MapiVirtualDirectory command:



So, the first thing we need to do is configure the directory.  We need to set the URL’s and the authentication method.  In our case, we will set both the internal and external url’s to and the IISAuthenticationMethods to NTLM and Negotiate.  In my lab the name of my CAS server is PHDC-SOAE13CAS1.  So my command looks like the following command:

Set-MapiVirtualDirectory –Identity “PHDC-SOAE13CAS1\mapi (Default Web Site)” -InternalUrl –ExternalUrl -IISAuthenticationMethods NTLM,Negotiate



Next thing we should do is reset IIS.  Remember this will cause a disconnect so run it after hours:

IISRESET /noforce

After that is completed, we need to enable MAPI/HTTP for the organization.  Ensure that this will not cause issues in your Exchange Organization before you do it.

From the Exchange Management Shell run the following command:

Set-OrganizationConfig -MapiHttpEnabled $true


If you have an existing Outlook 2013 SP1 session open, you will most likely see the message: “An Exchange Administrator has made a change that requires you to restart your outlook”.

After you restart it, and go to connection status (hold the Control Key and right click the Outlook icon) you should see a set of connections using “HTTP” instead of “RPC/HTTP”.  RPC/HTTP is Outlook Anywhere, where HTTP is MAPI/HTTP.



Notice all my connections are going to Server name and using the Protocol HTTP.

If you check the Autodiscover Log we will see there is a new provider from Autodiscovery:


Notice the Protocol is Exchange MAPI HTTP.  You can see the Exchange HTTP below it.  Exchange HTTP is Outlook Anywhere, where Exchange MAPI HTTP is the new MAPI/HTTP.

What else is interesting is if we go to the Outlook Anywhere Settings we see the screen is now removed from Outlook:

Outlook 2013 SP1 using MAPI/HTTP:



Outlook 2010 using Outlook Anywhere:


Note that the connection tab is missing.

Also, remember how I said you MAY have connection issues to legacy based Public Folders?  Well in my lab, I still have Exchange 2010 running public folders.  And since I have Outlook Anywhere, Outlook actually created one Outlook Anywhere connection for Public Folders:


Notice how the proxy server is “”, the server name is PHDC-SOAEXC01, which is my Exchange 2010 Mailbox Server with a legacy public folder database.  Lastly note the protocol is RPC/HTTP.  Now, I in NO way think this is ideal, as we are straddling not only two protocols (MAPI/HTTP and Outlook Anywhere), two namespaces ( and, but look at the screenshot.  We are using two separate authentication methods where MAPI/HTTP is Negotiating, where Outlook Anywhere is using NTLM.  Care should be taken again to ensure your organization can properly support connections so that they are using one or the other.

I also checked and of course the new MAPI virtual directory does respond to the Managed Availability URL check.  This can help when using load balancers that do health checks like the Citrix Netscalers.  I outline that in my article here (  If you go to https://hostnameofyourcas/mapi/healthcheck.htm and everything is working, you should get a 200 OK response back:


Lastly, if you want to disable Outlook 2013 SP1 from using the new MAPI/HTTP for any reason, you can do so using the registry.  Create the following key:


Create a new DWORD value named MapiHttpDisabled and set the value to 1

You can also use that to troubleshoot.  If for some reason MAPI/HTTP is not working, check that key.  If its set to value 1 and you want to ENABLE it, you can do so by setting the value to 0.  If you need to mass deploy this you can so with a script, or Group Policy.

We will see how the performance of the new protocol works, as well as any other changes that need to happen as a result of this new architecture.

How to Install XenMobile 8.6 with XenMobile Netscaler Connector and XenMobile Mail Manager–Part 3

ActiveSync, Client Access, Exchange 2010, Exchange 2013, Netscaler, Xenmobile

See the previous posts in the series:

Part 1

Part 2

Part 4

In the last article, we installed Device Manager.  Now we will configure basic policies and settings.  Log into your instance by going to http://servername/zdm


You will get treated to a “Getting Started with Device Manager” screen which will allow you build the basic policies.

Select that you are not using App Controller:


Leave the Base Package as the name:


Select the Passcode bubble to add to the policy, then configure the passcode you want to configure:


Select Yes, enroll in corporate credentials:


This will bring you to the LDAP directory screen:


Configure your active directory connection.  Ensure to enter a user account that can read from the directory, it only needs to be a Domain User:


Select Next, accept the defaults for the LDAP attributes import:


At the groups to add, you need to select two groups.  One that can be admins of the XenMobile Device Manager server. And the other that can enroll their devices.  We will use Domain Admins to Administrator, and Domain Users to users:


Select Next and then Finish.  The Test Enrollment Screen will show you how you can test from mobile devices:


Click Next->Next-> Go to Device Manager.

Now, we need to configure the Netscaler to present the Device Manager server to the internet as

Log into your Netscaler and go to Traffic Management->Load Balancing->Service Groups

Click Add.  Give a name for the service group, for example XENMOBILE-DEVICEMANAGER-443.  Choose Protocol as SSL Bridge.  Add PHDC-XENDM01 to the members, and select Port 443


Save the group.  Make sure to do the same thing for port 8443:


Finally, create one for HTTP as the protocol on port 80:


Next go to Virtual Servers and click Add:

Create a name for the virtual server, and select Protocol as SSL Bridge, and the Port as 443.  Assign it an IP address.  On the service groups tab, select the service group you created above:


Do the same thing for port 8443:


Finally create the virtual server for HTTP and select the HTTP protocol and service group


Next, point your DNS to the IP address you assigned the load balancer and see if you can resolve the web page.  Remember, you need ports 80, 443 and 8443 open from the external world to the Device Manager Server.

In the next article, we will install XenMobile Netscaler Connector and attach it to the XenMobile Device Manager.

User’s Cannot Log into Exchange 2007 or Exchange 2010 OWA with UPN Suffix

Client Access, Exchange 2010, Hosting, Resource Forest


Lets say you have the following environment:


ExchangeResource.corp hosts all the Microsoft Exchange 2010 servers, and linked mailbox accounts.  The actual user accounts are stored in the Tailspin.corp and Mantech.corp forests.  The Tailspin.corp and Mantech.corp forests have a one way forest trust with ExchangeResource.corp so that users in the Tailspin.corp and Mantech.corp forests can access their linked mailboxes in the ExchangeResource.corp domain.

Now to make things easy on the users, you set the OWA directory to use UPN suffix names instead of Domainuser:


This will allow users in Tailspin to login using username@tailspin.corp and users in Mantech to use username@mantech.corp.

Everything works fine, but then you add a UPN suffix to each individual forest that makes the UPN suffix match the users email address. Below is an example shown with the user Tom Jones in the Tailspin forest:


Now users in Tailspin login using and users at Mantech login using

A user goes to login with the new UPN and is greeted with an error message that they could not login:


But using the old UPN still works fine, so what’s going on?

Well, if we check the event logs of the DC in the ExchangeResource.corp domain we find EventID 6034 for LsaSrv in the security event log:


The DC is telling us that it does not know how to route the suffix.  It notes that it has been added to the forest tailspin.corp, as it learns it through the forest trust, but that the name suffix is not enabled.  It does very nicely tell us how to fix this.  Go to Active Directory Domains and Trusts->Right click on ExchangeResource.corp->Properties


Go to the Trusts tab.  Here you will see all the forests that you have trusts with.  Highlight the tailspin.corp forest and click on properties:


Navigate to the Name Suffix Routing tab:


Here we can see the new suffix has been added, it even has a status of “New”, but the Routing is disabled.  Highlight the suffix and then click Enable:


If you do not see the new suffix you created listed here, simply click the Refresh button and it should appear.

After hitting apply both names should be enabled:


Now if a user try’s to login, they should be all set!


Keep in mind you will need to do this each time you add a new UPN Suffix to one of the domains that are being trusted by ExchangeResource.corp.


Users Receive a Login Prompt After a Database Failover in Exchange 2010

Client Access, Exchange 2010, High Availability, Outlook Anywhere


When performing a database *over in Exchange 2010, especially a planned one, it is suppose to be as seamless as possible to the end user.  An Outlook user for example, will receive a small pop up informing them that the connection to Exchange has been lost, and their Outlook may hang for a couple of seconds before reconnecting and resuming normal behavior.

I recently ran into an issue where this was not the case.  Users would call the helpdesk as soon as a database failover was initiated with complaints that their outlook was prompting them for a login:

Jan. 2601 09.54

Well, needless to say this is not expected behavior.  After a little troubleshooting that involved a packet capture, it seemed that the Outlook clients were making an HTTPS call to the CAS servers at that moment.  Turns out it was an attempt to connect to them over Outlook Anywhere, and this was the reason of the login prompt.  When I checked the Outlook client, they in fact had the Outlook Anywhere Settings enabled.  This was due to Autodiscovery.  To check the settings in Outlook 2007 navigate to Tools->Account Settings->Change->More Settings->Connection  If yours is enabled, it will look like the following:

Jan. 2603 09.55

Under Exchange Proxy Settings, you’ll find the settings enabled:

Jan. 2604 09.55

Since these were internal clients, and had no need to use Outlook Anywhere, simple unselect the Connect to Microsoft Exchange using HTTP:

Jan. 2606 09.58

This will disable the Outlook Client from connecting.  The only issue is, if you use automatic profile generation through Group Policy, this leverages autodiscovery, so it will continue to put the setting back.  You can do one of two things.  The first is to delete the Outlook Anywhere provider using the Remove-OutlookProvider command, which is NOT recommended.  This will stop Autodiscovery from publishing Outlook Anywhere GLOBALLY. 

The second is to use Group Policy.  Create a blank GPO named something like Disable Outlook Anywhere Settings.  Download the Outlook Anywhere ADM template from here, and import it into the template under User Settings.  You’ll now have the Outlook Anywhere (RPC/HTTP) options available in Group Policy:

Jan. 2608 11.23

The only value you need to edit here is the RPC/HTTP Connection Flags setting:

Jan. 2609 11.24

Edit the setting, set it to Enabled and No Flags

Jan. 2610 11.25

This will disable the Connect to Microsoft Exchange Using HTTP in the outlook clients after its been applied, notice how its greyed out:

Jan. 2611 11.25

Once this GPO has applied to all your users, you should now be able to failover databases without the users receiving a log in prompt. 

Migrating Exchange 2007 ActiveSync to Exchange 2010. And why your Android may work but your Apple iphone / ipad may not.

ActiveSync, Client Access, exchange 2007, Exchange 2010, Security


When doing a migration from Exchange 2007 to Exchange 2010, one of the biggest item’s you need to watch out for is the migration of the ActiveSync environment, and be aware of how it can affect your end users.  You should also be aware of potential issues depending on the TYPE of active sync device you are using, as some will work, and other’s will have issues.

First we’ll start with the migration.  Our current Exchange 2007 ActiveSync environment is as follows:


Here, we have one internet facing site, the NY site.  There is a DNS record for the CAS server in NY, that points to the IP of the CAS server on the internet.  We have set the –externalurl to and the –internalurl to  Note that newyork2007 is the NETBIOS name of the CAS server in NY.  We set both of these values with the following command:

Set-ActiveSyncVirtualDirectory –Identity “newyork2007Microsoft-Server-ActiveSync” –InternalURL –ExternalURL

In London, we have set the InternalURL attribute to the local name of the server, but leave the ExternalURL attribute blank.  We do not populate the ExternalURL attribute because London is not accessible directly from the internet. 

Setting the –internalurl attribute updates the SCP in active directory, so that any system that query’s AD itself, will be able to return the internal URL the user should access.  For instance, in our above scenario, LON07 the user configures his active sync device from the internet.  He put’s in as the server address, which is the external DNS name of the NY CAS server.  The NY CAS server, as part of the Active Sync process, query’s Active Directory for the home mailbox of LON07, and then determines which site LON07 is in.  Since LON07 is not in the same site as the NY CAS, the NY CAS then returns the value for ExternalURL.  If we had entered a value here, such as, the users device would be redirected to it (as long as the device supported auto discovery, more on that later), and the user would connect, as long as that was configured properly.  In our case, since there isn’t, the NY CAS uses the InternalURL entry to determine what address the NY CAS should use to proxy on behalf of the LON07 user.  Essentially the NY CAS connects to the London CAS, and returns the Active Sync info to the users device, all seamless to the LON07 user.

Now, we start to introduce Exchange 2010 to the equation.  Microsoft’s high level recommendation is to create a new namespace, called and have this entry point to the 07 CAS, and slide the 2010 CAS into the existing namespace.   See the below diagram:


So we would need to reconfigure the –ExternalURL and –InternalURL attributes of the NY 07 CAS servers, as well as the NY 2010 CAS servers.  They can all be done by changing the values of the command listed earlier in this article.  The logic here is the same as 07-07 proxy.  If the NYC07 user enters in into his/hers server address on their ActiveSync device, the 2010 CAS server will query AD, and determine that he is a 2010 user, but in the same AD site.  It will then query to see if an ExternalURL setting is populated, in which case ours is.  That users device, if it supports activesync, will automatically be redirected to and their profile loaded, all seamless to the end user.

If LON07 enters in the NY 2010 CAS server query’s Active Directory, finds his mailbox is in another site, and checks to see if there is an ExternalURL entry.  Since their isn’t, like before, it proxies the connection to the London 07 CAS server, all seamless to the end user. 

Now, this is all great, but what happens if your device does not support auto discovery?  Some active sync devices don’t work properly with auto discovery, and in that case, Microsoft recommends that you manually change their profile to point to  Maybe not even that, but for security purposes you don’t allow external devices to use auto discover to determine the settings.  In this case, you again have to manually point those devices to  If you have any significant number of users, this can be insanely time consuming. 

Let me show you an example.  I had configured everything as it was in the above diagram.  I was configuring his active sync on an Apple iPad, a device that supports activesync.  Problem was, his account wasn’t working.  The following log file was taken from the NY 2010 CAS server for the NYC07 user, they are located at c:inetpublogsLogFilesW3SVC1:


Sep. 2801 15.56 Here, we can see that the NY 2010 CAS server is telling the device that it has the wrong URL, and is redirecting it to  This is because the device has advertised that it can do auto discover.  In our example, since auto discover is disabled, or because the device doesn’t handle auto discover properly, the user was getting a connection to server error on the iPad.

Now, with NO changes, let’s try configuring the same user, but not using the iPAD, but using Touchdown for the Android.  Now, all work’s without issue, here is the log files:


Sep. 2802 15.56

In this case, the configuration worked without issue.  Notice how it also says  This is because since Touchdown did not advertise to Exchange that it could do auto discovery, Exchange knew it would have to proxy the connection back to the NY 07 CAS server to allow this to complete successfully.

The funny thing is, if we were to configure LON07 on the iPAD it would work fine.  Why?  Because since the London 07 CAS server does NOT have a value for ExternalURL, Exchange knows it HAS to proxy to London 07 CAS for all London users.

So, we want the same behavior for the NY users on 07.  To do so, we simply need to clear the ExternalURLvalue on the NY 07 CAS server.  We would do so with the following command:

Set-ActiveSyncVirtualDirectory –Identity “newyork2007Microsoft-Server-ActiveSync” –InternalURL –ExternalURL $null

This would wipe out the ExternalURL value.  The downside to this, is that auto discover for this URL would not be included, so if you used Outlook Anywhere, or other devices to connect using Auto discover, it would cause issues.  If you didn’t though, for instance you disable auto discover, this fixes all your issues.  Now when you try to connect NYC07’s mailbox to the iPad, since there is no ExternalURL entry for the NY 07 CAS server, the NY 2010 CAS server is forced to proxy:


Sep. 2803 15.56

Now, all existing 07 users will continue to have access to their mailbox’s via active sync and will not need any changes when their mailbox’s are moved to 2010.

How to Lock Down Activesync Users to Specific Device in Exchange 2010 or Exchange 2007

ActiveSync, Client Access, exchange 2007, Exchange 2010


With the recent release of the Apple iPad, the new iPhone, not to mention the numerous Google Android phones available, there has been a dramatic increase in interest in using Exchange ActiveSync along with Exchange Server 2010 or Exchange Server 2007. 

Along with using these devices, comes certain questions regarding security.  One of those topics, covered by this post, is how to restrict end users to a specific ActiveSync device.  Some ActiveSync devices do not support certain features, that Exchange Admins may want to ensure don’t connect to their systems.

For this example, we’ll run the Get-ActiveSyncDeviceStatistics –Mailbox pponzeka command to determine the DeviceID of the users current ActiveSync device:


Jun. 2310 08.55

Note the DeviceID listed, 413030303030313542354533744.  This is akin to a serial number for this particular active sync device, its unique per device.  We can lock down this use, so that he can only use THIS device to connect to his mailbox via activesync.

To do so, we simple run the command Set-CasMailbox pponzeka –ActiveSyncAllowedDeviceIDs number1,number2

Jun. 2314 09.16

If we had multiple devices, you would just list both numbers separated by a comma.

If you ever want to remove the restriction, simply enter the null value:

Set-CasMailbox pponzeka –ActiveSyncAllowedDeviceIDs:$null


This will set this users mailbox back to the default of allowing all activesync device’s to connect!