Category Archives: Security

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

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 Publish Outlook Web Access with RSA SecureID on Exchange 2007 or Exchange 2010

exchange 2007, Exchange 2010, Security, Threat Management Gateway

With many companies putting an emphasis on security, especially given the recent events involving Google and China, one of the things many companies turn to is two form authentication. The most popular brand out there is RSA, a subdivision of EMC.

Those who work with RSA know the deal. You get an appliance that you install on your internal LAN, and give your users a key fob.  This key fob has a display that changes a number sequence every sixty seconds. Users then use this key code, along with their user name and password, to log onto company resources. It’s regularly seen with network resources such as Citrix XenApp and web resources. Another solution where you can leverage it is by securing Outlook Web Access from Exchange 2007 or Exchange 2010 with RSA two form authentication. This means that users would need to use an RSA token along with their user name and password to log onto OWA.

Besides the RSA appliance, you would need also a Microsoft Threat Management Gateway Server (formerly called ISA Server) installed and operational. In the remainder of this article, I’ll show you how to publish the OWA page utilizing RSA for two form authentication.

Our test network is as follows:

1. NYRSA1 (RSA Server) –

2. NYTMG1 (TMG Server) – Local LAN, Internet

3. NYCAS01 (Exchange 2007 Client Access Server) –

Remember, with TMG the server generally has 2 NICS, one is connected to the unprotected network, or internet, and one is connected to the protected LAN, or internal network.  With Threat Management Gateway, you can either have it external to the domain, joined to a workgroup, or joined to the internal domain.  In our example, we have the TMG server joined to the domain.

So, the first thing we need to do is make the RSA server and the RSA Agent (in this case the TMG server) aware of each other and allow the TMG server to authenticate users with RSA. Log into NYRSA1 and launch RSA Authentication Manager Host Mode:

From here select “Agent Host” and select Add Agent Host. Fill out the name of the TMG server. (Ensure the server name is resolvable from the host, you can tell if it automatically fills in the IP of the TMG server):

Ensure the Agent Type is set as NET OS Agent and check Open to All Locally Known Users.

Select OK to save the host. Next, we need to export a file that we will import on the TMG server to establish communications. Go to Agent Host, Generate Configuration File and select One Agent Host:

Select the TMG server, NYTMG1 and save the resulting sdconf.rec file to the RSA appliance desktop. Next, move that file to a location on the TMG server that you can access from that server. You may need to use a USB key or CD if your TMG server is set with the default settings, which doesn’t allow remote or network share access.

Next, log onto NYTMG1, and copy the sdconf.rec files to two locations:

1. C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig

2. C:WindowsSystem32

***If you do not copy the sdconf.rec file to C:Program Files location, you will receive an error later on that I will show you***

Next, we need to export a copy of the certificate that is installed on NYCAS01, so that we can install this same certificate on NYTMG1. This is because the TMG server does SSL bridging between the two servers, and needs this certificate in order to unwrap the SSL packets from the client.

On NYCAS01, open an Exchange Management Shell. First we need to figure out the thumbprint for our certificate. You can get this by running the command Get-ExchangeCertificate:

Next, you can export this certificate to a .pfx file with the command above. Note we are exporting the certificate whose thumbprint begins with 331BF.At the end of this command, a logon prompt will appear which will force you to enter logon credentials to password protect the certificate. The prompt forces you to enter a logon name with a domain, but rest assured, it’s the password that’s important.

Now, copy the file export.pfx to the TMG server so you can access it locally, we need to import this certificate. On NYTMG01, open a blank console by running the command mmc and pressing enter. Now, select Add/Remove Snap In and select the Certificates snap in:

Select Computer Account and Local Computer and finish:

Next, navigate to the Personal store and select Import:

Now, the Import Certificate Wizard starts:

Select Next, and browse to the .pfx file you copied over:

At the next screen, select Mark This Key as Exportable, enter the password you created earlier and select next and finish. Now this certificate is available for use in TMG.

Next, let’s start creating our rule to publish OWA. Open the Threat Management Gateway Console and Select Firewall Policy:

Click on Publish Exchange Web Client Access from the Tasks bar on the right, which will start a Wizard. Give the rule you are creating a name:

Click Next, and select the version of Exchange you are using, as you can see, it supports all versions from 2000 through 2010:

Click next, and it will ask you if you want to publish a single site, or multiple sites for load balancing. In this example, since we only have one CAS server, we’ll select Publish a single Web Site or Load Balancer:

Click Next. The next screen is how you want the TMG server to speak to the CAS server. Since security is paramount here, we want to select “Use SSL”.

Click next, and now it will ask for the Internal Site Name. This is the DNS name of the internal CAS server. Since the TMG server is also on the local LAN, this would be the INTERNAL DNS NAME of the server, or in our example, NYCAS01.internal.local

Click next, and this screen is asking what EXTERNAL DNS NAMES your users will be typing into their browsers to connect to this page from an external computer. If you set the public name wrong, users won’t be able to connect. In our example, users will type in to access the OWA page from outside the organization.

Next, we have to select a Web Listener. Since we haven’t created on, there are none from the drop down:

Select “New” and we’ll be presented with the New Web Listener Wizard

After creating a name, select next, and you’ll be presented with should the listener require SSL. Since, again, security is paramount, we select require.

Next, it will ask what networks will be connecting to the server through this listener; here select External since this will be a web page that users will access from outside the company network.

Next, you’ll need to select the SSL certificate to use to secure this connection. Select the certificate we imported earlier:

Next, we are selecting particulars of how the user will log in through this listener. Here, we want to select HTML Form Authentication, and we need to select Collect Additional Delegation Credentials in the Form, and select RSA SecurID. This will add an extra field in the OWA logon page, requesting the SecureID token from the user’s key fob.

At the next screen, uncheck the option for Single Sign On:

At the next screen, you’ll get prompted with the following screen:

Select Yes. The TMG server has built in RSA dll’s, so you don’t need to install the RSA Agent software on the TMG server. You do need to select yes though here, to create the necessary firewall rules to enable communication between the TMG server and the RSA server.

Now, you’ll be returned to the Exchange Publishing Rule Wizard, and the Web Listener should be populated with the new Web Listener you just created:

At the next screen, you are presented with how the TMG server is going to authenticate to NYCAS01. Here, we are going to select Basic Authentication. Since it’s wrapped in an SSL wrapper, Basic Authentication in this case is secure:

The next screen will allow you to select which users can authenticate through this connection:

We’ll leave All Authenticated Users and select next. This will finish the creation of the rule. Ensure you hit apply at the top of the Firewall Page to apply the changes made:

So that takes care of the configuration on the TMG server side, but we need to ensure of some configuration on the Client Access Server side of NYCAS01.

On NYCAS01, open the Exchange Management Console, and Browse to Server Configuration->Client Access Server->NYCAS01 and right click the OWA virtual directory and select properties:

Remember, before we selected Basic Authentication as the method the TMG server would use to authenticate to NYCAS01, so ensure this is selected as an authentication option. After you apply these settings, you’ll need to run IISRESET /NOFORCE from a command line to recycle the IIS process and apply the changes.

So, now we should be all set, let’s test it out! If we point our browser to the external IP of the TMG server we should be presented with the correct logon page:

There we go! Notice the three boxes, one for user name, password and pass code.

One more thing. Remember before, how I warned you that if you didn’t copy the sdconfig.rec file to C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig you would receive an error? The error is actually received by the end user, as a web server busy message as below:

Just copy the file to correct location, no need to recycle services, and you should be all set!

Any questions just shoot me an email!