AutoReseed reduces the need for Exchange Administrator or any other operator, to be on site at the moment of the drive crash and replace it as soon as he can in order to preserve the healthy copies structure.

The AutoReseed process acts as the following:

1. The Microsoft Exchange Replication service periodically scans for copies that have a status of "FailedAndSuspended" for 15 minutes in a raw.

2. The Microsoft Exchange Replication service try to resume copy 3 times.

3. The Microsoft Exchange Replication service try assigning a spare volume for 5 times (every 1 hour).

4. The Microsoft Exchange Replication service try InPlaceSeed with SafeDeleteExistingFiles 5 times (every 1 hour).

5. Once all retires failed, the process stops.

6. After 3 days when the copy is still in "FailAndSuspend", the process resets and starts over from step 1.

The prerequisites for AutoReseed to take place:

1. The copy is not ReseedBlocked or ResumeBlocked.

2. Logs and EDB are on the same volume.

3. The Logs and Database folder structure matches required naming convention

4. There are no active copies running on the failed volume.

5. All copies on the volume are in FailedAndSuspend status.

6. No more than 8 FailedAndSuspend copies on the server.

 So how does it work? Very simple. In the next example I will explain the idea behind the configuration, while this example describes a one database configuration in one server at the DAG out of 2 or more servers in the DAG configuration. A basic component when working with AutoReseed mechanism, is Mount Points. The idea is based on a pre-configured "cartridge" of volumes (like online spare), on each server for the databases that are replicated to the server. In case that the ESE engine has an issue writing to a specific volume according to the check list above, a new volume becomes active instead of the "problematic" one. In order to configure the "cartridge" of volumes we will create a directory called "ExchVols" which will host the different volumes. The Databases will be listed under the "ExchDBs" folder, each database will have 2 folders - one for logs and one for the database:

Components legend:

1. ExchDBs: Folder that "hosts" the databases root folders. Each of the databases root folder is located on a mount point.

2. ExchVols: Folder that "hosts the volumes "cartridge". Under this folder, we will be able to list the volumes that are in production to host the databases folders and the "online spare" volumes.

3. DB001: A folder that hosts the database and logs folders for DB001. For every database, there is a folder with the same format - DBXXX and underneath a folder for database - DBXXX.db and folder for logs - DBXXX.log

In case of DB001, The folders underneath (DB001.edb & DB001.log)  are the same folders that exists below Volume1. That means that DB001 and Volume1 are pointing to the same location - 2 folders with the same mount point.

 The Auto Reseed configuration includes 3 new main parameters for every Exchange 2013 DAG:

• AutoDagVolumesRootFolderPath (ExchVols in our example): Includes the mount point containing all volumes for databases and the "Online Spare".  The default location is: C:\ExchangeVolumes
• AutoDagDatabasesRootFolderPath (ExchDBs in our example):Is the mount point that containing all the databases. The default location is: C:\ExchangeDatabases
• AutoDagDatabaseCopiesPerVolume: Is the number of databases copies per volume. The default is 1 database per volume.

Now after we go over the Auto Reseed components and the concepts around this high availability feature, let's see how to configure AutoReseed step by step.

The environment containes 2 mailbox servers E15MBX1 and E15MBX2, CAS server named E15CAS1 and one domain controller. The DAG name is DAG13.

How to configure DAG for AutoReseed:

1. Configure the DAG with the AutoDagVolumesRootFolderPath to point to ExchVols and AutoDagDatabasesRootFolderPath for ExchDBs.  In order to do it, run the commands:

Set-DatabaseAvailabilityGroup DAG13 -AutoDagDatabasesRootFolderPath C:\ExchDbs

Set-DatabaseAvailabilityGroup DAG13 -AutoDagVolumesRootFolderPath C:\ExchVols

2. We don't need to configure the AutoDagDatabaseCopiesPerVolume value since we use the default of 1 database per volume. In case that you have more than 1 database per volume, for example 4, you should run the next command:

Set-DatabaseAvailabilityGroup DAG13 -AutoDagDatabaseCopiesPerVolume 4

3. In order to verify that your DAG is configured correctly, run the next command:

Get-DatabaseAvailabilityGroup DAG13 | fl *auto*

4. Now create 5 folders, one for ExchDBs, One for ExchVols, one for the database (DB001), and 2 for the volumes (Volume1 & Volume2) that will be used for the database files and for "Online Spare" in case of drive crash. You can create the folders using Windows Explorer or by running the 3 commands from CMD (in example we will create all 5 folders by running only 3 commands):

