Category Archives: Exchange 2013

Cannot Update Exchange 2013 after Installing Exchange 2016 BETA

Exchange 2013, Exchange 2016, Role Based Administration

Recently ran into an issue where I couldn’t update my lab Exchange 2013 CU9 servers to Exchange 2013 CU10.  I wanted to do so because Exchange 2016 had gone RTM and one of the requirement’s for coexistence of Exchange 2016 and Exchange 2013, is for Exchange 2013 to be running at CU10.  One of things to note is that I had previously installed the Exchange 2016 BETA into my lab setup.

The error I got from the Exchange setup program was:

[11/06/2015 21:40:05.0247] [2] [ERROR] The given key was not present in the dictionary.
[11/06/2015 21:40:05.0247] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: The given key was not present in the dictionary.
[11/06/2015 21:40:06.0122] [1] The following 1 error(s) occurred during task execution:
[11/06/2015 21:40:06.0122] [1] 0.  ErrorRecord: The given key was not present in the dictionary.
[11/06/2015 21:40:06.0122] [1] 0.  ErrorRecord: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at Microsoft.Exchange.Data.Directory.SystemConfiguration.ExchangeRole.StampImplicitScopes()
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.PrepareRoleForUpgradeAndGetOldSortedEntries(ExchangeRole roleToUpgrade, Boolean isDeprecated)
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.UpdateCannedRole(ExchangeRole existingRole, ExchangeRole cannedRole, RoleDefinition roleDefinition)
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.CreateOrUpdateRole(RoleNameMapping mapping, RoleDefinition definition, List`1 enabledPermissionFeatures, String suffix, String mailboxPlanIndex)
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.CreateOrUpdateRole(RoleNameMapping mapping, RoleDefinition definition, List`1 enabledPermissionFeatures)
   at Microsoft.Exchange.Management.Tasks.NonDeprecatedRoleUpgrader.UpdateRole(RoleDefinition definition)
   at Microsoft.Exchange.Management.Tasks.InstallCannedRbacRoles.UpdateRolesInOrg(RoleNameMappingCollection mapping, RoleDefinition[] roleDefinitions, ServicePlan servicePlan)
   at Microsoft.Exchange.Management.Tasks.InstallCannedRbacRoles.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
   at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc)
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()
[11/06/2015 21:40:06.0169] [1] [ERROR] The following error was generated when “$error.Clear();
          if ($RoleDatacenterFfoEnvironment -eq “True”)
            Install-CannedRbacRoles -InvocationMode $RoleInstallationMode -DomainController $RoleDomainController -IsFfo
            Install-CannedRbacRoles -InvocationMode $RoleInstallationMode -DomainController $RoleDomainController
        ” was run: “System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at Microsoft.Exchange.Data.Directory.SystemConfiguration.ExchangeRole.StampImplicitScopes()
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.PrepareRoleForUpgradeAndGetOldSortedEntries(ExchangeRole roleToUpgrade, Boolean isDeprecated)
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.UpdateCannedRole(ExchangeRole existingRole, ExchangeRole cannedRole, RoleDefinition roleDefinition)
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.CreateOrUpdateRole(RoleNameMapping mapping, RoleDefinition definition, List`1 enabledPermissionFeatures, String suffix, String mailboxPlanIndex)
   at Microsoft.Exchange.Management.Tasks.RoleUpgrader.CreateOrUpdateRole(RoleNameMapping mapping, RoleDefinition definition, List`1 enabledPermissionFeatures)
   at Microsoft.Exchange.Management.Tasks.NonDeprecatedRoleUpgrader.UpdateRole(RoleDefinition definition)
   at Microsoft.Exchange.Management.Tasks.InstallCannedRbacRoles.UpdateRolesInOrg(RoleNameMappingCollection mapping, RoleDefinition[] roleDefinitions, ServicePlan servicePlan)
   at Microsoft.Exchange.Management.Tasks.InstallCannedRbacRoles.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
   at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc)
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()”.
[11/06/2015 21:40:06.0169] [1] [ERROR] The given key was not present in the dictionary.
[11/06/2015 21:40:06.0169] [1] [ERROR-REFERENCE] Id=361422192 Component=
[11/06/2015 21:40:06.0169] [1] Setup is stopping now because of one or more critical errors.
[11/06/2015 21:40:06.0169] [1] Finished executing component tasks.
[11/06/2015 21:40:06.0201] [1] Ending processing Install-ExchangeOrganization
[11/06/2015 21:40:06.0201] [0] CurrentResult console.ProcessRunInternal:198: 1
[11/06/2015 21:40:06.0201] [0] CurrentResult launcherbase.maincore:90: 1
[11/06/2015 21:40:06.0201] [0] CurrentResult console.startmain:52: 1
[11/06/2015 21:40:06.0201] [0] CurrentResult SetupLauncherHelper.loadassembly:452: 1
[11/06/2015 21:40:06.0201] [0] The Exchange Server setup operation didn’t complete.  More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.
[11/06/2015 21:40:06.0216] [0] CurrentResult 1
[11/06/2015 21:40:06.0216] [0] CurrentResult setupbase.maincore:396: 1
[11/06/2015 21:40:06.0216] [0] End of Setup
[11/06/2015 21:40:06.0216] [0] **********************************************


