Tag Archives: Exchange 2010

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:

Exchange07as

Here, we have one internet facing site, the NY site.  There is a DNS record for the CAS server in NY, activesync.company.com that points to the IP of the CAS server on the internet.  We have set the –externalurl to activesync.company.com and the –internalurl to newyork2007.company.local.  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 newyork2007.company.local –ExternalURL activesync.company.local

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 activesync.company.com 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 lonactivesync.company.com, 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 legacy.company.com and have this entry point to the 07 CAS, and slide the 2010 CAS into the existing activesync.company.com namespace.   See the below diagram:

Exchange2010as

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 activesync.company.com 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 legacy.company.com and their profile loaded, all seamless to the end user.

If LON07 enters in activesync.company.com 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 legacy.company.com.  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 legacy.company.com  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 legacy.company.com.  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 PrxTo:newyork07.company.local.  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 newyork2007.company.local –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 Update DAG Members to SP1 in Exchange 2010

Exchange 2010, High Availability

 

Exchange 2010 SP1 has been released, and comes with a slew of new and exciting features.  Since we are all clamoring to get this installed in our environments, we should discuss how exactly we upgrade the members of our DAG so as to provide zero downtime to our users, and get our systems patched correctly.

From a high level view, remember we should be patching servers in the following order:

  1. Client Access Servers
  2. Hub Transport Servers
  3. Edge Transport Servers
  4. Mailbox Servers

The process we discuss in this article can and should be applied to ALL updates to members of a DAG, not just major updates like service packs.

In our environment we have three total nodes:

  1. NYDAGNODE1
  2. NYDAGNODE2
  3. BOSDAGNODE1

Let’s start with BOSDAGNODE1.  Step one would be to move all active databases on BOSDAGNODE1 to another server.  You want to ensure that it does not have any active databases on it.  We can accomplish this in two ways.

In the EMC navigate to Server Config –>Mailbox.  Select the server in question and then select Switchover Server:

Sep. 2301 10.43

Then you can either automatically choose a target server, or specify one yourself:

image

Or, through the shell, you can run the command:

Move-ActiveMailboxDatabase –Server DKPBOSDAGNODE1

Sep. 2302 10.45

This will do the same thing as the console, and will automatically choose a target server.

Next, we want to block DKPBOSDAGNODE1 from activating it’s databases.  This will prevent other servers from failing over to it.

Set-MailboxServer DKPBOSDAGNODE1 –DatabaseCopyAutoActivationPolicy:blocked

Sep. 2303 10.47

Now you can upgrade the server to Exchange 2010 SP1!

After its finished, run the following command to re-enable activation of the node:

Set-MailboxServer DKPBOSDAGNODE1 –DatabaseCopyAutoActivationPolicy:unrestricted

Sep. 2304 10.50

Now, you can proceed on the other nodes until your finished!

One caveat you need to be aware of.  Exchange 2010 RTM servers can failover TO a dag node member running Exchange 2010 SP1, but a server running Exchange 2010 SP1 cannot failover to a dag node member NOT running Exchange 2010 SP1.  So make sure your entire DAG is upgraded in a timely fashion!

As for your schedule, note that I chose to do Boston, which is our DR site first, because NY would still be able to fail over to it in case of a DR situation.  Next, I can do one node at a time in NY.  This allows me to keep my mailboxes local to my production site, while ensuring that I am covered should a DR situation arise. 

Creating a Database Availability Group in Exchange 2010 – Part 3

Exchange 2010, High Availability

 

In Part 2 of this series, we created the Database Availability Group, and added both NYDAGNODE1 and LNDAGNODE1 to it.

In Part 3 of this series, we are going to configure the network’s properly, and create some database’s for the DAG.

As we noted last time, by default, all networks for every node in a DAG is configured for replication.  We only want replication to occur over certain networks, mainly 172.16.1.0 for NY and 172.17.1.0 for London.  If we navigate to Organization Configuration –> Mailbox and select the Database Availability Group tab and select DAG01, we see all the networks listed.

23 Jun. 30 20.55

Just a side note, if you right click the label DagNetwork01 for example, you can rename it to something more descriptive.

24 Jun. 30 20.57

Now, for the two production network’s, when your in the property’s page, un-check the “Replication Enabled” check box:

25 Jun. 30 20.59