md C:\ExchDBs\db001

md C:\ExchVols\Volume1

md C:\ExchVols\Volume2

 5. Verify that the root folders ExchDBs & ExchVols folders were created:

6. Verify that the volume folders Volume1 & Volume2 were created:

7.  In addition verify that the database folder db001 was created as well:

8. Now open Windows Disk Management (diskmgmt.msc) in order to create the Volume1 mount point which will be used for hosting a database. For this purpose I pre-configrued 2 disks - one for each volume. Right click Disk 1 and choose New Simple Volume:

9. Choose the size of your volume and click Next. In my example I choose the whole size of the disk - 20GB:

10. Now instead of giving the drive a letter, choose the Mount in the following empty NTFS folder into Volume1 as a mount point at the next path: C:\ExchVols\Volume1 and click OK:

 11. Now click Next:

12. Since an Exchange database and transaction logs are going to be hosted on that drive / volume, it is better to format the drive with 64KB and not as the default. In order to do that, at the Format this volume with the following settings tab, open the Allocation unit size and choose 64KB:

13. In order to make things easier when troubleshooting drive issues (not must), name the volume at the Volume Label location with VOL1 and click Next.

14. Verify that all the parameters were configured correctly and click Finish:

15. At the end of the Volume1 configuration, it should look as following:

16. The next step is pointing the volume as a second mapping to a different location - db001 folder. In order to do that, right click the volume you have just created and select Change Drive Letter and Paths...:

17. At the properties screen, select Add and choose the Mount in the following empty NTFS folder option. Click Browse and navigate to C:\ExchDBs\db001. Choose db001 folder and click OK:

18. At the next screen click OK again:

19. Verify that the both paths are listed: C:\ExchVols\Volume1 and C:\ExchDBs\db001 like the next example and click OK:

- Note: This action will point both C:\ExchVols\Volume1 and C:\ExchDBs\db001 to VOL1 drive.

20. Now repeat steps 8 - 15 for the second volume (Volume2) in order to add it as an "Online Spare" in case that Volume1 will crash. In order to it, right click on the second drive and mount it to C:\ExchVols\Volume2.

Notice that you DO NOT NEED to repeat steps 16 - 19 since Volume2 is an " Online Spare" drive and not yet used for a production database:

21. In order to verify that Volume2 has been configured correctly, right click Disk2 and select Change Drive Letter and Paths... you sholud see the next path C:\ExchVols\Volume2

22. After you have configured both volumes and mounted them to the correct locations, you should see the folders icons were changed to mount points icons as following :

Now we will create all the needed steps in order to create and adjust the databases paths and copies. Please note that if you have already have databases created on your Exchange 2013 DAG environment with active mailboxes, you will have to move mailboxes to the new databases or to use the Move-DatabasePath PowerShell command in order to move the database and transaction logs to the mount point location.

23. Create 2 directories under Volume1 folder, which is actually the same location as db001 mount point. The 2 directories, 1 for database and 1 for transaction logs, should be with the same syntax:

C:\< VolumeFolderName>\VolumeX\<dbname>.db (In our example it would be - C:\ExchVols\Volume1\db001.db)

C:\< VolumeFolderName>\VolumeX\<dbname>.log (In our example it would be - C:\ExchVols\Volume1\db001.log)

You can create the folders using Windows Explorer or use CMD for that. In my example, I used the 2 commands in order to create db001.db & db001.log directories:

md C:\ExchVols\Volume1\db001.db

md C:\ExchVols\Volume1\db001.log

 24. The directories structure should look as following:

25. Now we will create a new database named db001 on a mailbox server named E15MBX1 and we will point the database and logs to the folders we created at the previous step according to the syntax of the directories structure:

26. The next step is to mount the new database. You can use powershell command or use the EAC (Exchange Administration Center). Under the Servers menu, choose Databases, right click the new database db001 and click Mount:

27. Now we will add a copy for the newly created database. From the EAC, under the Servers menu, choose Databases, right click the new database db001 and click Add Database Copy:

28. Choose the mailbox server that you would like to add as an additional copy. In our example it would be E15MBX2, click on Browse and choose the mailbox server:

29. After selecting the additional copy, click on Save:

30. Verify that the copy was added and that the copy is in a Healthy state. As you can see, the database db01 is now mounted on E15MBX1 and has a valid and healthy copy at E15MBX2:

