As has been the case with recent versions of Exchange Server, ActiveSync is based on the use of Internet Information Server virtual directories. And just like any virtual directory, you can customize certain settings. Before doing so, it's important to understand a major architectural change Microsoft made in Exchange Server 2013 that could affect
In previous versions of Exchange Server, ActiveSync was tied to the Client Access server role. A Client Access server is essentially just a Web server containing a series of Exchange-specific virtual directories. One of these virtual directories provides ActiveSync functionality.
In Exchange Server 2013, Microsoft split ActiveSync functionality between the Mailbox server role and the Client Access server role. ActiveSync is still implemented through virtual directory use, but this change means Client Access servers and Mailbox servers each have ActiveSync virtual directories. As such, ActiveSync-related tasks are split between the two server roles.
The key to customizing ActiveSync-related virtual directories in Exchange Server 2013 is to know which settings correspond to the Mailbox server role and which settings correspond to the Client Access server role. You also need to know how to use the Exchange Management Shell to make changes.
Microsoft provides a list of the ActiveSync settings specific to each server role. The specific Client Access server role settings include:
These ActiveSync virtual directory settings exist on Client Access and Mailbox servers:
Although having a list of the names of the settings is handy, it won't do much good unless you know how to view and edit the settings. Some of these settings can be accessed through the IIS Manager, but it's generally easier to use the Exchange Management Shell.
Manipulating the settings requires you to know the server and virtual directory names. You can retrieve this information by entering the Get-ActiveSyncVirtualDirectory cmdlet. The cmdlet will return the virtual directory name, the server name, and the internal URL the virtual directory uses.
The Get-ActiveSyncVirtualDirectory cmdlet can sometimes cut off the virtual directory name. If you find the information you need is cut off, use this command instead:
Get-ActiveSyncVirtualDirectory | Select-Object Name, Server, InternalURL | FL
You can use this same basic technique to retrieve the current status for any of the settings previously listed. For example, if you wanted to determine whether basic authentication was enabled, you could use the following command:
Get-ActiveSyncVirtualDirectory | Select-Object Name, Server, BasicAuthEnabled | FL
If basic authentication is enabled for the virtual directory, Exchange will return a value of true (see Figure 1).
You can append the setting name of an ActiveSync virtual directory to the Select-Object section of the command listed above.
But what if you want to disable basic authentication? You'll need to specify the identity of the virtual directory. For that, use the Set-ActiveSyncVirtualDirectory cmdlet instead of the Get-ActiveSyncVirtualDirectory cmdlet. The command looks something like this:
Set-ActiveSyncVirtualDirectory –Identity "<server>\<virtual directory name>" –BasicAuthEnabled;$False
You would replace <server> with your server name and <virtual directory name> with the name of your virtual directory. You could also use this command to disable basic authentication on a lab server (see Figure 2).
After manipulating an ActiveSync setting this way, use the Get-ActiveSyncVirtualDirectory cmdlet to verify that the new setting was correctly applied.
It's relatively easy to apply changes to ActiveSync virtual directory settings. The key is to know which PowerShell commands to use and the settings each server role contains. If you try to manipulate a setting on the wrong server role, you'll receive an error message stating that the property is "read-only."
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.
This was first published in January 2014