Issues with IPv6 and Transport Servers using DNS Delivery in Exchange 2007 and General Troubleshooting Steps

 

I recently ran into a little bit of an issue at a company I was working with regarding their Exchange 2007 installation.  At the company, we had installed 2 Edge Transport servers in their main site in NY, and 1 Edge Transport server at their secondary location in Boston. 

One of their user’s complained that when they sent email to a specific domain, say xzy.com, they were getting delivery delayed messages, and eventually full blown NDR messages:

As we can see by the NDR, the message expired.  This happens when Exchange cannot connect to a certain destination mail server (such as the receiving company’s server is down), or there is no path to the destination.  The 1st is usually the fault of the receiving organization, the second is usually a configuration problem on your end.  Needless to say, we set out to troubleshoot.

Some basic stuff out of the way first.  All three Edge Servers were configured identical, and all experienced the same exact behavior.  All use Send Connectors, configured to deliver email using DNS, and thus connect directly to the destination domain.

The first thing I did, was the old telnet to the email server trick, and see if I can send email manually through telnet.  First, you need to figure out the receiving email server for the domain in question.  You can do this using the nslookup command.  In a command prompt, enter the command nslookup and hit return.  This will cause the machine your working off of to connect to its default DNS server, in NSLOOKUP mode.

Now, how do we find the server or servers that are responsible for receiving email on behalf of the organization?  Why, by searching for MX records of course!  In NSLOOKUP, tell the DNS server that you only want to know the MX records for a domain.  You do this by setting the query to MX only with the set q=mx command:

Next, enter the domain you are having trouble with, such as espn.com:

All the entries listed, are servers that receive email on behalf of espn.com.  Next, we want to see if we can send email to those servers, using telnet.  Which server should we pick?  Honestly, since they are all the same priority, to be really thorough, you can do all.  If one had a lower priority, start with that one, and work your way back up through the highest one.

Open up another command prompt, and run the command telnet nameofserver.domain.com 25 and hit enter:

This is your greeting from the remote server.  Now, to send email, you must issue several commands.  First, introduce yourself using the helo  yourserver.yourdomain.com command.  Replace yourserver.yourdomain.com with the external DNS name of the server your connecting from.  If you don’t, the remote server may tell you that you forged your name:, and it may reject your email:

Correct:

Incorrect:

The whole process will end up looking like this:

Okay, we’ll this means email was successfully sent from my Edge Transport server, to their email servers.  So that means that their wasn’t any connectivity issue between the servers.  Hmmm.  Next, on to Connectivity Logging!

Connectivity logging is not turned on by default, but can be configured by right clicking on the server in the console, and going to properties->Log Settings:

Check the box to “Enable Connectivity Logging” and then select browse for the location. 

When I checked the log, this is what I found for the domain in question:

The 72.21….. IP address is actually my DNS server for this particular Edge Transport server, and as you can see, it’s returning a DNS failure for that domain.  Well, that’s odd, being with the NSLOOKUP we already determined that we could resolve names for that domain on this particular server.

As a test, I changed DNS servers to be ones from a completely different company and……same problem.

We’ll, now we now why the emails are expiring, they cannot figure out how to get to the domain in question, so they sit in the queue until they expire and the server generates an NDR.

So we know its a problem with name resolution, but have no idea why it would be failing.  The next step I took was to use a network analyzer like WireShark to see what was happening.  Here is a sample capture for the domain in question that was giving me problems:

Well, well well, here we have a DNS failure of Standard Query AAAA.  So, what’s going on here?  We’ll it seems that the server is performing ONLY an IPv6 DNS lookup, and not doing a IPv4 lookup.  Since the domain doesn’t have an IPv6 record for their domain, the query is failing. 

I reached out to Microsoft and it seems that this is a fairly common issue with Exchange 2007 servers working on Windows Server 2008 machines, as they come installed with IPv4 and IPv6.  Microsoft does not have an official fix for it, but does have three potential solutions for the problem.

1. Place a regular SMTP server ahead of the Edge Transport server, and have the Edge Server forward all outgoing mail to this server as a smart host. (this is in my opinion the worst solution)
2. Create a new Send Connector for that particular domain as an address space.  Set all email to forward through this connector as a smart host and add all MX records as potential smart hosts for this connector (this works very well, with the only potential problem being if the problem is spread across a lot of domain’s, there is a lot of work for the administrator)
3. On the Send Connector, check the “Use the External DNS Lookup on the transport server”