31. So currently we are having a database named db001 which is mounted at E15MBX1 and has also a copy at E15MBX2. Each server has 1 volume (Volume1), which hosts the database and transaction logs and 1 volume as an "Online Spare" (Volume2). In that case no matter if Volume1 will fail on E15MBX1 or E15MBX2 - Volume2 on each server will be replaced automatically by the system and take place of the failed drive.

32. At this step we will simulate a "disk failure" in Volume1 on server E15MBX1 - this volume hosts the mounted database. In order to simulate a failure in Volume1, we will remove the drive from the Hyper-V settings of E15MBX1. Acting that way will eliminate Volume1 without any delay from the server:

33. You are able to see that the Hard Drive Vol1_MBX1.vhd was disconnected from E15MBX1:

34. As a result, the drive will not be available to the system, therefore we will get the next error message at E15MBX1:

35. After the "disk failure" we can see that the mounted database was automatically activated on E15MBX2 (the healthy copy) because of the disk failure and that the copy on E15MBX1 (which was at mounted state), was changed to "FailedAndSuspend":

36. Since the replication service scan all the databases every 15 minutes look for a "FailedAndSuspend" state, the server which experiences a disk failure, will automatically replace the failed volume (disk) and automatically reseed the database from the active database. In our example we can see that after a while, the "FailedAndSuspend" copy on E15MBX1 was changed automatically after reseeding to a "Healthy" copy:

37. At the next screen shot, we can see that after Volume1 failed on E15MBX1, Volume2 was automatically activated and db001 was automatically reseed:

38. In order to follow the AutoReseed process, we should look at the next location: Event Viewer\Applications and Services Logs\Microsoft\exchange\HighAvailability\seeding

39. At the event viewer at the above mentioned location, event id 1109 will appear and inform that the replication service discovered that there is a disk failure and that there is no possibility to write to the database and logs location of db001: C:\ExchDBs\db001.

40. Event id 825 indicate that the seeding process was started:

41. Event id 826 indicate that the seeding process was completed:

42. Event id 1109 describes the last checks for the database:

43. Event id 1110 claims that the last checks for the database were completed successfully:

44. The final step in the database seeding is the Content Indexing (CI) seeding. Event 827 indicates that the CI seeding was started:

45. Event 828 indicates that the CI seeding was finished successfully:

 After the database was reseeded automatically, the administrator should replace the failed disk in order to keep the cartridge volumes available for the next disk failure event.

Summery:

AutoReseed mechanism in Exchange 2013 keeps the messaging service up and running with high nonstop availability. The Exchange administrators can sleep well now and replace the failed drives in the morning instead of waking up in the middle of the night.

 I would like to thank Heiko Pohl (Microsoft - Principle PFE) & Danijel Klaric (Microsoft - Senior PFE) for the assistance. .

This document describes what needs to be done in order to apply the Kerberos authentication in addition to NTLM for Outlook users against Exchange 2010 CAS servers. This document is based on TechNet article: Configuring Kerberos Authentication for Load-Balanced Client Access Servers.

The problems around too many NTLM authentications and limitations, including theory around the solution for using Kerberos, are described at the next TechNet article: https://technet.microsoft.com/en-us/library/ff808313.aspx

Exchange environment architecture:

1. DC01: Windows 2003 Domain controller.
2. EX141: Exchange 2010 SP2 installed as HUB, CAS, MBX.
3. EX142: Exchange 2010 SP2 installed as MBX (DAG member).
4. EX143: Exchange 2010 SP2 installed as MBX (DAG member).
5. The domain name is msft.net

Before you begin:

According to the official TechNet article regarding to the Kerberos authentication configuration, you should create only one ASA credential in case you are having a single DAG stretched across 2 Active Directory sites:

"Because this architecture includes a Database Availability Group (DAG) that’s stretched across both Active Directory sites, you must deploy a single ASA credential for use by members of the Client Access server arrays in ADSite1 and ADSite2. If you don’t use a single ASA credential, clients will have Kerberos authentication issues when you perform a datacenter switchover because the secondary datacenter Client Access server array members won’t be able to decrypt the Kerberos session ticket. For more information about activating the secondary datacenter, see Datacenter Switchovers."

The next steps describe the Kerberos authentication configuration:

1. Creating the alternate service account (ASA) for the CAS ARRAY in the domain. This is being done, by opening the Active Directory User and Computers and creating new computer account:

