Posts | Exchange for the Working Man

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 http://www.citrix.com/downloads/xenmobile/product-software/xenmobile-86-mdm-edition.html

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 + mobile.accessabacus.com : 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

ip –> CLIENT.IP.SRC

url –> (“https://”+HTTP.REQ.HOSTNAME+HTTP.REQ.URL).B64ENCODE

resultType->”json”

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

DeviceId-> HTTP.REQ.URL.QUERY.VALUE(“DeviceID”)

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

Written by Port25Guy on Saturday, March 1st, 2014

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

14 Comments

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:

Exchange 2013 Servers all running the new SP1 Upgrade – http://www.microsoft.com/en-us/download/details.aspx?id=41994
An Outlook 2013 client running the new SP1 Upgrade
- 32 Bit – http://www.microsoft.com/en-us/download/details.aspx?id=42017
- 64 Bit – http://www.microsoft.com/en-us/download/details.aspx?id=42006
A namespace that you will use for the MAPI/HTTP connection. This can be the same as your existing ones as well. In our case we will use https://mapi.accessabacus.com
A certificate to support that namespace
Update your Load Balancer’s and/or Reverse Proxy to allow access to the new MAPI virtual directory on your Exchange 2013 SP1 CAS Servers

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:

Get-MapiVirtualDirectory

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 https://mapi.accessabacus.com/mapi 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 https://mapi.accessabacus.com/mapi –ExternalUrl https://mapi.accessabacus.com/mapi -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 https://mapi.accessabacus.com 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 “email-ph.lab.accessabacus.com”, 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 (email-ph.lab.accessabacus.com and mapi.accessabacus.com), 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 (http://port25guy.com/2013/07/24/how-to-use-managed-availability-in-exchange-2013-with-your-load-balancer/) 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:

HKCU\Software\Microsoft\Exchange

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

Written by Port25Guy on Thursday, February 27th, 2014

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

4 Comments

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 mobile.accessabacus.com.

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.

Cycle for Survival!!! Donate to a Great Cause!

Written by Port25Guy on Thursday, February 6th, 2014

Uncategorized

Join the Battle with Paul Ponzeka. Beat Rare Cancers.

I am taking action against rare cancers by participating in Cycle for Survival.

This national indoor team cycling event raises money to fund critical research at Memorial Sloan-Kettering Cancer Center. Participants and donors make progress and hope possible for patients and their loved ones worldwide.

Here are two important facts you should know:

>>> 100% of the funds donated for my ride will go directly to MSKCC to help patients around the world.

>>> Since its inception, Cycle for Survival has helped fund 85 clinical trials and research studies.

Why do I ride?

I ride to honor brave family and friends touched by cancer. Cycle for Survival is my way of fighting back and making a difference.

I ride because I want to contribute to lifesaving research.

I ride because there aren’t enough treatment options for people with rare cancers—I know we can change that. All pediatric cancers, leukemia, lymphoma, sarcoma, and thyroid, ovarian and pancreatic cancers are among the many types considered to be rare.

How can you help?

Give a gift to my Cycle for Survival ride! Every dollar goes directly to promising cancer research.

Together, we can truly make an impact!

It’s time.

JOIN THE BATTLE.

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

Written by Port25Guy on Monday, February 3rd, 2014

ActiveSync, Exchange 2010, Exchange 2013, Netscaler, Xenmobile

3 Comments

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 www.citrix.com and download the needed software:

http://www.citrix.com/downloads/xenmobile/product-software/xenmobile-86-mdm-edition.html

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 http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

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 mobile.accessabacus.com . 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 mobile.accessabacus.com

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 support@zenprise.com 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 https://identity.apple.com/pushcert. 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 mobile.accessabacus.com:

**If after you want to replace this certificate with your own, complete the install and then follow my article here: http://port25guy.com/2013/11/18/import-a-3rd-party-certificate-into-xenmobile/**

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

Written by Port25Guy on Friday, January 31st, 2014

ActiveSync, Exchange 2010, Exchange 2013, Xenmobile

3 Comments

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.

Requirements:

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

Restrict unmanaged devices from being able to connect to the Exchange environment using ActiveSync.
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.
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.
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 mobilemail.accessabacus.com.

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:

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

The external namespaces will be:

Mobilemail.accessabacus.com – Exchange ActiveSync URL
Mobile.accessabacus.com – 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 Mobile.accessabacus.com 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

Written by Port25Guy on Sunday, January 26th, 2014

DAG, Exchange 2013, High Availability

3 Comments

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 10.220.10.2

SFDC-SOAE13MBX1 – IP Address of 10.10.10.60

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:

10.220.10.0/24

10.10.10.0/24

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

10.220.10.6

10.10.10.6

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.

Enjoy!

Import a 3rd Party Certificate Into XenMobile

Written by Port25Guy on Monday, November 18th, 2013

ActiveSync, Blackberry, Xenmobile

4 Comments

To replace the default certificate that comes with XenMobile with a 3rd party one, from say Digicert, there are a couple of steps that you need to take. None of these are hard, but are not well documented anywhere. First you need to have a PFX file that has your root CA, intermediate CA and regular certificate included in it. It should also be protected by a password. The easy way to create this is to use an existing windows server that has the certificate installed. Open of the Certificate snapin and browse to the local computer.

The following was done with XenMobile 8.6 but also applies to XenMobile 8.5. It was also done with a wildcard certificate but the process should be the same for a SAN or regular certificate.

Navigate to Personal->Certificates. As you can see I have the following certificate that I want to export:

Click on the Details tab, and select copy to file

Select Yes, export the private key

Select the option to Include all certificates in the certification path if possible

Enter in a password to secure the file, and finally export:

Copy that file to the XenMobile Device Manager Server. In our example we will copy it to a folder on the C drive called ExternalSSL. Rename the extension to be p12 instead of pfx:

Next, to make your life easy, download the certificate utility from Digicert at https://www.digicert.com/util/. When you run it you’ll get the following screen, and select Import in the upper right:

Browse to, and select the certificate we copied over earlier:

Next you need to enter the same password you put in when you exported the certificate above:

Enter a friendly name for the certificate. This is simply so you can better label it:

Select Finish, and you should get a message that the import was successful:

Now on the device manager server, navigate to the tomcat directory, which if your on an x64 server is the following path:

C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat

We have to edit two files. The first one is C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\webapps\zdm\WEB-INF\classes\pki.xml

Open the file in WordPad. At the bottom of the file, but before the </beans> section paste the following info:

<bean id=”externalSslCert” class=”com.sparus.nps.pki.def.KeyStoreParams”

p:keyStoreType=”PKCS12″

p:keyStorePath=“C:\ExternalSSL\xenmobile.p12”

p:entryAlias=””

p:keyStorePass=“password”

p:publiclyTrusted=”true”

Note the highlighted sections. The first is the path to the certificate file, the next is the password from when we exported it.

Save and close the file.

The next file we are going to edit is C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\conf\server.xml

Again open the file in wordpad.

Find the following section, and replace the highlighted section to match the same as above

<Connector
            port=”443″
            maxHttpHeaderSize=”8192″
            maxThreads=”400″
            enableLookups=”false”
            redirectPort=”-1″
            acceptCount=”100″
            connectionTimeout=”30000″
            disableUploadTimeout=”true”
            maxKeepAliveRequests=”-1″
            protocol=”org.apache.coyote.http11.Http11NioProtocol”
            scheme=”https”
            secure=”true”

            clientAuth=”want”
            SSLEnabled=”true”
            truststoreFile=”C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\conf\cacerts.pem.jks”
            truststoreType=”JKS”
            truststorePass=”notMeaningFul”
            keystoreFile=”C:\ExternalSSL\xenmobile.p12″
            keystorePass=”password”
            keystoreType=”PKCS12″
            ciphers=”TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384″

Still in server.xml, do the same with the following section:

<Connector
            port=”8443″
            maxHttpHeaderSize=”8192″
            maxThreads=”20″
            enableLookups=”false”
            redirectPort=”-1″
            acceptCount=”100″
            connectionTimeout=”30000″
            disableUploadTimeout=”true”
            maxKeepAliveRequests=”-1″
            protocol=”org.apache.coyote.http11.Http11NioProtocol”
            scheme=”https”
            secure=”true”

            clientAuth=”false”
            SSLEnabled=”true”
            truststoreFile=”C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\conf\cacerts.pem.jks”
            truststoreType=”JKS”
            truststorePass=”notMeaningFul”
           keystoreFile=”C:\ExternalSSL\xenmobile.p12″
            keystorePass=”password”
            keystoreType=”PKCS12″
            ciphers=”TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384″

Save and close the file.

Now, restart the XenMobile Device Manager service:

After browse to https://localhost/zdm on the Device Manager and you should be able to validate that your certificate was installed. Note that the tomcat service does spend some time with heavy CPU after a restart and it may be a minute or two until the page comes up:

Now all thats left is to publish it in DNS!