Before installing NetApp SnapManager for Exchange you will need to have the following software packages.

• Microsoft Powershell – You can download here
• Storevault Manager
• SnapDrive 5.0
• SnapManager for Exchange

All packages need to be installed on the Exchange Server that you would like to back up. You will also need to make sure that the service account has the correct permissions to access the Exchange Server.

1. Install Microsoft Powershell
2. Install StoreVault Manager
3. Install SnapDrive 5.0  You will need to download the Server hotfix KB931300 which can be found on a previous post called Quick Guide to Creating SQL Luns and Installing SnapManager for SQL
4. Install SnapManager for Exchange

The component ‘Microsoft Exchange Messaging and Collaboration Services cannot be assigned the action “Remove” because: -One or more users currently use a mailbox store on this server. These users must be moved to a mailbox store on a different server or be mail disabled before uninstalling this server.

1. Launch MMC
2. Add Snap In -> ADSI Edit
3. Right Click on ADSI Edit and select Connect to
4. Select Domain under Select a well known naming context and click OK
5. Right Click on Doman, select New -> Query
6. Under Name type Mail User Search, under Root of Search Click on Browse and Select Domain, Click on Edit Query, under field choose User -> Exchange Home Server.  Under Conditions select Ends With, this is important as I could only find the user under this condition. Under Value type the Exhange Server name.  Click Add, then OK
7. Click OK

You should see all the users that have their mailbox on the Exchange Server that you would like to remove.  Delete all users and then go back to the Exchange Server and remove Exchange through Add and Remove Programs in Control Panel.

1. In the properties of the virtual root Exadmin in IIS, go to the “Directory Security” tab
2. In the “Secure Communications” section select “Edit”.
3. Make sure to deselect “Require secure channel (SSL)” and “Require 128-bit encryption.”
4. If the “Require 128-bit encryption.” is selected and greyed out, make sure to select “Require secure channel (SSL)” and deselect “Require 128-bit encryption.” then deselect “Require secure channel (SSL)” again.
5. Goto Start – Programs – Windows 2000 Support Tools – Tools and launch ADSI Edit.
6. In the left side pane expand the Configuration container.
7. Next expand CN=Configuration
8. Then CN=Services
9. CN=Microsoft Exchange
10. CN=
11. CN=Administrative Groups
12. CN=First Administrative Group site name>
13. CN=Servers
14. CN=Protocols
15. CN=HTTP
16. CN=1
17. Right Click on CN=Exadmin and choose Properties.
18. In the Properties dialog box you will see 2 drop-down lists. drop down the top list and select “Both”. Drop down the second list and scroll down to the attribute “msExchSecureBindings” and double click on it.
19. If this attribute is set to 443 or any other value really, click the 443 value to select it and click the “Remove” button. Then click “Apply” and then “OK”
20. Close out of ADSI Edit, close and reopen Exchange System Manager and test Public Folder access again.

Background

Veritas Replication Exec 3.1 (now from Symantec) is a file replication tool. It can be used for configuring jobs for replicating the contents of folders between two or more machines. For more information on Veritas ReplicationExec, please visit Symantec Website.

Before you follow this procedure, please make sure that you have understood the Veritas Replication Exec 3.1 whitepaper that describes how to setup replication for Exchange using MSCS.

As per the whitepaper, one needs to set up two MSCS clusters, each with one node (not one cluster with two nodes). One single node cluster would be for the primary server and the other would be for the secondary server. Both clusters would be identical with respect to virtual name and virtual IP. Under normal conditions only the primary server cluster would be online. The secondary (DR) exchange server cluster would be left offline. Veritas Replication Exec would be configured for continuous replication of data between primary and secondary servers.

The main reason for using single node cluster is because the same (virtual) name can be used on the same network for both servers, as at any given point of time, only one cluster would be online. This is required because, in the event of a disaster, the secondary server has to be available to all users by the same name since the Exchange Server name is mentioned at many places within the AD. However, most server SCSI hardware will not permit you to have a single node MSCS installed since a shareable SCSI bus is required.

This article investigates on how you can achieve this without having to install single node MSCS, i.e. without having to use a common (virtual) name and IP for the primary and secondary servers.

Step 1. Install Exchange 2003