2. Type your name for the ASA and click Next. In our example, the ASA named CAS-ARRAY-ASA. In Windows 2008 domain environment, the new computer account wizard will look slightly different.

3. Click Finish:

4. It is recommend to type a description for the ASA, in order to avoid deletion on this account by mistake in the future.

5. After creating the ASA (computer account), verify the account has replicated to all domain controllers within all Active Directory sites that contain the client Access servers that will use the ASA credential.

6. In order to continue, we need to verify the CAS array’s FQDN, since this name will be used for the SPN that will be attached to the ASA. In order to check the CAS Array’s FQDN, run the next command:

Get-ClientAccessArray

7. We also need to the check the InternalUrl & ExternalUrl names, which also needs to be configured for the SPN:

Get-ClientAccessServer ex141 | Get-OwaVirtualDirectory | fl ExternalUrl,InternalUrl

- In case that you want to check the InternalUrl & ExternalUrl names configuration for ALL of your CAS servers, run the next command:

Get-ClientAccessServer | Get-OwaVirtualDirectory | fl Server,Name,ExternalUrl,InternalUrl

8. Setting the SPNs for the NetBIOS & FQDN names. It’s recommended to add also the NetBIOS names (short names), since Outlook 2003 clients and maybe other MAPI applications works this way with short names.

• http Use this SPN for Exchange Web Services, Offline Address Book downloads, and the Autodiscover service. This data was provided at steps 6 & 7.
• exchangeMDB Use this SPN for RPC Client Access.
• exchangeRFR Use this SPN for the Address Book service.
• exchangeAB Use this SPN for the Address Book service.

9. Now create the SPN names using the setspn built-in command. The command can run using PS1 or a BAT file, but it is recommended to run the commands one by one in order to verify that all commands processed successfully.

setspn -s exchangeMDB/outlook CAS-ARRAY-ASA$

setspn -s exchangeRFR/outlook CAS-ARRAY-ASA$

setspn -s exchangeAB/outlook CAS-ARRAY-ASA$

setspn -s exchangeMDB/outlook.msft.net CAS-ARRAY-ASA$

setspn -s exchangeRFR/outlook.msft.net CAS-ARRAY-ASA$

setspn -s exchangeAB/outlook.msft.net CAS-ARRAY-ASA$

setspn -s exchangeMDB/mail.msft.net CAS-ARRAY-ASA$

setspn -s exchangeRFR/mail.msft.net CAS-ARRAY-ASA$

setspn -s exchangeAB/mail.msft.net CAS-ARRAY-ASA$

setspn -s http/outlook.msft.net CAS-ARRAY-ASA$

setspn -s http/mail.msft.net CAS-ARRAY-ASA$

setspn -s http/autodiscover.msft.net CAS-ARRAY-ASA$

10. To verify that all relevant SPNs have been assigned properly, run the following command from the Exchange's Powershell:

Setspn –L msft\CAS-ARRAY-ASA

11. In order to “attach” the ASA credentials to the CAS Array servers, we should run the next script from the following location: C:\Program Files\Microsoft\Exchange Server\V14\Scripts

.\RollAlternateserviceAccountPassword.ps1 –ToArrayMembers outlook.msft.net -GenerateNewPasswordFor “msft\CAS-ARRAY-ASA$" –Verbose

12. In case that the script was finished succfully, you will get the following message: 

“THE SCRIPT HAS SUCCEEDED":

13. To verify that the ASA credentials have been deployed properly use the following command:

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

14. Download and run the ConvertOABDir.ps1 in order to create new application pool to support different authentication methods like Kerberos and Certificate authentication for the OAB virtual directory. This script should run on each of the CAS servers in the Outlook.msft.net CAS array.

15. Restart the MSExchangeOAB & MSExchangeRPC on all the CAS servers in the configured array:

Get-Service MSExchangeAB,MSExchangeRPC | Restart-Service

16. Verify that the services are up and running:

Get-Service MSExchangeAB,MSExchangeRPC | fl name,status

17. In order to verify that all the previous steps completed successfully and that clients can communicate using Kerberos, use one of the there ways:

      17.1 Configure the Outlook to connect using TCP/IP, while the “Encryption” is marked and that the "Logon network security” is configured to use the "Kerberos Password Authentication"