Now, it states for both NY and LN Production, that replication is disabled.  This will ensure that all replication occurs over a dedicated network.

26 Jun. 30 21.00

Now, it’s time to add some database’s to the DAG!  Move on to the Database Management tab.  You will note two database’s here, both of which are the default one for each server. 

27 Jun. 30 21.01

We can add these existing database’s to the DAG, by right clicking on each of them and selecting “Add Mailbox Database Copy”.  You will select any free server to add a copy, in our case:

28 Jun. 30 21.03

Select Add, and it will add NYDAGNODE1, as a replica for the Database.  Note the preferred list sequence number.  This indicates that NYDAGNODE1’s copy of this database, should be the second database activated, should something happen to Preferred List Sequence Number 1, which is the original copy on LNDAGNODE1.

The powershell command we could have run is listed:

29 Jun. 30 21.04

Now note, we have one database that’s listed as Copy Status Mounted, and one who’s Copy Status is Healthy.  The Healthy means it’s not in production and is a replica. 

30 Jun. 30 21.06

Note how it lists the servers that are hosting the database, as well as the Copy Queue Length, Replay Queue Length, as well as the Preferred List Sequence Number.  The copy queue length is how many transaction logs are waiting to be copied to the node, the replay is how many are waiting to be played into the database on that node, and the list sequence is what is the preferred next copy of the database Exchange should activate, if the currently mounted one becomes unavailable.

Adding a new mailbox database is very similar.  You create a new mailbox database, and select a node to host the first copy:

31 Jun. 30 21.09

And then just add extra copies as we did above.  All servers that are in the same DAG should have the same drive letter or mount point configuration.  This is because all copies will have the same path to the EDB File, as well as the Transaction Log and System Files path’s.  Also, since Mailbox Database’s are objects of the organization now, you need to ensure that their names are unique throughout the entire Exchange Organization.

So, that’s it for the third part of this series.  In this part, we configured the networks for replication, and we added copies of existing database’s, as well as created new database’s and copies into our DAG.

In the next part, I’ll show you how to fail over to different copies of the Mailbox Database’s, and it’s impact on the end user.

Creating a Database Availability Group in Exchange 2010 – Part 2

Exchange 2010, High Availability

 

In Part 1 of this series, we went over the basic concepts of the Database Availability Group, or DAG, and then went into how to set up the Networking for the DAG.  In this next section, we’ll cover how to create the DAG, and then add servers to that DAG.

The first thing we need to do, is actually create the DAG.  In the Exchange Management Console, under the Organization Configuration-> Mailbox, navigate to the Database Availability Group tab:

10 Jun. 30 19.35

Click on the “New Database Availability Group” Action.  You’ll be presented with the following screen:

11 Jun. 30 19.36 

  1. Database Availability Group Name – This is just the name of the DAG.
  2. File Share Witness Share – This is the UNC patch of a file share witness, most likely on an HT server.  This is used if there an even number of Servers in the DAG for a majority vote
  3. File Share Witness Directory – This is where the share is located on the server who is hosting it.  It will be created for you automatically.
  4. Network Encryption and Network Compression we’ll leave at the default.

With a Hub Transport server installed on NYDC01, and wanting the share to be from a folder called “DAG01” on the C drive of that server, our screen will look like this:

12 Jun. 30 19.40

After hitting next, you’ll see the powershell command that could have been run:

New-DatabaseAvailabilityGroup -Name ‘DAG01’ -FileShareWitnessShare ‘\NYDC01DAG01’ -FileShareWitnessDirectory ‘C:DAG01’

Now, you’ll have a DAG created, but with no member servers in it:

13 Jun. 30 19.43

Now, lets add NYDAGNODE01 to it.  A couple things that should be noted.  First, DAG’s utilize the Windows Server Failover Cluster feature to be installed.  If when you go to add a node to the DAG, if this isn’t installed, the command will run it for you, it will just take a little bit longer.  The second issue is that we are using the Beta release of Exchange 2010.  There seems to be an issue with the Exchange Console, being able to remotely initiate the installation.  To get around this when using the Beta, just make sure to install the Windows Failover Clustering Feature from Server Manager yourself on all the nodes.  This will also help to speed things up.

14 Jun. 30 19.47