I opened up ADSIEDIT and navigated to the domain root->Configuration->Services->Microsoft Exchange->Organization Name->RBAC->Roles->Apps




Under Roles, there will be an existing entry named My ReadWriteMailbox Apps.


Delete this entry, or rename it (I renamed it to My ReadWriteMailbox Apps2).


After that, I re-ran Exchange 2013 CU10 Setup and everything completed as expected.  If you renamed the object above, you’ll see that setup recreated the proper role:




Notice I have my duplicated entry that I renamed alongside my newly created one.

Configure an Exchange 2013 DAG on Windows Server 2012 R2 With No Administrative Access Point

DAG, Exchange 2013, High Availability

Exchange 2013 SP1 introduced support for Windows Server 2012 R2, and also introduced support for a new feature in Windows Server 2012 R2, Failover Clusters without an Administrative Access Point.  You can now create a DAG, that does not need separate IP’s on each subnet for the DAG itself.  It also no longer creates the CNO which is seen as the computer account in Active Directory.  The benefit of this feature is that you reduce complexity, no longer need to manage the computer account for the DAG, and no longer need to assign IP addresses for each subnet on which the cluster operates.  There are some downsides, but it shouldn’t affect Exchange admins much.  Mainly, since there is no ip address and no CNO, you cannot leverage Windows Failover Cluster admin tools to connect to it.  You need to leverage local PowerShell against a cluster node directly.  With Exchange, this shouldn’t be too much of a problem as almost all of the management of the cluster is handled with Exchange tools through management of the DAG itself.

In our example, we have two servers in separate AD sites that we are going to configure in our DAG:



We will create a DAG named SOA-DAG-2013.  Now, previously this would be the name of the CNO that Exchange would create underneath.  This is changed to essentially be a label that is stamped on all the nodes for management, but will no longer create the CNO.

If we login to EAC and navigate to Servers->Database Availability Groups, we can create the DAG by click on the plus sign:


Enter in the information for the DAG, and remember to specify your Witness Server.  It should be another Exchange 2013 Server in your primary datacenter location that is not also a member of the DAG.  We will specify one IP address of


If we are doing this in PowerShell, the syntax is different:

New-DatabaseAvailabilityGroup –Name SOA-DAG-2013 –DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) –WitnessServer NYDC-SOAE13CAS1.soa.corp –WitnessDirectory c:\WitnessDirectory\SOA-DAG-2013




Now, from here, building the DAG should have the same steps.  Lets add the mailbox servers to the DAG.  If you don’t already have Windows Failover Clustering installed, these steps will install it for you.

From the EAC:, under Database Availability Groups select the DAG name, and click on the Server with the gearbox icon:












Add your servers to the DAG and click Save:



From the Exchange Management Shell:

Add-DatabaseAvailabilityGroupServer -Identity SOA-DAG-2013 -MailboxServer SFDC-SOAE13MBX2


And your all set.  The DAG has been configured with no Administrative Access. 

If we check the properties of the DAG in the EAC we can see the IP address is listed as