Even if you do not configure specific External DNS servers on the Edge or Hub Transport servers, this will cause the server to only perform a standard IPv4 lookup, which will resolve the issue.

Hopefully this article can help you when troubleshooting email delivery issue’s, giving you some of the steps you can take to track down the specific issue your users are having.

Exchange 2010 Archive Mailbox and Retention Policies – Part 1

 

PST’s and Mailbox Limits.  Those two items keep Exchange Administrator’s up at nights.  One of the biggest battles between the end users and the administrator is mailbox size and retention.  It’s pretty well known that the bigger the mailbox get’s, usually the worse the performance gets.  Admins have been trying for years to get users to get their mailbox size down, and users always fight back.  With the dramatic changes that the Exchange Team has made to the Mailbox Store in Exchange 2010, it is now possible to have huge mailboxes’ (10GB+) to support the growing need’s of our end users.

Problem is, we still want to get the best performance possible out of our mailbox’s.  For archive purposes, the only “built in” solution from Microsoft was to export data to PST files.  PST files though are not managed by the organization, are prone to corruption, not accessible through OWA, and are generally messy.  Company’s were forced to move towards 3rd party utilities to satisfy their archiving and compliance needs.

One of the new features in Exchange 2010 is the Archive Mailbox feature.  Simply put, the Archive Mailbox is an extra mailbox assigned to the user, that’s meant to hold older, less accessed data.  For instance a user could place every email older than 1 year in the archive folder, keeping only new constantly accessed data in the primary mailbox.  The Archive Mailbox is integrated into the users Outlook Profile in Outlook 2010:

As well as Outlook Web App (the new name for Outlook Web Access in Exchange 2010):

There are some caveat’s to the Archive Mailbox feature:

1. Only Outlook 2010 supports the integration of the Archive Mailbox in the user profile
2. The archive mailbox is placed in the SAME database as the primary mailbox

Word on the street is that Microsoft is working on a plug in or an update to Outlook 2007 that will allow the older version of Outlook to access the Archive Mailbox.  Still, many companies have an Office 2003 installation that will be hard to uproot to 2010 for this feature.

The second point I think is the one that really hurts this feature.  The fact that the archive mailbox is part of the same database as the primary mailbox.  I understand that in 2010, the IOPS requirement has been dramatically lowered, and now the organization can run on SATA or Tier-2 disk’s, but many company’s want to segregate their data onto different tier’s and speed of storage.  I think this aspect of the feature will end up hurting Microsoft.  Let’s see if they make a change in the future. 

I digress.  The Archive Mailbox is essentially meant to replace the use of PST’s.  The best part is you can drag data from existing PST’s into the archive, just like you can drag messages from your inbox to the archive.  But the real power is setting this up to be done with policy’s, called Retention Policy’s. 

As administrator’s, we can control the length of time that users are allowed to keep items in their primary mailbox.  This is an extension of the Management Folder’s feature from Exchange 2007.  In 2007 however, users had to place email’s in certain folder’s, be it inbox, or a created folder, so that the policy’s were enacted properly.  2010 uses the concept of Retention Policy’s as well as Retention Policy Tag’s to enforce these settings. 

Retention Policy Tag’s are classification’s that are set for a folder or a type of item.  For instance you can create a Retention Policy Tag for the inbox, and set it to archive anything over 90 days.  You could also set a Retention Policy Tag for any calendar item over 180 days to delete and not archive. 

You would then group this tag’s into a Retention Policy, which would then be applied to a mailbox.

By default, Exchange 2010 comes with two retention policy’s, Default Archive Policy, and Arbitration. 

The Default Archive Policy comes with predefined tags:

1. Personal never move to archive
2. Personal 1 year move to archive
3. Personal 5 year move to archive
4. Default 2 year move to archive

You can check these settings by entering the following powershell command:

Get-RetentionPolicy *default* | fl

Every mailbox that is archive enabled is automatically assigned the default retention policy.  You can determine the retention policy by running the command Get-Mailbox jsmith | select Name,RetentionPolicy:

So according to the Default Archive Policy, the user can tag items as one of the three personal setting’s, and then have it moved to archive after the specified time, and anything not tagged will be moved to the archive after 2 years.  Retention Policy’s base the time or age of the message on when the item was delivered, or if the item wasn’t delivered (such as calendar item or post), when the item was created.

The Arbitration Retention Policy is used for moderated mailboxes.  Moderated mailboxes are used for users who mail must pass through a manager for approval first, or for group membership approval.  This policy should only be used in conjunction with these type of mailboxes.

Next, we’ll create a user and assign him an Archive Mailbox

Creating the user is straightforward and exactly the same as normally creating a mailbox, except for one thing.  Towards the end of the mailbox creation period, you’ll be prompted with this screen:

You can create an archive mailbox at the mailbox creation time, or after the mailbox is created by right clicking the user and selecting

One thing to keep in mind is you cannot mix Retention Policy’s and Managed Folder Mailbox Policy’s.

Notice how the icon changes for Archive Enabled mailbox’s:

If we navigate to the each user in ADSIEDIT, you’ll see some other difference’s in available attributes.  The three in particular are msExchArchiveGuid, msexchArchiveName, and msExchMailboxtemplateLink.

Notice how the user on the right the value’s are blank, and how they are populated on the John Smith user on the left.  Also, notice the msEchMailboxTemplateLink value.  This is the retention policy applied to this particular user. 

In this first part, we discussed the new Online Archive Mailbox feature of Exchange 2010, its concept and purpose, and then discussed how administrator’s can apply them using Retention Policy’s.  In part two of this article.  We’ll get in and get our hands dirty, and start applying policies, and seeing how Exchange manages and move’s item’s accordingly.

Uncovering the New Move Request Feature in Exchange 2010

 

One of the biggest issue’s any administrator faces with any type of Exchange upgrade or migration is the prospect of mailbox moves.  The issue comes from the fact that a mailbox move, from the moment it’s started, makes the mailbox unavailable to the end user until it’s completed.

This comes from the way that mailbox moves are done in Exchange 2000/3/7.  The mailbox move is actually a MAPI copy operation.  The reason’s behind this are clear, Exchange need’s to lock in the mailbox, then copy it, to ensure that no data is lost. The user is stuck waiting for the mailbox move to complete, meaning they can’t work.  This ends up in mailbox moves being forced to happen late at night in bunches, through the use of scripting or other methods. 

One of the exciting new features of Exchange 2010 is online mailbox move’s, which are called Mailbox Move Requests.  This new feature allows administrators to move mailbox’s while the user is actively using it.  How does this work you ask?  The magic lies in a new service that is installed on Exchange 2010 Client Access Servers, the Microsoft Exchange Mailbox Replication Service:

 

Exchange 2010 no longer performs a MAPI copy operation to perform any of it’s mailbox moves.  Now, when a move request is created, the Microsoft Exchange Mailbox Replication Service or (MRS) is responsible for replicating the mailbox from it’s source, to it’s destination. An initial replication occurs, and then incremental updates happen until the service can complete the move.  Once the service completes’ the sync, the user receives a message to restart outlook.  They restart, their mailbox is again available.  The only downtime was for them to restart Outlook, not bad at all.

The nice part about this, is that mailbox move’s from Exchange 2007 benefit from this feature when moving to an Exchange 2010 mailbox.  Keep in mind that you must be at service pack level 2 with Exchange 2007 for it and 2010 to interoperate.

Let’s take a look at actually performing one of these.  In our environment we have two Exchange 2007 servers, DEVLOCALHT1, which is a Hub Transport/Client Access Server, and DEVLOCALMB1, which is a Mailbox Server.  Then we have three Exchange 2010 servers.  DEVLOCALHT2010, which is a Hub Transport/Client Access Server, and then DEVLOCALNODE1 and DEVLOCALNODE2 which are both Mailbox Servers.  The Mailbox Servers are joined into a Database Availability Group or DAG.  If your not sure what a DAG is, see my article series:

DAG – Part1

DAG – Part2

DAG – Part 3

DAG – Part 4

Our user, creatively named Paul Ponzeka, has an Exchange 2010 mailbox. We currently have two Mailbox Database’s in Exchange 2010, MDB1 and MDB2:

Currently Paul Ponzeka’s mailbox is located on MDB1, and we’ll move him to MDB2.  In the Exchange 2010 EMC, navigate to Recipient Configuration->Mailbox.  Select Paul Ponzeka, right click and select New Local Move Request:

Don’t let the language fool you, if your moving a mailbox anywhere within the SAME Active Directory Forest, its a Local Move.  If your moving the mailbox Cross-Forest’s, its a Remove Move.

Select the target mailbox database:

After selecting next, you’ll see a familiar screen regarding what to do regarding corrupted items.  You can choose to have the move fail, or to ignore up to a certain amount of items.

After you select next, you’ll have a summary page, select the “New” button, and as always, it will provide you with the powershell command for the equivalent.

Now, if you navigate to Recipient Configuration->Move Request, you’ll see the move request, and it’s progress:

You can also get the progress through the Exchange Management Shell by running the command:

Get-MoveRequest

Also, in the Event Viewer of DEVLOCALHT2010, the Client Access Server handling the move, we will note that Event ID 1102 is logged regarding the start of the move:

Once the move is complete, Event ID 1107 will be logged:

And if we notice back in the EMC, the status of the move:

And the shell:

Now, the client, who’s Outlook has been open the whole time, will receive the following message:

Once the client restart’s outlook, their mailbox is back, and they’ve only been out of Outlook from the time the move completed, till when they restart.

The move’s work EXACTLY the same way as from an Exchange 2007 SP2 mailbox with no difference. 

The new online mailbox moves, through the Move Mailbox Request feature of Exchange 2010 will allow administrators to move mailbox’s with minimal downtime and interruption to the end users.

The “Require That All Senders are Authenticated” Does Not Work As Expected in Exchange 2007

 

I recently ran across an issue where one company was setting the “Require that all senders are authenticated” checkbox on a particular mail distribution group in Exchange 2007.

Most organizations will do this, to ensure that only users of the internal Exchange organization can email this group, effectively stopping external users from emailing it.  This is particularly useful if the group is an extremely broad group such as “ALLUSERS” or something similar.

The problem was that even with this checked, the group was still receiving emails from outside senders.  What gives?  Well, I started doing a little digging, and this is what I found.

The company had followed this article by Scott Landry of the Exchange Team.  The articles discusses two ways to allow application servers to relay through Exchange 2007, applications such as SharePoint. 

If you read Scott’s article, his tone indicates that these applications are really internal applications.  He also lists two method’s for doing so.  The first being to set the receive connector to externally secured, and the second with manually applying permissions using powershell.  The company who was having this issue, had used the first method, eternally secured, but was using it to allow a 3rd party SMTP server that was used for spam filtering on it’s DMZ, to relay into Exchange.  So what’s the problem?  Essentially the method they used, gave TOO much permission to the 3rd party server.  Let’s take a look.

Scott’s article states to create a new receive connector, and set this connector to allow the IP address of the 3rd party server.  So, assuming our third party server has an IP address of 192.168.1.5, the connector would look like the following:

Next, the article states to edit the authentication and permissions tab’s, so that “Exchange Servers” are set on the Permission Groups tab:

  and then “Externally Secured” is selected for authentication:

After this, the 3rd party server would be allowed to relay.  So you ask, what’s the problem.  Well, by setting the above, most importantly the Exchange Servers on the Permission Groups, you are essentially telling Exchange 2007, that any email that comes in this connector, should be treated the exact same as if it originated from an Exchange 2007 server.  This means that the emails will bypass anti-spam settings, as well as appear as if they were sent from inside the organization.  Scott lays out exactly what permissions are set:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Now, any email from this connector, will bypass the “Require That All Senders are Authenticated” check box, because according to Exchange 2007, they are authenticated!

So, how do you fix it?  It couldn’t be easier, Scott’s article already tells us how.  He lists Option 2, grant the relay permission to Anonymous Users on the connector.

If we change the permission group, so that only “Anonymous” is checked, and remove “Externally Secured” from the authentication tab:

And then run one little powershell command:

Get-ReceiveConnector “3rd Party Relay” | Add-ADPermission –User “NT Authority\Anonymous Logon” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”:

That’s it.  Now, the third party server can send emails into the organization, but they are treated as outside emails.  This means they will be subject to size limit’s, anti-spam, as well as being rejected if they are sent to a group that has the “Require That All Senders Are Authenticated” setting checked.