Okay, so on to adding the first Node to the DAG.  When you add the first node to a DAG, the DAG get’s assigned an IP address.  If you do this through the Exchange Management Console, the DAG will retrieve an address through DHCP.  I’m not a huge fan of this, so I like to use the Exchange Management Shell, because you can statically assign an IP address to the DAG.  I’ll show you both way’s though.  For the Exchange Management Console, Navigate to Organization Configuration –> Mailbox and select the Database Availability Group tab.  Here, you will see DAG01 listed, the DAG we created before.  Right click it, and select “Manage Database Availability Group Membership”, you’ll be presented with this screen:

15 Jun. 30 19.59

Now, select the green Add button, and then select NYDAGNODE1, and select OK.

16 Jun. 30 19.59

You could now select manage.  This would ensure the server had Failover Clustering installed, if it didn’t it would install it, and then add it to the DAG.  It would also retrieve an IP address from a DHCP server.  We won’t finish this, we’ll do it in the shell. 

The command is really simple. 

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer NYDAGNODE1 -DatabaseAvailabilityGroupIpAddresses 10.1.1.3

18 Jun. 30 20.04

This will add the server NYDAGNODE1, to the DAG, DAG01 and assign the DAG IP address 10.1.1.3.

We let the command run, and it can take some time, you’ll see a command similar to the below as it creates the cluster and adds the server to the DAG:

19 Jun. 30 20.05

Once the command finishes, you’ll see NYDAGNODE1 listed as a member server:

20 Jun. 30 20.07

If we now ping that IP, we see that we are getting a successful return:

21 Jun. 30 20.08

Now, add the second node, LNDAGNODE1.  It works the same way as above for the Console, or the shell.  If you use the shell, you can now omit the –DatabaseAvailabilityGroupIPAddress command.  (Remember to log on locally to LNDAGNODE1, as the Beta fails when trying to do it remotely.  Also, it seems that you need to use the Exchange Management Shell (Local) icon to add the second node successfully) The end result should look like this:

22 Jun. 30 20.33

If you note, there are now two Member Servers in the DAG, and in the bottom half of the screen, it notes the networks, and their status.  Note, by default, ALL of the networks are configured for replication.  We’ll configure this differently in the next part.

In this part, we created a DAG, and added two members to this DAG.  In the third part of this series, we’ll configure the replication networks, and create some database’s and set them up for replication!

Creating a Database Availability Group in Exchange 2010 – Part 1

Exchange 2010, High Availability

 

As you may or may not have heard, Microsoft has announced the next version of their messaging suite, Microsoft Exchange 2010, will be available later this year!  The new version of Exchange hosts many improvements and feature additions on top of Exchange 2007.  One of the most exciting ones announced, was a feature called Database Availability Groups, or DAG’s.  In this four part series, we’ll go over the concepts of DAG’s, and how to get one working and test it out. 

So, what is a DAG?  A DAG is the evolution of the CCR and SCR functionality that was introduced in Exchange 2007.  CCR allowed you to keep two copies of your database’s in a cluster, protecting against both server failure, and a corruption of the database.  SCR allowed you to add site resiliency to your Exchange design, by replicating data to your disaster recovery site, and activating it if needed.  CCR and SCR have now been rolled into the DAG feature.  The best part about it, is most of the legwork, as well as the activation of the data, is automatic!  It still uses the concept of log shipping for the replication, although its been much improved.  Let’s get into a little bit of how it works.

The first thing you need to know, is in Exchange 2010, the storage architecture is different than that of Exchange 2007.  There are no more storage groups to start.  Transaction logs, checkpoint files, are all based off of the mailbox database now.  Microsoft was moving away from the storage groups, especially when you consider the requirement for any type of replication in Exchange 2007 required a maximum of one database per storage group.  The next big change is that database’s are no longer objects of a server, but objects of the Exchange organization itself.  What exactly does that mean, well, take a look of this screen shot in the Exchange 2010 management console:

 

01 Jun. 29 20.38

If you notice, I am under the Organization Configuration node, not the server configuration node.  The picture shows two database’s, each hosted on different servers.  If you notice on the bottom half of the screen, the console lists the Database Copies that make up this particular database.  A DAG consists of multiple copies of a set of database’s, that can be activated as the active copy at any time.  You can have up to 16 servers in a DAG, meaning you can have up to 16 separate copies of one database!  For example, you could have two servers in your main datacenter, each with a copy of one database for high availability in your main site, and then a third copy of the database in your disaster recovery site, in case you lost your main datacenter.  Members of a DAG do not have to be members of the same AD site, like stretched 2008 CCR clusters did.  Each of these can be activated at any time, automatically if you have a failure, or manually by running some commands.