And even though we had that string in the PowerShell command, if we check the IP address in PowerShell, we only have listed as an IP address:



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.

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

ActiveSync, Exchange 2010, Exchange 2013, Netscaler, Xenmobile

See other articles in the series:

Part 1

Part 3

In the first article, we went over the basic architecture.  Now we are going to go about installing XenMobile Device Manager on our PHDC-XENDM01 server.

First, lets go to and download the needed software:


Besides that, we also need to install Java on the server.  At the time of this writing, I used Java version 7 Update 51:


We also need to download a specific Java policy, Java Cryptography Extension Unlimited Strength from

Once, we have the software, lets log into PHDC-XENDM01, which is running Windows Server 2012 STD.

First, lets disable IPV6 on the server.  Run the following command from powershell:

New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters -Name DisabledComponents -PropertyType DWord -Value 0xffffffff

Also, run msconfig and disable UAC:


After, reboot the server.

Once it comes back up, it’s time to install Java.  This is a simple, next, next finish install:


Next, we need to go into UnlimitedJCEPolicy folder.  We need to copy the two files local_policy.jar and US_Export_policy.jar:


To the following two locations:

C:\Program Files\Java\jdk1.7.0_51\jre\lib

C:\Program Files\Java\jre7\lib

If you don’t complete the above steps, you will get an error when you launch the Device Manager console, and iOS devices will not be able to register.

Next, lets get SQL ready.  We need to open SQL Management Studio on PHDC-SQL01.  Navigate to Security->Logins->New Login


Make sure you create the login as SQL Server authentication.  We will use the login name xenmobile and set the password to whatever you like.  Next click the server roles tab, and we will select sysadmin.  Make sure that this security is allowed in your environment before making this setup.


Before we start the install of Device Manager, if we are registering iOS devices, we need to request a certificate from Apple for an APNS certificate.  We then need to submit that request to XenMobile helpdesk for them to sign the request before completing the request with apple.

On a server with IIS installed (not the XenMobile Device Manager server, as IIS will break Device Manager), we need to create a certificate request for our Device Manager namespace, which in our case is .  Open IIS Manager and click on Server Certificates:


Then click on create Certificate Request, and fill out the certificate.  Ensure the common name is the one that devices will be hitting to register with Device Manager.  Again ours is


Select Next, and on Cryptographic Service Provider Properties, change the Bit Length to 2048:


Select next, and save the request to your c drive:


Next create an email to and request to have the certificate signed, ensure to attach the request you created above.  You will receive an email back with the signed request.

Take the file you get back, and log into  If you don’t have a developer ID, create one, its free.

Click Create a Certificate:


Accept the agreement, and upload the signed request file.  You can then download your complete certificate request:


Now, log back into the same server where you created the certificate request and go back to IIS->Server Certificates.  Now click on Complete Server Certificate, and select the file you downloaded from the Apple website.  Give it a friendly name so you can easily identify it.  In my case I’ll call it iOS MDM.


Next, open up MMC on the same server you completed the certificate request on. Click on File->Add/Remove Snap in, select certificates and add it, select local computer:


Navigate to Certificates->Personal->Certificates.  Select the iOS MDM you created before, right click and select all tasks, export:


Ensure you select Yes Export the private key:


It will ask you to password protect the file, ensure you remember it as you will need it when you install Device Manager.


Select a file name and save the file:


Okay, we are FINALLY ready to install Device Manager.

Copy the PFX file you exported to PHDC-XENDM01.  Then, lets run the XenMobileDeviceManager Installer.

Select Next until you get to the component screen.  Unselect Database Server.  This will allow us to use Microsoft SQL and not the Postgres SQL that comes with Device Manager:


Select the default install path and click next, let the installer begin.  It will ask you for the license file for the install, browse to it and select the file.  You can request free trials from Citrix as well:


Next brings you to Configure Database Connection.  Select SQL Server/jTDS.  Fill out the info:



The user name should be the user we created in SQL before.  The database name can be anything you want.  the installer will realize its missing and ask if you want to create it when you select Check the connection:


Click create, and then next.

Leave this screen blank, and select next:


Select next at the Configure iOS usage screen:


Then click on next through all the IP configuration:




Next we will come to the Define the Root Certification Authority.  This will create a self signed certificate store.  Enter a keystore password to create, to the same for the next three screens:




For the last one, define a certificate for HTTPS, you need to add the FQDN that users are connecting to this server on.  In our case, its


**If after you want to replace this certificate with your own, complete the install and then follow my article here:**

Next page, browse to the PFX file that holds your Apple APNS certificate, and enter the password you used to protect it:


Select next, leave the default port for Remote Support tunnels:


Next, select the default admin username and password:


Click Next, and then finish.

Next time, we will go over configuring the XenMobile Device Manager Server and publishing it using the Netscaler.

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

ActiveSync, Exchange 2010, Exchange 2013, Xenmobile

Read other articles in the series:

Part 2

Part 3

Citrix XenMobile is a Mobile Device Management software that allows you to control ActiveSync devices at the corporate level.  While many people assume this means pushing email profiles to the device and controlling ActiveSync access, it is in fact much more than that.  You have the ability to control and push applications to the devices, security on the devices among many other things.  That being said, there can be a lot of complexity and moving parts to get the solution working.  I thought it would be good, for my own sanity, but also for others to see the steps to set up a real world example.  I’ll do it in the style of a business case so we can outlay what the business requirements are, how the architecture looks, and then go about installing and configuring the necessary items.


There are several goals for the SOA Corporation that they want to achieve out of this Mobile Device Management implementation.

  1. Restrict unmanaged devices from being able to connect to the Exchange environment using ActiveSync.
  2. Force all devices, employee owned or not, to first be registered with XenMobile before they are allowed to receive corporate resources such as ActiveSync profiles and applications.
  3. Management wants to be able to wipe just the corporate data off of the devices and leave the rest of the employee owned device alone.
  4. Management would like to minimize the helpdesk from having to manually allow devices for users.


Existing Architecture:

The existing Exchange architecture is simple for this case.  We have a single, multi-role Exchange  server sitting in our datacenter.  We also are utilizing Citrix Netscalers to publish Exchange resources to the internet.  Users access ActiveSync currently by using the namespace


Now, after we implement the XenMobile Solution, are architecture will look like the following:


Now, there are a couple things to note.  First off, I stink at Visio, so I did the best that I could.  After our installation though, we will have the following servers:

  1. PHDC-SOAEXC1 – Exchange Multi Role Server
  2. PHDC-XENDM01 – XenMobile Device Manager Server
  3. PHDC-XENNC01 – XenMobile Netscaler Connector Server
  4. PHDC-XENMM01 – XenMobile Mail Manager Server
  5. PHDC-SQL01 – SQL Server to host the XenMobile Device Manager and XenMobile Mail Manager Databases


The external namespaces will be:

  1. – Exchange ActiveSync URL
  2. – XenMobile Device Registration Site


What Does Each Component Do?

XenMobile Device Manager Server

This is the “brains” of the XenMobile operation.  It is the management server where you device policies, manage user devices and have visibility into the environment.  This server hosts the web page, and is where we need to point our mobile devices at in order to register them with XenMobile.

XenMobile Netscaler Connector

This server runs a service that will be responsible for “intercepting” Exchange ActiveSync requests from end user devices.  It does this via HTTP callouts in the Netscaler (which we will explain and discuss later in the article).  When it intercepts, it will then ask the XenMobile Device Manager server about the device in question.  Based on the policies in place, the Device Manager server will tell the Netscaler Connector whether the ActiveSync device should be allowed or not.  If it shouldn’t be allowed, it will tell the Netscaler to drop the connection and the users device will get a “cannot connect to error” message.  If it should be allowed, the Netscaler Connector tells the Netscaler to allow the device to connect to the Exchange Server as normal.  Think of Netscaler Connector has a network level firewall for Exchange ActiveSync.

XenMobile Mail Manager

