Many customers have requested instructions on how to enable standby continuous replication to use an alternate network interface.  By design standby continuous replication always uses the “public” interface to ship logs and seed the database.

Over the past few weeks we have been working with the Exchange product group on a “supported” method to allow standby continuous replication to use an alternate network interface.  This blog will detail how to implement these steps and what effects it has on the overall solution.

First if you are reading this post you should review the replication service deep dive whitepaper located at http://technet.microsoft.com/en-us/library/cc535020.aspx (“White Paper:  Continuous Replication Deep Dive").  When reviewing this whitepaper it is important to pay attention to what sources are involved in replication when using standby continuous replication.  For example:

• When the source is a standalone mailbox server, logs are replicated by connecting to shares mapped to the server name.
• When the source is a cluster continuous replication server, logs are replicated by connecting to shares mapped to the ACTIVE node server name.
• When the source is a single copy cluster, logs are replicated by connecting to shares mapped to the clustered mailbox server name.

Keeping these parameters in mind will help you understand how the following changes will allow for standby continuous replication to use an alternate network interface.

The steps to implement this vary little by operating system.  Windows 2008 though does introduce some changes to the way file shares are handled.  Please review this blog for information on how share scoping in Windows 2008 effects the operations of the replication service.  (http://blogs.technet.com/timmcmic/archive/2008/12/23/exchange-replication-service-exchange-2007-sp1-and-windows-2008-clusters.aspx)

The following instructions are based on Exchange 2007 SP1 with RU7.  All customers implementing these instructions are encouraged to do so on Exchange 2007 SP1 RU7.

Replication behavior when using standby continuous replication over an alternate network interface.

When the instructions are implemented as documented, all network traffic from the SCR target to the SCR source is first routed through the private interface.  This can be verified with netmon by reviewing SMB (Windows 2003) or SMBv2 (Windows 2008) traffic. 

It is important to note that these instructions only effect the LOG SHIPPING functionality of SCR.  Other functions such as update-storagegroupcopy will only occur using the public interface.  This requires that both the source and target have the ability to communicate over both the public and private interfaces.  Planning for network sizing should take into account that re-seeding operations using update-storagegroupcopy must occur over the public interface.

Unlike continuous replication host names in CCR there is no automatic failover between interfaces.  Should the private interface serving log shipping be unavailable for any reason, log shipping will fail.  With this in mind appropriate monitoring of log copy operations is necessary to ensure replication is functioning.  In the event that the network link serving replication is not available, the host file should be removed and replication resumed over the public interface.  As mentioned earlier your network design considerations should take into account the need to communicate over both the public and private interfaces as well as the potential need to perform log shipping operations over the public interface. 

For the solution to be fully supported network connectivity must be available between the source and target on both the private and public interfaces.  All replication operations must be able to function on both interfaces.

When engaging product support services for assistance with replication when these steps are used you may be requested to remove the host file and verify that log shipping works as originally designed with no modifications.

Behavior of commandlets used for implementing / managing standby continuous replication when replication is enabled to use an alternate interface.

Get-storagegroupcopystatus:  No issues noted.

Enable-storagegroupcopy:  No issues noted.

Disable-storagegroupcopy:  No issues noted.

Restore-storagegroupcopy:  No issues noted when machines involved are running Exchange 2007 SP1 RU7.  Prior to RU7 it may be necessary to use restore-storagegroupcopy –force for the command to complete successfully.

Update-storagegroupcopy:  Because update-storagegroupcopy uses online streaming functionality to seed the database to the target the network traffic associated with this occurs over the public interface.

Suspend-storagegroupcopy:  No issues noted.

Resume-storagegroupcopy:  No issues noted.

Changes to the SCR activation process when replication is enabled to use an alternate interface.

Whether using the database portability method or the single node cluster method after running restore-storagegroupcopy the entries in the host file should be removed or commented out.  Once the removal is complete, dns resolver cache should be flushed (ipconfig /flushdns) and a ping from the target machine to it’s own name performed to ensure DNS resolves the correct IP address on the public interface.

When name resolution occurs successfully your move-mailbox –configurationonly or setup.com /recoverCMS can be run to complete the activation process.

**********************

Windows 2008

**********************

Configuring networks and network interfaces to support standby continuous replication using an alternate network interface on Windows 2008.

The first step is to configure the network settings for the network interface that will be used for standby continuous replication.  These instructions are performed on both the source and target machines.  To configure these settings:

• Select Start –> Control Panels –> Network and Sharing Center
• In the tasks pane, select “Manage Network Connections”
• Right click on the interface for SCR private replication, select rename.
  • Change the name of the interface to something meaningful indicating it’s purpose.
• Right click on the interface for SCR private replication, select properties.
  • Ensure that Client for Microsoft Networks is enabled.
  • Ensure the File and Print Sharing for Microsoft Networks is enabled.

• In the network properties, select “Internet Protocol Version 4 (TCP/IPv4)”, press properties button.
  • On the general tab:
    • Under “Use the following IP address”, provide a valid IP address and subnet mask.
    • Do not provide a default gateway.  (If the source and target reside on different subnets it will be necessary to utilize persistent static routes in order to ensure network communications follow the appropriate path.  Do not use two default gateways on a single host).
    • Do not provide any DNS servers under “Use the following DNS server addresses” .

• Selecting the advanced button, on the DNS tab:
  • Uncheck “Register this connection’s addresses in DNS”.

• Complete the changes by pressing OK three times.

The network configuration process is then completed by updating the network binding orders.  To update the network binding orders:

• Select Start –> Control Panels –> Network and Sharing Center
• In the tasks pane, select “Manage Network Connections”
• Ensure that the toolbar is displayed:
  • Select Organize –> Layout –> Menu Bar
• From the advanced menu select advanced settings.
• On the “Adapters and Bindings” tab, using the arrow keys, adjust the binding order so that the public facing interface is first on the list.  All other interfaces may be set in any order.

This completes the base networking configuration for standalone machines and clustered nodes.

Additional configuration steps for SCR source servers on Windows 2008.

• Exchange 2007 SP1 / Windows 2008 Standalone Mailbox Server Source
  • No additional configuration changes are necessary.
• Exchange 2007 SP1 / Windows 2008 Cluster Continuous Replication (CCR) Source
  • Windows 2008 enumerates all networks in a cluster for cluster use.  To ensure full supportability of the cluster, the cluster should be re-validated using the validation wizard in Failover Cluster Management.
  • No additional configuration changes are necessary.
• Exchange 2007 SP1 / Windows 2008 Single Copy Cluster (SCC) Source
  • Windows 2008 enumerates all networks in a cluster for cluster use.  To ensure full supportability of the cluster, the cluster should be re-validated using the validation wizard in Failover Cluster Management.
  • Enable the network for SCR replication for client connectivity.
    • Launch Failover Cluster Management
    • In the left hand pane, expand networks.
    • Identify the network that contains the interfaces used for standby continuous replication.
    • Right click on the network, select properties.
    • Select the checkbox next to “Allow clients to connect through this network”.
    • Press the OK button.
    • When prompted that the network is now available for client use, press the OK button.

• Enable an IP address resource in the Exchange Clustered Mailbox Server (CMS) group.
  • In the left hand pane, under services and applications, find the CMS group.
  • Right click on the group, select Add a Resource –> More Resources –> Add IP Address
  • This will create a not configured IP Address resource in the CMS group.

• Right click on the not configured IP Address resource and select properties.
• In the "Resource Name” field, enter and appropriate name.
• In the “Network” drop down, select the SCR replication network.
• In the “Static IP Address” fields input a static IP address valid on the SCR replication network.

• Press the OK button.
• Right click on the new IP address resource, select “Bring this resource online”.
• DO NOT UPDATE ANY DEPENDENCIES ON THIS RESOURCE OR MAKE THIS RESOURCE DEPENDANT ON ANY OTHER RESOURCE(S).

Additional configuration steps for SCR Targets on Windows 2008.

These instructions apply to both standalone and single node SCR targets based on Windows 2008.

Using notepad, open the hosts files located at c:WindowsSystem32DriversEtc

Depending on the source make the following changes:

• Exchange 2007 SP1 / Windows 2008 Standalone Mailbox Server Source
  • Add entries in the host file for both the NetBIOS and fully qualified domain name (FQDN).  Associate these names to the IP address assigned to the SCR network on the source server.
• Exchange 2007 SP1 / Windows 2008 Cluster Continuous Replication (CCR) Source
  • Add entries in the host file for both the NetBIOS names and fully qualified domain names (FQDN) of the source NODES.  Associate these names to the IP address assigned to the SCR network on the source nodes.
• Exchange 2007 SP1 / Windows 2008 Single Copy Cluster (SCC) Source
  • Add entries in the host file for both the NetBIOS name and fully qualified domain name (FQDN) of the source CMS.  Associate these names to the IP address created in the CMS group assigned to the SCR network.

Here is the output of a sample host file.

# Copyright (c) 1993-2006 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost
::1             localhost

#Exchange 2007 SP1 / Windows 2008 / Standalone Mailbox Server

10.1.1.1    2008-MBX1
10.1.1.1    2008-MBX1.exchange.msft

#Exchange 2007 SP1 / Windows 2008 / Cluster Continuous Replication (CCR)

10.1.1.3    2008-Node1
10.1.1.3    2008-Node1.exchange.msft
10.1.1.4    2008-Node2
10.1.1.4    2008-Node2.exchange.msft
10.1.1.8    2008-Node5
10.1.1.8    2008-Node5.exchange.msft
10.1.1.9    2008-Node6
10.1.1.9    2008-Node6.exchange.msft

#Exchange 2007 SP1 / Windows 2008 / Single Copy Cluster (SCC)

10.1.1.7    2008-MBX4
10.1.1.7    2008-MBX4.exchange.msft

Additionally, the replication service on occasion may have to resort to Netbios name resolution.  To ensure that the correct replication network is always returned, edit the LMHOST file and put entries for the netbios name and corresponding IP address.

Using notepad, open the LMhosts files located at c:WindowsSystem32DriversEtc

Here is a sample LMHost file.

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to computernames
# (NetBIOS) names.  Each entry should be kept on an individual line.
# The IP address should be placed in the first column followed by the
# corresponding computername. The address and the computername
# should be separated by at least one space or tab. The "#" character
# is generally used to denote the start of a comment (see the exceptions
# below).
#
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
# files and offers the following extensions:
#
#      #PRE
#      #DOM:<domain>
#      #INCLUDE <filename>
#      #BEGIN_ALTERNATE
#      #END_ALTERNATE
#      xnn (non-printing character support)
#
# Following any entry in the file with the characters "#PRE" will cause
# the entry to be preloaded into the name cache. By default, entries are
# not preloaded, but are parsed only after dynamic name resolution fails.
#
# Following an entry with the "#DOM:<domain>" tag will associate the
# entry with the domain specified by <domain>. This affects how the
# browser and logon services behave in TCP/IP environments. To preload
# the host name associated with #DOM entry, it is necessary to also add a
# #PRE to the line. The <domain> is always preloaded although it will not
# be shown when the name cache is viewed.
#
# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
# software to seek the specified <filename> and parse it as if it were
# local. <filename> is generally a UNC-based name, allowing a
# centralized lmhosts file to be maintained on a server.
# It is ALWAYS necessary to provide a mapping for the IP address of the
# server prior to the #INCLUDE. This mapping must use the #PRE directive.
# In addtion the share "public" in the example below must be in the
# LanManServer list of "NullSessionShares" in order for client machines to
# be able to read the lmhosts file successfully. This key is under
# machinesystemcurrentcontrolsetserviceslanmanserverparametersnullsessionshares
# in the registry. Simply add "public" to the list found there.
#
# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
# statements to be grouped together. Any single successful include
# will cause the group to succeed.
#
# Finally, non-printing characters can be embedded in mappings by
# first surrounding the NetBIOS name in quotations, then using the
# xnn notation to specify a hex value for a non-printing character.
#
# The following example illustrates all of these extensions:
#
# 102.54.94.97     rhino         #PRE #DOM:networking  #net group’s DC
# 102.54.94.102    "appname  x14"                    #special app server
# 102.54.94.123    popular            #PRE             #source server
# 102.54.94.117    localsrv           #PRE             #needed for the include
#
# #BEGIN_ALTERNATE
# #INCLUDE \localsrvpubliclmhosts
# #INCLUDE \rhinopubliclmhosts
# #END_ALTERNATE
#
# In the above example, the "appname" server contains a special
# character in its name, the "popular" and "localsrv" server names are
# preloaded, and the "rhino" server name is specified so it can be used
# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
# system is unavailable.
#
# Note that the whole file is parsed including comments on each lookup,
# so keeping the number of comments to a minimum will improve performance.
# Therefore it is not advisable to simply add lmhosts file entries onto the
# end of this file.

#Exchange 2007 SP1 / Windows 2008 / Standalone Mailbox Server

10.1.1.1    2008-MBX1

#Exchange 2007 SP1 / Windows 2008 / Cluster Continuous Replication (CCR)

10.1.1.3    2008-Node1
10.1.1.4    2008-Node2
10.1.1.8    2008-Node5
10.1.1.9    2008-Node6

#Exchange 2007 SP1 / Windows 2008 / Single Copy Cluster (SCC)

10.1.1.7    2008-MBX4

This completes the configuration steps for Windows 2008.

**********************

Windows 2003

**********************

Configuring networks and network interfaces to support standby continuous replication using an alternate network interface on Windows 2003.

The first step is to configure the network settings for the network interface that will be used for standby continuous replication.  These instructions are performed on both the source and target machines.  To configure these settings:

• Select Start –> Control Panels –> Network Connections
• Right click on the interface for SCR private replication, select rename
  • Change the name of the interface to something meaningful indicating it’s purpose.
• Right click on the interface for SCR private replication, select properties.
  • Ensure that Client for Microsoft Networks is enabled.
  • Ensure the File and Print Sharing for Microsoft Networks is enabled.

• In the network properties, select “Internet Protocol (TCP/IP)”, press properties button.
  • On the general tab:
    • Under “Use the following IP address”, provide a valid IP address and subnet mask.
    • Do not provide a default gateway.  (If the source and target reside on different subnets it will be necessary to utilize persistent static routes in order to ensure network communications follow the appropriate path.  Do not use two default gateways on a single host).
    • Do not provide any DNS servers under “Use the following DNS server addresses” .

• Selecting the advanced button, on the DNS tab:
  • Uncheck “Register this connection’s addresses in DNS”.

• Complete the changes by pressing OK three times.

The network configuration process is then completed by updating the network binding orders.  To update the network binding orders:

• Select Start –> Control Panels –> Network Connections
• From the advanced menu select advanced settings.
• On the “Adapters and Bindings” tab, using the arrow keys, adjust the binding order so that the public facing interface is first on the list.  All other interfaces may be set in any order.

This completes the base networking configuration for standalone machines and clustered nodes.

Additional configuration steps for SCR source servers on Windows 2003.

• Exchange 2007 SP1 / Windows 2003 Standalone Mailbox Server Source
  • No additional configuration changes are necessary.
• Exchange 2007 SP1 / Windows 2003 Cluster Continuous Replication (CCR) Source
  • No additional configuration changes are necessary.
• Exchange 2007 SP1 / Windows 2003 Single Copy Cluster (SCC) Source
  • Enable the network for SCR replication for client connectivity.
    • Launch Cluster Administrator
    • In the left hand pane, expand “Cluster Configuration” –> “Networks”.
    • Identify the network that contains the interfaces used for standby continuous replication.
    • Right click on the network, select properties.
    • Select “Enable this network for cluster use” and “All Communications (mixed network)”.  Press the OK button.

• Enable an IP address resource in the Exchange Clustered Mailbox Server (CMS) group.
  • In the left hand pane, expand groups, find the CMS group.
  • Right click on the group, select New –> Resource.
  • Provide an appropriate name in the Name field.
  • Provide an appropriate description in the Description field.
  • For Resource Type, change the drop down to “IP Address”

• Press the next button.
• Verify that the possible owners of the CMS group are correct.  Press the next button.

• DO NOT UPDATE ANY DEPENDENCIES ON THIS RESOURCE OR MAKE THIS RESOURCE DEPENDANT ON ANY OTHER RESOURCE(S).

• In the address field type an appropriate static IP address for the SCR replication network.
• In the subnet mask field type the appropriate subnet mask.
• In the network drop down ensure that the SCR replication network is selected.
• Keep “Enable NetBIOS for this address” selected.

• Press the finish button.
• Right click on the new IP address resource, select “Bring this resource online”.

Additional configuration steps for SCR Targets on Windows 2003.

These instructions apply to both standalone and single node SCR targets based on Windows 2003.

Using notepad, open the hosts files located at c:WindowsSystem32DriversEtc

Depending on the source make the following changes:

• Exchange 2007 SP1 / Windows 2003 Standalone Mailbox Server Source
  • Add entries in the host file for both the NetBIOS and fully qualified domain name (FQDN).  Associate these names to the IP address assigned to the SCR network on the source server.
• Exchange 2007 SP1 / Windows 2003 Cluster Continuous Replication (CCR) Source
  • Add entries in the host file for both the NetBIOS names and fully qualified domain names (FQDN) of the source NODES.  Associate these names to the IP address assigned to the SCR network on the source nodes.
• Exchange 2007 SP1 / Windows 2003 Single Copy Cluster (SCC) Source
  • Add entries in the host file for both the NetBIOS name and fully qualified domain name (FQDN) of the source CMS.  Associate these names to the IP address created in the CMS group assigned to the SCR network.

Here is the output of a sample host file.

# Copyright (c) 1993-2006 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost

#Exchange 2007 SP1 / Windows 2003 / Standalone Mailbox Server

10.1.1.1    2003-MBX1
10.1.1.1    2003-MBX1.exchange.msft

#Exchange 2007 SP1 / Windows 2003 / Cluster Continuous Replication (CCR)

10.1.1.3    2003-Node1
10.1.1.3    2003-Node1.exchange.msft
10.1.1.4    2003-Node2
10.1.1.4    2003-Node2.exchange.msft

#Exchange 2007 SP1 / Windows 2003 / Single Copy Cluster (SCC)

10.1.1.7    2003-MBX4
10.1.1.7    2003-MBX4.exchange.msft

Additionally, the replication service on occasion may have to resort to Netbios name resolution.  To ensure that the correct replication network is always returned, edit the LMHOST file and put entries for the netbios name and corresponding IP address.

Using notepad, open the LMhosts files located at c:WindowsSystem32DriversEtc

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to computernames
# (NetBIOS) names.  Each entry should be kept on an individual line.
# The IP address should be placed in the first column followed by the
# corresponding computername. The address and the computername
# should be separated by at least one space or tab. The "#" character
# is generally used to denote the start of a comment (see the exceptions
# below).
#
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
# files and offers the following extensions:
#
#      #PRE
#      #DOM:<domain>
#      #INCLUDE <filename>
#      #BEGIN_ALTERNATE
#      #END_ALTERNATE
#      xnn (non-printing character support)
#
# Following any entry in the file with the characters "#PRE" will cause
# the entry to be preloaded into the name cache. By default, entries are
# not preloaded, but are parsed only after dynamic name resolution fails.
#
# Following an entry with the "#DOM:<domain>" tag will associate the
# entry with the domain specified by <domain>. This affects how the
# browser and logon services behave in TCP/IP environments. To preload
# the host name associated with #DOM entry, it is necessary to also add a
# #PRE to the line. The <domain> is always preloaded although it will not
# be shown when the name cache is viewed.
#
# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
# software to seek the specified <filename> and parse it as if it were
# local. <filename> is generally a UNC-based name, allowing a
# centralized lmhosts file to be maintained on a server.
# It is ALWAYS necessary to provide a mapping for the IP address of the
# server prior to the #INCLUDE. This mapping must use the #PRE directive.
# In addtion the share "public" in the example below must be in the
# LanManServer list of "NullSessionShares" in order for client machines to
# be able to read the lmhosts file successfully. This key is under
# machinesystemcurrentcontrolsetserviceslanmanserverparametersnullsessionshares
# in the registry. Simply add "public" to the list found there.
#
# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
# statements to be grouped together. Any single successful include
# will cause the group to succeed.
#
# Finally, non-printing characters can be embedded in mappings by
# first surrounding the NetBIOS name in quotations, then using the
# xnn notation to specify a hex value for a non-printing character.
#
# The following example illustrates all of these extensions:
#
# 102.54.94.97     rhino         #PRE #DOM:networking  #net group’s DC
# 102.54.94.102    "appname  x14"                    #special app server
# 102.54.94.123    popular            #PRE             #source server
# 102.54.94.117    localsrv           #PRE             #needed for the include
#
# #BEGIN_ALTERNATE
# #INCLUDE \localsrvpubliclmhosts
# #INCLUDE \rhinopubliclmhosts
# #END_ALTERNATE
#
# In the above example, the "appname" server contains a special
# character in its name, the "popular" and "localsrv" server names are
# preloaded, and the "rhino" server name is specified so it can be used
# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
# system is unavailable.
#
# Note that the whole file is parsed including comments on each lookup,
# so keeping the number of comments to a minimum will improve performance.
# Therefore it is not advisable to simply add lmhosts file entries onto the
# end of this file.

#Exchange 2007 SP1 / Windows 2003 / Standalone Mailbox Server

10.1.1.1    2003-MBX1

#Exchange 2007 SP1 / Windows 2003 / Cluster Continuous Replication (CCR)

10.1.1.3    2003-Node1
10.1.1.4    2003-Node2

#Exchange 2007 SP1 / Windows 2003 / Single Copy Cluster (SCC)

10.1.1.7    2003-MBX4

This completes the configuration steps for Windows 2003.

===============================

Updated Sunday, August 9th, 2009 with LMHOST instructions.

===============================

When using any form of multi-machine Exchange 2007 replication (CCR / SCR) Kerberos authentication is very important.  We leverage the rights of Exchange server machine accounts for several functions including the ability to replicate log files and utilize the remote registry service for commandlets.

Some Background…

In terms of the replication service we copy logs between CCR and SCR servers using SMB file shares.  These shares are created by the replication service.  Permissions to access these shares are derived by assigning the share permission READ to the Exchange Servers group.

Note:  We use a very restrictive read heuristic which does not fully equal the same read permission as set through the GUI so you’ll have to trust me here – the groups effective share permission is read.

In the Exchange Servers group we automatically place the machine account for each Exchange server installed. 

By adding the Exchange servers machine account to the Exchange Servers group, and adding the Exchange Servers group with appropriate permissions, we’ve effectively allowed the machine accounts read access to the shares.  The replication service, which runs under the local system security context, can then access the shares to pull log files.

The Issue…

It is becoming more common in environments to no longer see WINS installations.  It is still a requirement of the product though that short name resolution work.  Many administrators address this issue by using a DNS suffix list.  You can set the DNS suffix list on the advanced settings of TCP/IP.

When a short name resolution request is made, the domains are appended in order as specified on the list.  If the name can be found in the DNS zone of the name as appended, then this combination is returned as the fully qualified domain name.

For example, if I have a host Server1 that is registered only in the DNS namespace exchange.msft, when I issue a ping request to Server1 the first domain appended is external.exchange.msft.  Since the machine is not registered in that dns domain, the second address is appended, in this case exchange.msft.  With the machine registered in this domain, a successful name query response is received and the ping will continue successfully to server1.exchange.msft.

An ipconfig /all will display the appended DNS suffixes and their order.

In many circumstances the machine will only resolve in a single DNS domain.  If this is the case then it will not affect keberos authentication.  Where an issue occurs is where the machine resolves in more then one domain, and the domain it resolves it does not match the active directory domain (which in this case is what is registered on the service principle name records) of the machine account.  Lets look at an example of how this can be an issue.

In this example the machine Server1 is registered in the dns domain external.exchange.msft and exchange.msft.  My active directory DNS name space for the domain that the machine is a member of is exchange.msft.

My append dns suffixes in this order has the following list:

external.exchange.msft

exchange.msft

domain.com

When the replication service attempts to copy a log file it begins the authentication process to the share.  The first step in this process is obtaining a kerberos ticket so we can leverage the permissions of the machine account (local system) for share access.  The first name in the suffix list is appended, and a successful name resolution occurs.  In this case the fully qualified domain name is believed to be Server1.external.exchange.msft.  At this time the kerberos key distribution center is contacted, and a ticket is issued for Server1.external.exchange.msft.  The next step is to access the share presenting this kerberos ticket.  At this time an access denied is received to the share, and logs cannot be copied. 

The reason the access denied is returned is that the service principle names stamped on the machine account in active directory for the server does not include Server1.external.exchange.msft, it only includes Server1.exchange.msft (the AD domain name).  You can see the SPNs registered on the server by doing an LDP dump of the computer object in the active directory domain container.  Here is an example:

servicePrincipalName (4): MSServerClusterMgmtAPI/2008-NODE1; MSServerClusterMgmtAPI/2008-Node1.exchange.msft; HOST/2008-Node1; HOST/2008-Node1.exchange.msft;

The issue in this case is easily corrected.  To correct the issue, change the appended DNS suffix list to use the active directory domain first.  For example:

exchange.msft

external.exchange.msft

domain.com

With the updated DNS suffix list the server name determined is server1.exchange.msft.  This name matches the entries of the service principle name and authentication can occur successfully and therefore log replication can occur without issues.

Other functions besides log replication can be impacted by the appended DNS suffix list.  For example, certain commandlets such as get-storagegroupcopystatus and update-storagegroupcopy leverage the rights of the local system to access the remote registry service.  These commandlets can also suffer access denied conditions as authenticated remote registry connections between servers can fail. 

Here is a sample of the error text from a failed get-storagegroupcopystatus:

Microsoft Exchange Replication service RPC failed :
Microsoft.Exchange.Rpc.RpcException: Error e0434f4d from cli_GetCopyStatusEx
at Microsoft.Exchange.Rpc.Cluster.ReplayRpcClient.GetCopyStatusEx(Guid[]
sgGuids, RpcStorageGroupCopyStatus[]& sgStatuses)
at
Microsoft.Exchange.Cluster.Replay.ReplayRpcClientWrapper.InternalGetCopyStatus(Strin
g serverName, Guid[] sgGuids, RpcStorageGroupCopyStatus[]& sgStatuses, Int32
serverVersion)
at
Microsoft.Exchange.Cluster.Replay.RpcCopyStatusInfo.GetMergedStatusResults()
at
Microsoft.Exchange.Management.SystemConfigurationTasks.GetStorageGroupCopyStatus.Pre
pareStatusEntryFromRpc(Boolean fCcr, Server server, StorageGroup storageGroup,
StorageGroupCopyStatusEntry& entry)”

The moral of the story…

Replication and commandlet issues on Exchange servers can be avoided when using appended dns suffixes list but ensuring that the active directory DNS domain is the first to be appended.