Manually transferring public folders from Exchange 2003 to 2010

Problem

You are in the process of migrating from Exchange 2003 to Exchange 2010 and noticed that using the Exchange 2010 supplied AddReplicaToPFRecursive.ps1 script does not appear to replicate all the public folders over to the new public folder store.

Solution

Note that this can be caused by various reasons such as corrupted items in your public folders, replication problems, etc.  One of the ways to get your public folders over is to actually manually export them to a pst file and then re-import them into the new public folder store.

Start off by identifying an account that has permissions to all of the public folders in the Exchange 2003 organization and locate the account’s store.

Open up the store’s properties and change the Default public folder database to point to the Exchange 2003 server:

Force replication once you’ve made the public folder store change by executing:

repadmin /syncall /AdeP

Review and ensure that there are no errors from the forced replication and open Outlook with the account that has full permissions to all of the folders in the Public Folders store: 

Proceed with exporting the public folders to a PST file.  In this example, we’ll be exporting one of the subfolders in the public folder store:

 

 

 

 

 

Once the public folder has been exported, proceed with re-pointing the home server of the information store of the account you used to export the public folder back to Exchange 2010.  Force replication once again and proceed with re-importing the public folder PST into the same folder: 

 

 

 

Once the PST has been re-imported, proceed with dismounting the information store you imported into:

… and to be absolutely sure the changes have been applied, you can also restart the Microsoft Exchange Information Store service:

 

Once you’ve completed the steps above, you can issue the following command on the Exchange 2010 server to get an item count on the public folder store folder and compare it to the Exchange 2003 server’s public folder’s folder item count:

C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-publicfolderstatistics -ResultSize unlimited > c:\pfcount.txt

A recovery of a VMware SRM’s (Site Recovery Manager) 4.1 “Protected Site” or “Recovery Site” throws the error: “dr.fault.RemoteSiteNotFound”

Problem

You’ve suffered a failure on your VMware SRM’s “Protected Site” or “Recovery Site” server.  You have no backups so you proceed to rebuild the server by reinstalling and restoring the databases.  Upon completing the rebuild, you get the following error:

dr.fault.RemoteSiteNotFound

You try to manually re-establish the connection by re-running the “Configure” option under “Protection Setup”:

… but get the following error:

A specified parameter was not correct.  RemoteSite.name

Exporting the VMware SRM troubleshooting logs show the following:

[2011-09-13 13:34:34.852 07272 verbose 'InventoryMapper'] Made recommendations for 1 VMs in 0 seconds

[2011-09-13 13:34:34.887 07676 info 'Replication'] Creating protection profile with name 'Test'

[2011-09-13 13:34:34.950 07676 error 'SOAP'] Method dr.primary.Configuration.createProtectionProfileWithGroup threw undeclared fault of type dr.fault.RemoteSiteNotFound

[2011-09-13 13:34:42.120 05092 verbose 'com.vmware.vcDr.ServiceInstance.AddRemoteSite-Task'] Task destroyed

[2011-09-13 13:34:42.120 05092 verbose 'SimpleTaskManager'] Scanning for tasks to reap

[2011-09-13 13:34:42.120 05092 verbose 'SimpleTaskManager'] Task Array.Synchronize-50 marked as complete

[2011-09-13 13:34:42.120 05092 verbose 'SimpleTaskManager'] Task com.vmware.vcDr.San.RecomputeLunGroups-51 marked as complete

Solution

One of the reasons why you’re experiencing this problem is because during the install, you did not specify the original name for the “Site Name” of the VMware SRM server you are recovering.  The following is a screenshot of the field:

You can also see the “Site Name” in the following screenshot.  Notice how the name is: “Site Recovery for…”

In this example, the site name should have been “Recovery Site”.

To have the site name of the server corrected, log onto the server and open up Windows Explorer and navigate to:

C:\Program Files (x86)\VMware\VMware vCenter Site Recovery Manager\config

Within this directory, you will see an xml file named: vmware-dr.xml

Open up the XML file and look for the tag <SiteName> </SiteName>:

Change the value in between the 2 tags to the name that the site was named previously:

Save the XML file and proceed with running a repair on the VMware Site Recovery Manager server via the Programs and Features window:

Once the repair finished, you should now see the correct name in the Summary tab of the Site Recovery section:

Installing VMware Update Manager 5.0 on a Windows Server 2008 R2

As with my previous post, I had to document a recent vSphere 5 install and since I already have the screenshots, I figure I’ll take the time to write this post to show what an install of VMware Update Manager 5.0 on a Windows Server 2008 R2 looks like.

Open up the VMware vCenter Installer and select VMware vSphere Update Manager:

The installer will launch:

Proceed going through the wizard:

It’s interesting to note that VMware vSphere Update Manager 5.0 still uses a 32 bit DSN:

If you’re install Update Manager on a drive with less than 120GB, you’ll be prompted with the following warning:

… and we’re done.