1. Install Exchange 2003 on both primary and secondary servers. In our example, the primary server is EXCH and the secondary (DR) server is EXCHDR. Our Windows domain name is MYDOMAIN.LOCAL
2. Make sure that the latest Exchange Service Pack is installed on both servers. The service pack level should be the same on both primary and secondary exchange servers.
3. On EXCHDR, stop all Exchange Services and change the startup mode to Manual.
4. It is a good practice to configure Exchange database and logs on separate volumes on the same server or at least in different folders. In our example, the Exchang database will be in D:\EXCHDATA and the Exchange logs will be in D:\EXCHLOGS on both servers.

Step 2. Install Veritas Replication Exec 3.1

1. Install Veritas Replication Exec 3.1. Installation is fairly straightforward. Make sure that the Replication Agents are installed on both Exchange servers. For more information on Veritas RE installation, see your Veritas RE documentation.

Step 3. Configure Veritas RE Replication jobs

1. On the computer where you have installed Veritas Replication Manager, open the Veritas Replication Exec Console.
2. Create a new replication job using New Job Wizard.
3. Create a One-to-One (standard) replication job.
4. Select the options as follows: Prescan, No changes on target, Exact replica on target, Continue Replicating After Synchronization.
5. Specify the source as the primary Exchange server (EXCH) and the destination as the secondary Exchange server (EXCHDR).
6. Specify the data to be replicated. It is recommended to replicate the entire EXCHSRVR directory for each disk containing Exchange data or log files. Replication Exec will select a default path on the Target unless you manually override the Target path. You must configure the replication job so the source and target paths are as per what is configured on each Exchange server as the local path for data and logs. Create a set of rules with a custom Target path. (in this example the NTFS Drive that Exchange was installed on happened to be the D: Drive, Hence map D:\exchdata as well as D:\exchlogs to the respective data and logs location on the secondary Exchange server.)
7. Test the replication and check if the Exchange files are being replicated. You can perform additional steps for checking database consistency as explained in the Veritas Whitepaper.

Step 4. Writing SCRIPT 1: Changing mailbox home to DR server

NOTE: This script needs to be run only in the event of a disaster. Write the script, test it and store it in a safe place.

1. Use a text editor like notepad and write a VBS script that achieves the following:
2. Save the file with .VBS extension. Here is my VBS script (you can start here and modify, especially the words in italics) :

Option Explicit
Dim objOU, objUser, objRootDSE
Dim strContainer, strDNSDomain, strhomeMDB, strhomeMTA, strmsExchHomeServerName
Dim intCounter, intPwdValue‘ Bind to Active Directory Domain
Set objRootDSE = GetObject(“LDAP://mydc1.mydomain.local/RootDSE”)
strDNSDomain = objRootDSE.Get(“DefaultNamingContext”) 

‘————————————————————
‘ Important change OU= to reflect your domain
‘————————————————————

strContainer = “OU=Accounts, ”
strContainer = strContainer & strDNSDomainintCounter = 0 strhomeMDB = “CN=Mailbox Store (EXCHDR),CN=First Storage Group,CN=InformationStore,CN=EXCHDR,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=MYORG,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=local”strhomeMTA = “CN=Microsoft MTA,CN=EXCHDR,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=MYORG,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=local”strmsExchHomeServerName = “/o=MYORG/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=EXCHDR”

1. Download and install the Office Resource Kit (ORK) (7.1 MB) from the Microsoft Website and install it on any one of your client machines. We will be using the ORK to generate the script for us. Once generated, we can use the script on any client.
2. Under Office Resource Kit tools, you will find the Custom Maintenance Wizard.
3. In the Custom Maintenance Wizard, keep clicking Next till you reach the Outlook: Customize Default Profile page,
4. Click New Profile, click Next. (Tip: You can also use Modify profile)
5. On the Outlook: Specify Exchange Settings page, specify Configure an Exchange Server Connection.
6. Specify your secondary Exchange server name (EXCHDR).
7. At the end of the wizard you have the option of saving a PRF file. A .PRF file is an Outlook Profile file.
8. When you double-click on the .PRF file from a client machine, it automatically reconfigures the Outlook profile to point to the secondary Exchange server. Put the execution of this .PRF file as a logon script in the event of a disaster.

TIP: You can use the same method to revert back by generating another .PRF, once you have recovered your primary exchange. While reverting back you also need to do a reverse-replication using Veritas RE. For more information, see your Veritas documentation.