Now open Outlook and verify that you are able to connect your mailbox: 

      17.2 At one of the workstations that are installed with outlook, open the command prompt and type: Klist tickets (on Windows XP or Windows server 2003). On Windows 7 or Windows 2008 type: Klist

           Klist tickets (Before Kerberos configuration):

           Klist tickets (After Kerberos configuration):

      17.3 From the Client Access Server, check the Address Book protocol logs. These logs are usually located at the following path: C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service:

         Now open one of the recent logs that were created after the Kerberos configuration you have made in the previous steps. In case you have configured all the steps in the right way, you should see the word

         Kerberos inside the AddressBook Service log. That means that the server successfully created a Kerberos authentication connection, as we can see in the next screenshot:

* Important: In case that your organization doesn’t work with encryption at the Exchange CAS & Outlook client side as the following example, you will not be able to use Kerberos to connect to the directory!

- The next example shows the directory disconnection status:

In order to check if your CAS server is configured with the “EncryptionRequired” parameter, run the command:

Get-ExchangeServer ex141 | Get-RpcClientAccess | fl EncryptionRequired

In order to change this value, run the next command on all the CAS servers and restart the MSExchangeRPC service:

Set-RpcClientAccess –server servername –EncryptionRequired $true

More information regarding to encryption configuration, you can find here:

https://technet.microsoft.com/en-us/library/dd439391(v=EXCHG.80).aspx

https://support.microsoft.com/kb/2006508

Rollback:

In order to roll back from the configuration above, run the next steps:

18. Delete all the SPNs we have created at step 9:

setspn -d exchangeMDB/outlook CAS-ARRAY-ASA$

setspn -d exchangeRFR/outlook CAS-ARRAY-ASA$

setspn -d exchangeAB/outlook CAS-ARRAY-ASA$

setspn -d exchangeMDB/outlook.msft.net CAS-ARRAY-ASA$

setspn -d exchangeRFR/outlook.msft.net CAS-ARRAY-ASA$

setspn -d exchangeAB/outlook.msft.net CAS-ARRAY-ASA$

setspn -d exchangeMDB/mail.msft.net CAS-ARRAY-ASA$

setspn -d exchangeRFR/mail.msft.net CAS-ARRAY-ASA$

setspn -d exchangeAB/mail.msft.net CAS-ARRAY-ASA$

setspn -d http/outlook.msft.net CAS-ARRAY-ASA$

setspn -d http/mail.msft.net CAS-ARRAY-ASA$

setspn -d http/autodiscover.msft.net CAS-ARRAY-ASA$

19. Delete the computer account you have created in step 1.

20. Verify that there are no outlook clients that are configured to use “Kerberos Password Authentication". Instead, they should use the “Negotiate Authentication” as the following example:

"Turning Kerberos Authentication Off

--------------------------------------------------------------------------------

 To revert your Client Access server array so that it doesn't use Kerberos, remove the SPNs from the shared service account. If the SPNs are removed, Kerberos authentication won't be attempted by your clients, and clients configured to use Negotiate authentication will use NTLM. Clients configured to use only Kerberos will be unable to connect. Once the SPNs are removed you should also delete the shared service account. You can use the maintenance script to clean out credentials from all Client Access server array members by using the toEntireForest parameter and using the -copy from server parameter to specify a server that does not have any Kerberos credentials. In addition, you should eventually restart all client computers to clear the Kerberos ticket cache."

More info:

https://technet.microsoft.com/en-us/library/ff808312.aspx

The core steps for the IP addresses changes are based on KB230356 which explains how to change the Windows cluster’s IP addresses.

In addition to the steps taken to change the IP addresses of the cluster’s members, we should take into consideration the Exchange system the runs on the cluster’s infrastructure. Therefore, additional steps regarding to the Exchange 2010 system were added to this document.

The environment:

The existing Exchange environment contains 3 Exchange 2010 Mailbox servers in the DAG, one of the servers is also CAS & HUB.

Before making the IP changes:

- Before changing the IP addresses of the servers involved in the Exchange environment, write down as in the next table, the current and the new IP addresses:

- In this case, the current and the new IP addresses are in same subnet (255.255.248.0). This means that no subnet changes needs to take place.

- Update all the other messaging related consumers that this change might prevent them from getting the messaging service during the IP changes period.

- The IP addresses change is reversible. In case that something gets wrong because of network or other issues, you can revert back to the previous IP addresses configuration.

- It is recommended to suspend the databases replication and dismount the databases before making the IP changes.

Steps taken to change the IP addresses:

* In case you are moving the DAG / Nodes to different subnets, add the new IP that will represent the DAG as a mandatory step by running the next command (although you can do it via the EMC) before starting the next steps:

Set-DatabaseAvailabilityGroup –identity DAG -DatabaseAvailabilityGroupIPAddress 100.100.100.234,100.100.97.234

1. Verify that the cluster’s resources (IP & Name) are owned by one of the other cluster’s nodes and not on the node you are going to run the IP changes. In this case, the first IP change is going to take place on EX141. In order to check which node is owned the cluster’s resources, we should run the next command:

Cluster group “cluster group” /state

In case EX141 is owned the cluster’s resources, use the next command to move the resources to other node in the cluster (EX142):

Cluster group “cluster group” /moveto:EX142

2. Stop all Exchange’s services on the Exchange server which it’s IP is going to be changed first.

In order to stop all the Exchange services quickly, stop the “Microsoft Exchange Active Directory Topology” service (MSExchangeADTopology). Stopping this service will stop all other Exchange services in case you choose “YES” in the next screenshot:

3. Verify that all the Exchange’s services are in “Stopped” state and that no monitoring or other system started them up again.

4. Check the hosts file on all Exchange servers in the environment and verify that it doesn’t contains the DAG / DAG members IP address. The hosts file is located at the next path:

C:\Windows\System32\drivers\etc

In case that the hosts file contains IP addresses relevant to the DAG or DAG members, change those IP addresses to the new IP addresses.

5. Change the IP address of the network adapter on node EX141 to the new IP address. This requires the computer to be rebooted.

6. After the server is up and running again, verify that the node EX141 was registered in the DNS with A & PTR records.

7. Verify that the node EX141 can ping the domain controllers and that other servers can ping the servers. In addition, check the communication between the server and the HUB & CAS servers.

8. Before changing EX142 IP address, fail the cluster’s resources (IP & Name) over to the functional node EX141. In order to failover to EX141 node, run the next command:

Cluster group “cluster group” /moveto:EX141

 9. Change the IP addresses for the network adapters in node EX142 and reboot the server.

10. Verify that node EX142 can ping the domain controllers and that other servers can ping EX142. In addition, check the communication between the server and the HUB & CAS servers.

11. Before changing EX143 IP address, fail ail the cluster’s resources (IP & Name) over to one of the cluster’s nodes you have already changed the IP address (EX141 node, in this example). run the next command:

Cluster group “cluster group” /moveto:EX141

12. Change the IP addresses for the network adapters in node EX143 and reboot the server.

13. Verify that node EX143 can ping the domain controllers and that other servers can ping EX143. In addition, check the communication between the server and the HUB & CAS servers.

14. Verify that the cluster service is up and that all nodes are online:

15. Now change the DAG IP address to the new IP address (same as cluster). In order to change it, run the next command:

Set-DatabaseAvailabilityGroup –identity DAG -DatabaseAvailabilityGroupIPAddress 100.100.97.234

This command will remove the old IP address of the DAG and leave it with the new the new IP address only.

16. In case that you have changed the subnet mask as well, run the “DiscoverNetworks” option, in order to force rediscovery of all DAG networks:

Set-DatabaseAvailabilityGroup –identity DAG -DiscoverNetworks

17. Verify that the in “Failover Cluster Manager” that the cluster resources are up with the new IP address:

18. Verify that all the Exchange services on all nodes are up

19. In order to verify that the DAG’s IP address was changed, run the next command:

Get- DatabaseAvailabilityGroup dag –Status | fl DatabaseAvailabilityGroupIp*

20. At the Failover cluster manager, double-click the IP Address resource to open its properties.

21. On the Parameters tab in the IP Address resource properties, make sure that the Network to Use box contains the new network as the network to use:

22. Verify that the “Application” and “System” doesn’t contain any errors related the cluster or exchange.

23. Verify that the Cluster’s IP address is registered with the new IP address at the DNS.

24.Now check that the cluster is working by moving the resources to one of the other cluster’s members:

Cluster group “cluster group” /move

25. After all the infrastructure (Windows servers, cluster) was configured and working, verify that all the databases are at Mounted state.

26. Now move / activate one of the mounted databases to one of the other DAG members and verify that the activation is working as expected.

This blog was created and published by the Microsoft Israel Services Messaging PFEs.  

In this blog we will publish Microsoft Exchange related articles on current and new technologies.

Good Luck!