This server runs a service that interrogates Exchange through remote PowerShell.  It allows XenMobile to see all devices that have Exchange ActiveSync connections, regardless of if they are managed by XenMobile or not.  It essentially is running the Get-ActiveSyncDevice command for every mailbox in the environment and reporting back to XenMobile Device Manager. It also though will get updates from Device Manager about whether a device should be allowed or not.  For instance, a user device connects to ActiveSync, then violates a company rule, say removing the passcode from their device.  XenMobile Device Manager will realize this, and send a command to Mail Manager.  Mail Manager will then, using PowerShell, apply an Exchange ActiveSync block on this particular device for the user, stopping it from connecting to ActiveSync.  Just how the Netscaler Connector is a network level firewall for Exchange ActiveSync, think of Mail Manager as an application level firewall for Exchange ActiveSync.

Mail Manager also works with Exchange’s Quarantine functionality.  This means that you set Exchange to quarantine every new device that starts an ActiveSync relationship.  Usually, an admin needs to go in and manually allow each device.  In XenMobile, if that user registers their device with XenMobile Device Manager, Device Manager will then send a command to Mail Manager to create an ActiveSync allow rule for that user, automating the entire process!

As of this writing though, Mail Manager does not yet support Exchange 2013 so you need to point it to a server running the Exchange Management Tools for Exchange 2010.  Just an FYI.

Well, that is the basic architecture and overall goal of the project.  Next, we will jump into install XenMobile Device Manager.

Setting Up a Database Availability Group in Exchange 2013

DAG, Exchange 2013, High Availability

We’ll walk through the steps of setting up a Database Availability Group or DAG for short in Exchange 2013.  Our setup is we have two mailbox servers:

PHDC-SOAE13MBX1 – IP Address of

SFDC-SOAE13MBX1 – IP Address of

There are a couple of requirements that we need to ensure are met before we can set up the DAG, and that things run well once we do. 

Requirement #1 – Windows Failover Clustering

For starters, Exchange DAG’s use windows failover clustering as the means to setup the foundation of the DAG.  This means that you will need to install Windows Failover Clustering on each of the mailbox servers that will be a member of the DAG.  The Exchange 2013 DAG setup will perform the install for you, so there is no need to do it ahead of time.  What you do need to know though, is that the underlying Windows operating system needs to be able to install it.  Meaning your Windows OS must be one of the following:

  • Windows Server 2008 R2 Enterprise
  • Windows Server 2012 Standard
  • Windows Server 2012 Enterprise

Requirement #2 – Same Operating System

Since Windows Failover Clustering has this requirement, so does Exchange 2013 DAG’s.  All members of the DAG need to run the same OS level.  Meaning you cannot have one DAG member running 2008 R2 Enterprise and another running 2012 Standard.

Requirement #3 – One DAG per Server

Each mailbox server can only be a member of one DAG at a time. 

Requirement #4 – You Need an IP address for the DAG in each subnet there is a mailbox server

Since the DAG is a cluster, that cluster needs an IP address in each subnet that there is a mailbox server.  This is separate from the mailbox server’s IP address.  In our example, we have two subnets we are spread across:

This means we need an extra IP address for each subnet to assign to the DAG.  In our case we will use:

Requirement #5 – Name of DAG

The name of the DAG needs to fit the NETBIOS requirements, meaning 15 characters or less.

In our example, we will use SOA-DAG-13.

Requirement #6 – Witness Server

We need a Witness Server that will be used in the event that we have an even number of members in the DAG, and there needs to be a tie breaking vote.  Best practice is to use an Exchange 2013 CAS server.  Realistically ANY windows server will do, but you need to add the Exchange Trusted Subsystem as an administrator to that local PC before you can use it.

In our example we will use PHDC-SOAE13CAS1 and use the directory of C:\Witness\SOA-DAG-E13.soa.corp

Optional Requirement – Replication Networks

While it is not required, it is certainly best practice to create a replication network.  With that, you would have an extra NIC on each DAG member that would be dedicated for replication traffic only.  In bigger installations this is certainly recommended as seeding and replication can easily use a significant portion of the bandwidth.

So let’s get started. 

Pre-Stage the DAG CNO

The first thing we need to do is pre-stage the computer name for the DAG. Open up AD Users and Computers.  Navigate to an OU that contains both your Mailbox servers in it.  Right click and create a new computer object.  Fill in the details as necessary:


Next, right click the account you just created and select Disable Account


Now, we need to assign permissions to this account so that the mailbox servers are allowed to manipulate the object, as well as the group Exchange Trusted Subsystem.

In AD Users and Computers, go to View->Advanced Features


Right click the account you created and go to Properties->Security tab.

Add the following objects to the computer account with Full Control

  • Exchange Trusted Subsystem
  • Each mailbox server

(You only really need to the add the first mailbox server that you are using to create the DAG, but just to make things uniform you can add both)




Ensure that AD replication has finished before moving on.

Creating the DAG

First, lets log into the Exchange Control Panel on either of the servers.  You can get there by going to https://servername/ecp .

Navigate to Servers->Database Availability Groups.  In our example, you can see my pre-existing Exchange 2010 DAG:


Click on the + symbol at top to create a new DAG, and enter in the information:


Not that we have added the Name of the DAG, the Witness Server, and the Witness Directory.  Then we add the IP’s we have assigned to the DAG itself underneath.  Click Save to create the DAG.

Now, if we double click and open the DAG, we will note there is nothing in it.  We need to add mailbox servers to it:


Back on the DAG screen, select your DAG object, then select the little server with the gear on it.  This will allow us to manage the membership of the DAG.


Select your mailbox servers:



And click save to begin adding them to the DAG:


If you didn’t install Windows Failover Clustering before hand, this will install it on each node for you.  It can take about five minutes for each server for the entire process.

Eventually the DAG will be complete:


Setting DAC Mode on the DAG

Once your DAG is done, there is one last item you should follow.  On an Exchange 2013 server, open the exchange management shell. run the following command to enable DAC mode:

Set-DatabaseAvailabilityGroup –Identity SOA-DAG-13 –DatacenterActivationMode DAGOnly


The purpose of DAC mode is to help prevent split brain, and also allow you to use to Stop-DatabaseAvailabilityGroup and Start-DatabaseAvailabilityGroup commands for failover.

Now your all set, the last thing to do is to add copies of the database on each DAG member. 


How to Delete Emails from Mailboxes in Exchange 2010 Using Search-Mailbox

Exchange 2010, Exchange 2013, Scripting, Security

Quick post today.  If you have an criteria of emails that you want to delete from all mailbox’s you can use Search-Mailbox to delete the message from users mailbox.  For example, you get hit with a virus email that has the subject “I am a virus” from the user

The below search goes through all mailbox’s and deletes any email with the subject “I am a virus”:


get-mailbox | Search-Mailbox -SearchQuery ‘subject:”I am a virus.” ‘ -TargetMailbox “adminmailbox” -TargetFolder “DeleteVirus” -LogLevel Full –DeleteContent


That above command will delete the emails from the users mailbox’s and copy them to the adminmailbox in the folder DeleteVirus

The next search does it based on the sender of the email:

get-mailbox | Search-Mailbox -SearchQuery ‘ ‘ -TargetMailbox “adminmailbox” -TargetFolder “DeleteVirus” -LogLevel Full –DeleteContent


The above search does the same thing as the first, except this query does it based on the from address of the sender versus the subject.

If you log into the admin mailbox, you can see the results of the search and log files for it:



You can also run the same commands without the –DeleteContent switch to copy the messages to the admin mailbox for review before running the commands to delete.

Remember, do this at your own risk and test test test before you run it!

How to Use Managed Availability in Exchange 2013 with your Load Balancer

Exchange 2013, High Availability, Managed Availability, Netscaler

One of the major changes in Exchange 2013 is the concept of Managed Availability.  I wont go too deep into it, but it is the ability of Exchange 2013 to monitor itself, detect problems and attempt to resolve them.  One of the added bonuses of this, is that Managed Availability then knows when a particular application is working and able to serve data.  One of these specific instances where we can use it with third party tools is with hardware based load balancers.