Creating a Database Availability Group in Exchange 2010 – Part 4

 

In part 3 of this series, we configured the replication networks for the DAG, as well as add database copies to the DAG.  In Part 4, the final part of this series, I’ll show you how to move the active copy between different servers, and how this affect’s the end user. 

Remember way back in Part 1 of this series, I mentioned that Outlook client’s now connect to a Client Access Server to connect to their respective mailbox’s, instead of connecting directly to the Mailbox server?  We’ll, part of the reason why, is that in Exchange 2010, Microsoft wanted the failovers to be less than 30 second’s, no matter what.  By moving the Outlook client to connect to the CAS server’s, you can meet this threshold.  Client Access Server’s are notified about a database move, and thus can redirect their client’s accordingly.

Take our user, Paul A. Ponzeka, who’s mailbox is is located on the Accounting database we created in part 3.  The active copy of the database is on NYDAGNODE1. 

When we create his profile in Outlook, look at the server he connects to:

Notice how the Outlook client connects to the CAS server, and not the mailbox server, which in this case would be NYDAGNODE1.  Everything, except public folder connections, are proxies through a CAS server.

Okay, so now let’s move the active copy to the London server, LNDAGNODE1. We can do this through the console, or the shell.  In the console, navigate to Organization Configuration –>Mailbox->Database Management.  Simply right click on the database in question, and select “Move Active Mailbox Database”.  Fill out the menu, with which server you want to move it to.  The override mount dial allows you to specify an override for the amount of data loss your willing to accept.  We don’t have a need to change this, so just leave it be and hit move:

So now the system will move the database, and if you note, in our example, it took 6 seconds, also note the command shell you could have run to get the same effect:

Now the accounting database will go to Mounted on LNDAGNODE1 and healthy under copy status on NYDAGNODE1:

There you go, all set!  Again, the threshold will be 30 seconds according to Microsoft for the failovers!

So in wrapping, I wanted to touch on a couple of the core differences between Exchange 2010 DAG’s, and CCR clusters, both normal and stretched.

First, in 2007 CCR clusters, when you perform the initial seeding, you need to have every transaction log for that particular storage group, otherwise seeding will fail.  This is no longer true with 2010.  You can add a DAG at ANY POINT.  Second, in 2007, once you moved the active copy to the passive node, you had to re-seed the previously active copy from the passive node before that node could ever be brought back on line.  This is again no longer true in 2010.  You can move back and forth without reseeding.

Third, CCR’s were limited to just 2 nodes, you are limited to 16 members of a DAG in 2010!  In 2007, even if you were doing a stretched cluster with 2008, both nodes had to be members of the same AD site.  This had to do with the nodes having to speak to the same set of Hub Transport servers to avoid data loss.  With 2010 and the inclusion of the new Shadow Transport feature, this is not needed.  So you can have any number of DAG members, in any number of different AD sites.  The outlook client’s will just be redirected to a CAS server in the local site of the now active mailbox server copy, again in under 30 seconds!

Another huge difference, is that since the database’s are no longer members of the servers, the failovers are on a per database level.  What this means is if a server in NY, has three databases, and all of them are active, and you have a situation where only one of the database’s go offline, only that database will be activated on another copy in the DAG, leaving the previous two untouched!

In this four part series, we went over the theory of the Database Availability Group feature of Exchange 2010, as well as how to configure and test the DAG.  Overall, it is a great improvement for both the High Availability, and Site Resiliency model for Exchange. 

Creating a Database Availability Group in Exchange 2010 – Part 3

 

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.

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

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

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

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. 

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:

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:

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. 

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:

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

 

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:

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

 

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:

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

New-DatabaseAvailabilityGroup -Name ‘DAG01′ -FileShareWitnessShare ‘\\NYDC01\DAG01′ -FileShareWitnessDirectory ‘C:\DAG01′

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

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.

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:

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

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

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:

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

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

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:

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

 

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:

 

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:

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. 

 

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:

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”:

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

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”:

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:

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

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

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.

User’s Receive a Message Stating that “User” Has Forwarded Your Meeting Request to Additional Recipients

 

I recently ran into a problem where some user’s were beginning to receive email messages from Exchange, informing them that their Meeting Request’s were being forwarded to additional recipients.  The issue popped up during a migration from Exchange 2003 to Exchange 2007:

So, easy fix right, it has to do with the Mailbox Calendar Setting option “RemoveForwardedMeetingNotifications”, second from the bottom in this screenshot.  You can check this status by running the command

Get-MailboxCalendarSettings user | fl

So, here it’s false, we want to change it to true.  Do that by running the following command. 

Set-MailboxCalendarSettings user –RemoveForwardedMeetingNotificiations:$true

Bam, problem fixed right?  Well, in this case, no.  The user was still receiving them.

Well, I started digging a little more.  Here is the basic background.  An admin was scheduling appointment’s for her boss, and the boss was receiving these messages.  She would either create the invitation on behalf of the boss, and invite attendees, in which case the forwarded emails would come, or edit a pre-existing appointment, in which case they would also be sent out.  Needless to say, the boss wanted it fixed!

We had recently moved her mailbox to Exchange 2007, which is when the issue began.  We investigated the issue a little further.  Turns out, she had been given access to the boss’s calendar by the boss right clicking his calendar and changing the share permissions. 

We created a test situation, Paul Ponzeka’s mailbox on Exchange 07, just like the admin, and Adam Smith’s mailbox on an Exchange 03 server, just like the boss’s.  We assigned permissions for Adam Smith’s calendar to Paul Ponzeka by changing the share permissions on the calendar.  Using Paul Ponzeka’s outlook, we opened Adam Smith’s calendar, and created a meeting invite.  Sure enough, we received the following email in Adam Smith’s Mailbox:

So we have duplicated the issue.  Next, on Adam Smith’s Outlook, we added Paul Ponzeka as a delegate, but just gave him access to the calendar and the same permissions he had before:

So, now we have the permissions the same, but the user is a delegate.  Again, on Paul Ponzeka’s Outlook, we create a meeting request in Adam Smith’s calendar, NO MESSAGE!  We tested the rest of the ways the admin was creating invites, all resolved.

It seems there is a bug that causes these messages, unless the user is a delegate.  It also seems like the “Remove Forwarded Meeting Notifications” setting in powershell, only applies if the user is a delegate.

Just for thoroughness, we tested with both the “boss’s” mailbox, and the “admin’s” mailbox on an Exchange 2007 server, and the exact same behavior was exhibited.  It seems it doesn’t matter where the boss’s mailbox is, 2003 or 2007.  In this example, the organization was running Exchange Server 2007 SP1 with Rollup 7.

Adding a Custom Global Address List to an Offline Address Book in Exchange 2007

 

In most organizations, the Default Global Address List, or GAL, more than fits their needs.  However, some organizations like to create custom GAL’s.  This could be either for the use of address list segregation with a hosted solution, or the Default GAL lists service accounts that the users shouldn’t see.  Creating a custom GAL is easy, especially in Exchange 2007. 

However, an issue may arise when after you have created this custom GAL, regarding users in cached mode in Outlook.  When a user is in cached mode, their GAL is actually the Offline Address Book.  By default, the Default Offline Address Book includes the Default GAL as its source.  So this custom GAL you just created isn’t seen by the users in cached mode. 

The trick to this, is to create a new Offline Address Book, and add the new GAL to it.  For this, you will need to use powershell.  So lets say you have a custom GAL called “Test GAL” in Exchange 2007.  You can check what GAL’s you have by running the Get-GlobalAddressList command:

We are going to create a new Offline Address Book, with the “Test GAL” as the included GAL to generate the OAB from.  Also, don’t forget, a specific Mailbox server has to be responsible for generating the OAB, so we are going to use server Test-EX07B.  The command will be as follows:

New-OfflineAddressList –Name “Test OAB” –AddressLists “Test GAL” –Server Test-EX07B

 

So you have your new “Test OAB”.  Just a heads up, while in the Exchange Management Console, you’ll be able to edit any item of the new OAB, except the address list.  This means you can change the name, and set the delivery mechanism for public folder distribution or web services distribution, but you can only add address lists through the shell:

 

Now all thats left to do is add the “Test OAB” as the default Offline Address Book for the database’s in your organization.  You can either right click on each database in your organization, select the Client Settings tab and change to the “Test OAB”:

Or, if you want to do it en masse for every database in your organization, you would run the following command from the shell:

Get-MailboxDatabase | Set-MailboxDatabase –OfflineAddressBook “Test OAB”