Administration of a server or of an enterprise of servers will often require the installation of updates to keep a system patched with the latest fixes. But at some point an upgrade or a migration will be needed. Email administrators, or any administrator of a system for that matter, will sooner or later encounter a situation where the most recent migration has not gone well.

Sometimes it is necessary to rollback to a previous working version to keep the users and the managers happy. It could also be the case that the most recent upgrade or migration effort inadvertently skipped a step or a patch or a fix was not yet installed to bring the system up to a supportable level.

Migration of Exchange server can have its own problems as well. Some administrators have reported a problem with Public Folders after having moved from Exchange Server 2000 to Exchange Server 2007.

If you have moved everything from one server to another then you might also be thinking about turning off all the old MSExch services on the older server. If you do this then you might end up with a situation where you are asked to logon to the older server every time you logon to your new server. What is happening is that the new Exchange Server is trying to get public folders from the old Exchange server. The result is that access to public folders is going to be hampered because the old Exchange server’s public folders are still trying to be accessed. An administrator can verify this scenario by right-clicking on the Outlook icon in the system tray. If you click cancel on the logon box then the public folders connection will be redirected to an EXch server in another domain. At this point some administrators have reported that their access has slow down.

It is possible to save the same public folder content on multiple Microsoft Exchange servers by using public folder replicas. The concept of using replicas is used in many applications such as database applications and also in disaster recovery strategies. The replicas must be updated at regular intervals so as to maintain the integrity of the data, in this case email messages, specifically public folder replicas must be refreshed at frequent intervals.

Exchange Server updates the public folder replicas by sending and receiving replication messages to each of the servers that contain public folder replicas. The sending and receiving of public folder replication messages creates a trail of communications which can be used for diagnostic purposes when there are problems with the replicas. These messages can be used to diagnose:

1. Which systems have sent any public folder replication messages.
2. Which systems have received any public folder replication messages.
3. Which systems have responded to any received public folder replication messages.

By analyzing the data an administrator can determine if a particular system is having problems with receiving or sending public folder replicas. Once it is determined which system is having problems then an administrator can further diagnose and isolate the problem through more tests.

One such test is to run the shell command “get-publicfolder -recurse | fl name,replicas” . The expectation is that the tree returned will display a populated public folder. If the tree is empty then more diagnostics will need to be run.

Error logs should also be checked for indications of a problem with the public folders.

When configuring public folder replication an administrator should use the System Manager tool to specify the target destination system as the replication server of another system for the source folders that need to be replicated. The replicated folders should indicate that they are “in sync” or “local modified”.

An administrator can confirm the status of the current public folder replicas by opening a command prompt and typing in the following commands:

1. cd D:supportExdeploy (hit enter)
2. pfmigrate.wsf /S:OLDSERVERNAME /T:NEWSERVERNAME /R /F:c:LOGNAME.log

The above commands will create a report of the current public folder replicas. A report file – LOGNAME.log – will be created. An administrator should review the file to confirm that the OLDSERVERNAME is the name of the old server such as Exchange 2003 and that the NEWSERVERNAME is the name of the new server such as Exchange 2007.

To confirm that a successful replication was created and that each designated public folder exists on the new server an administrator can view the LOGNAME.log file for verification.