One of the jobs of the hardware load balancer is to detect the health of the server that it is load balancing, something that Managed Availability is already doing itself!  Hardware load balancers can detect the health through a variety of different ways.  The basic is ping, which just checks if the host is responding to ping.  The obvious problem here is that the host could be up, but none of the services!  The next would be to check if a port is accessible.  Here you configure the load balancer to check if say port 443 is alive.  This is better than ping, but doesn’t check if the application is actually working behind the scenes, just that it can telnet to 443.  We can use Managed Availability with our hardware load balancer to check if the application itself is actually healthy.

How do we do that?  Say we want a HLB to check if OWA is healthy on a server.  The normal http path would be https://servername/owa right?  Well, if you navigate to https://servername/owa/healthcheck.htm, you will get a page generated on the stop indicating if OWA is working on that server.

For example, say we have two Exchange 2013 servers:



And we want to publish OWA through a HLB to at ip address

If we navigate to https://PHDC-SOAE13CAS1/owa/healthcheck.htm on this server with working OWA, we get the following page:


Not a lot too it, but essentially its returning a 200 OK message indicating the service is working. If the service was not working, this page would not generate.  So we can have our HLB check to see if it gets a 200 OK response from a particular server.

We want to configure these in our load balancer for services such as OWA, Activesync, Outlook Anywhere etc.  So, we will configure Exchange 2013 using Citrix’s Netscaler in this example.  The configuration will be similar for other HLB, but we’ll go through the steps here.

On the Netscaler go to Load Balancing->Monitors and click add to create a new monitor.  Here, we will create a custom monitor for the Netscaler, so that it can poll that web page.  Name the monitor MONITOR-EXCHANGE2013_OWA and set the type to HTTP-ECV.  Ensure to select the Secure check box at the bottom as this will be over SSL.  Leave the other options default:


Next, click on the Special Parameters tab.  In the Send String box enter in GET /owa/healthcheck.htm.  In the Receive String box, enter in 200 OK:


Click create to save, and navigate over to Load Balancing –>Service Groups

Add a new Service Group, and name it Exchange2013-OWA and set the protocol to SSL.  Enter in the IP addresses of your CAS servers, and set their ports to 443


Next, click on the Monitors tab.  Find the Monitor_Exchange2013_OWA monitor we created above and add it to the configured Monitors selection


Click on the SSL Settings tab and select the SSL certificate that you will use to publish the Netscaler service to the internet.  I have a preloaded one named Lab-2013 that I will be using:


Click Create to save the Service Group.

If we check, our service group should be reporting up, that’s good, it means our monitor is working!


Next lets go to Load Balancing->Virtual Servers

Create a new Virtual Server and name it Exchange2013_OWA, Set the Protocol to SSL, and assign it an IP, in our case Leave the SSL Port at 443.


Select the Service Groups tab and select the service group Exchange2013-OWA we created earlier:


Then click on the SSL Settings tab and select the same certificate as you did on the service group, in our case Lab-2013:


Click Create to save the virtual server.

Next, make sure your DNS address is pointing to the IP address of the virtual server and lets try to login:


There we go!  There is are OWA page!  But, the question is how do we test that our monitor is working.  That’s easy.  On PHDC-SOACAS2, lets go into IIS Manager and stop the MsExchangeOWAAppPool:


If we check our Netscaler, we see that one of the servers is now being reported as down:


If we try to telnet to that server on port 443:


We can see it works fine:


I know it doesn’t show much, but it shows that the server is still listening on port 443.  This also proves that using Managed Availability for your HLB is much better.  Here, the standard checks would have said the server was working fine, sent user requests to it, but in fact OWA isn’t working.  But since we are using Managed Availability, we are passing that knowledge on an application layer to our HLB.

If we try to go back to OWA:


The HLB sees that one server is down, and runs everything to the server that’s still up.  But, if both servers have their application pools stopped:

We get a HTTP Error, The Service is unavailable:


This works for all of the Exchange web services.  So that means you can create separate monitors just be appending healthcheck.htm at the end of the URL.  So for ActiveSync its https://servername/Microsoft-Server-ActiveSync/healthcheck.htm.  The only one that has a stipulation is OWA, which requires Forms Based Authentication to be enabled for it to provide a HealthCheck.htm page.

I hoped you have found this helpful, and hopefully it will save you some configuration steps (and some uptime!) on your hardware load balancer