The last major point, is that no client connects directly to a mailbox server anymore, including outlook.  Outlook clients connect to a Client Access Server, just like a POP or IMAP client does to connect to it’s mailbox.  This allows for incredible quick failovers (30 seconds or less), of the Outlook client to a new copy of the database. 

So now that we have an idea of the high level concept, let’s take a look at actually setting up one.  Here is my lab environment.  I have two separate AD sites.  New York has two subnets, 10.1.1.0/24 and 172.16.1.0/24, and London has two subnets, 192.168.1.0/24 and 172.17.1.0/24.  In NY, production traffic will occur over the 10.1.1.0/24 network, and replication and heartbeat over the 172.16.1.0/24.  In London, production is 192.168.1.0/24, and replication and heartbeat 172.17.1.0/24.  Now, since these are two separate sites, both replication networks need to be able to contact each other.  This means both networks need to be routable to each other, which in our case they are.  You can use a stretched VLAN, but is a much more complicated scenario, for no true benefit.  In each site, I have a single Domain Controller, that is also a Client Access Server and Hub Transport server, as well as one machine with just the Mailbox Role installed.  It should be noted, one of the coolest feature of the DAG, is that the mailbox role does not have to be installed by itself for it to be part of a DAG.  You can have any combination of roles installed, and it will still work EXACTLY the same.  Below is a Visio of the setup:

DAG_Diagram

All of the Exchange 2010 is installed, as you do NO customization during the install, all is done after.  This means you do not have to re-install Exchange if you decide down the rode to make it part of a DAG. Let’s take a look at the network configuration.  First, the NY server. 

 02 Jun. 29 20.58

I have two NIC’s, one labeled “Client” and one labeled “Replication”.  The client NIC, is configured as normal, with an IP, Subnet Mask, Gateway, all the regular stuff.  The replication NIC should only be configured with an IP and subnet, NO DEFAULT GATEWAY:

03 Jun. 29 21.00

Now, select the advanced button, and select the DNS tab.  At the bottom, un-select the box to “Register this connection’s address in DNS”:

04 Jun. 29 21.01

Next select the WINS tab and select the radio button to disable NetBIOS over TCP/IP:

05 Jun. 29 21.01

After this, select OK to save your settings and return to the Network Connections screen.  Select Advanced->Adapters and Bindings.  Make sure your production or “Client” NIC is listed above “Replication”:

06 Jun. 29 21.03

Now, you may be wondering about the default gateway missing on the heartbeat network.  If you add a default gateway on two different NIC’s, windows provides you with a warning:

07 Jun. 29 21.04

Hmm, seems like this most certainly pertains to us.  Also, DAG’s still use the Windows Failover Clustering feature of Windows Server 2008.  Have a configuration with a default gateway on the replication or heartbeat NIC is not supported, as very odd behavior can be exhibited.  So, then the question is asked, well the network’s are routed, how do we tell the replication NIC on one node, how to get to the replication networks of the other nodes?  For this, we add static routes to the individual server’s routing tables.  Tim McMichael had a great article about this, and you can read it here

So, on the NY node, we want it to contact the LN node’s replication network of 172.17.1.0/24 on its replication network of 172.16.1.0/24.  The gateway on the NY side is 172.16.1.254, so we run the following command:

route add 172.17.1.0 MASK 255.255.255.0 172.16.1.254 –p

08 Jun. 29 21.11

The –p makes it consistent across reboots.  We can check if it was successful with the route print command:

09 Jun. 29 21.13

So now, all replication and heartbeat traffic should pass through the specific replication NIC, over the replication network, to the replication NIC of the London node.  Repeat this step for ALL your replication networks, on all nodes.  For the London node, with a gateway on the London replication network of 172.17.1.254, the command back to NY would be:

Route Print 172.16.1.0 MASK 255.255.255.0 172.17.1.254 –p

Okay, that does it for part 1 of this series.  We went over the basic concepts of the DAG, and how to set up the networking for it.  In the next section, we’ll go over how to create the DAG, and add nodes to it.  Stay tuned.