Replicate Public folders Between Exchange 2003 and 2010 Organizations Using the Interorg Replication Tool

By:Rik Hoffelder

---

I wrote in my article, Cross-Forest Migration with Exchange 2010 is a Piece of Cake! that it is possible to synchronize public folder and free/busy data between Exchange 2003 and Exchange 2010 Forests using the free Interorg Replication Tool. Since that time I have received a few questions on how I set that up and got it working. So by popular demand, here are the steps I used along with screenshots to help get you going.


First, a little background on the environment
In my lab, as was the case as the production enviroment, I had Exchange 2003 running in a single domain Windows 2003 forest, set at Windows 2003 Functional Level. Exchange 2010 is running in a single domain forest with Windows 2008 domain controllers, functional levels also set to 2003. A Cross-Forest Trust was established, SIDHistory filter security relaxed with the intent of migrating all domain resources to the new forest, including Exchange 2010. The Active Directory Migration Tool (ADMT 3.2) was used to migrate user accounts, groups etc as noted in Cross-Forest Migration with Exchange 2010 is a Piece of Cake! and mailbox GUIDs updated to prepare for the mailbox migration.

Setting Up Interorg Replication
To preform the steps outlined below I was running version 6.5.7408 of the Interorg Replication Tool from the Exchange 2003 Toolkit, Exchange 2003 SP2, and Exchange 2010 with Rollup 1, though it should work with Rollups 2 or 3.

1. Create a user account and mailbox to be used for the process in the Exchange 2003 organization. This account must be granted Owner rights on every public folder that you plan to replicate. For my purposes I used the EX2003\Administrator account, though not the most reocmmended for security reasons.

2. Create a user account and mailbox to be used for the process in the Exchange 2010 forest. This account must be granted Owner rights on every public folder that you plan to replicate. For my purposes I used the EX2010\Administrator account, though not the most reocmmended for security reasons. (NOTE: The public folder hierarchy must already exist in the Exchange 2010 forest, so you will need to pre-create the folders you will replicate from 2003.)

3. Create a top-level public folder named ExchsyncSecurityFolder in the Exchange 2003 organization. Assign the account created in step 1 Folder Visible rights only. Remove all other access rights for all other accounts.



4. Create a top-level public folder named ExchsyncSecurityFolder in the Exchange 2010 organization. Assign the account created in step 2 Folder Visible rights only. Remove all other access rights for all other accounts.



5. Install the Interorg Replication Tool replication service on the Exchange 2003 public folder server by running EXSSRV.EXE from the toolkit. Click the Create button which will install the service on the server. In my case I used the EX2003\Administrator account as the service account. I had problems when using local system. Administrator is also a local admin and Exchange Full Administrator



6. Open the Interorg Replication Configuration tool by running EXGCFG.EXE. Click File -> New to create a new Exchange Sync Configuration file (.esc). Click Session from the menu bar then click Add - Public Folder Replication.

7. In the Public Folder Session Configuration window enter PF 03 -> 10 in the title field to indicate 2003 public folders replicating to 2010. In the Publisher Organization section enter the Exchange 2003 public folder server and the mailbox name you created in step 1. In the Subscriber Organization section enter the name of the Exchange 2010 public folder server and the mailbox name you created in step 2.



8. Click the Advanced button under Publisher Organization then enter the credentials for the account you created in step 1. Click the Advanced button under Subscriber Organization then enter the credentials for the account you created in step 2.



9. Click the Folder List button. Click the Logon button under Publisher Public Folders and the Logon Button below Subscriber Public Folders. This will allow you to view the available folders in both organizations. Select a top-level folder under Publisher Public Folders and click the Add button. Repeat this for each top-level folder you plan to replicate.




10. Click Session from the menu bar then click Add - Schedule+ Free/Busy Replication. Repeat steps 7 through 9 to replicate free busy from 2003 to 2010.

11. Repeat steps 7 - 9 instead using Exchange 2010 as the Publisher and Exchange 2003 as the Subscriber to allow reverse replication. Do this for both public folders and free/busy. When the process is complete you will have at least 4 sessions in your configuration as shown below:



12. After completing this you can now monitor the process (I have mine running every five minutes in the lab, hourly in production) using the EXGSRV.EXE console.



For additional information on Interorg Replication Tool configuration and implementation I recommend checking out the full TechNet article here.

More information on Exchange

Read more!

Cross-Forest Migration with Exchange 2010 is a piece of cake!

By:Rik Hoffelder

---

Overview
It has been a while since I've posted anything new on The Generation V as I have been neck deep in projects. One of them involved a cross-forest Exchange migration as part of a larger AD migration. In this project the customer was migrating Exchange 2003 in Forest A to Exchange 2010 in Forest B and they needed to do it on a budget. In other words, no third party tools if at all possible. As the title suggests, with free tools from Microsoft and built-in features of Exchange 2010, it was remarkably easy.

Over the years Microsoft has added many tools, most free, to assist in numerous management and migration tasks. For this project I used the Active Directory Migration Tool 3.1, Exchange Sync from the Exchange 2003 toolkit, CVSDE, VBScripts, and PowerShell to perform all of the tasks. This saved the customer the many thousands of dollars third party software would have cost and not necessarily made the process any easier.

I will not go into the specifics of the AD migration part of the project, just know that all user and group accounts were migrated using ADMT 3.1. I also did not use ILM 2007 FP1 SP1 to provide GAL sync as this wasn't necessary due to the relatively small size of the project (about 600 mailboxes) and the rarity of account/mailbox additions/changes/deletions in this environment during the co-existence period. Even in that case, creating new accounts or modifying DLs followed a document process I created that eliminated the need for GAL sync. I would suggest ILM for larger organizations and those that make many changes during co-existence.

Prepare Routing

Prior to the Exchange migration, I had to establish a routing method to be used during the co-existence period between Exchange forests. This is necessary because both Exchange forests must be authorative for the primary SMTP namespace of customer.com. To do this I established a proxy address of ex2003.local for Exchange 2003 and ex2010.local for Exchange 2010.

I then added ex2010.local to the Accepted Domain Hub Transport organization configuration and added %m@ex2010.local as a proxy address to each affected E-mail Address Policy. Next I added the %m@ex2003.local proxy address to each Exchange 2003 Recipient Policy and selected the "This organization is responsible for delivery …" checkbox. All recipients were updated with the new policies.

Next I created SMTP connectors in each Exchange forest to forward to the other's proxy address space. For example the Exchange 2003 SMTP connector routes @ex2010.local to the Exchange 2010 forest and vice versa.

Prepare User Accounts

The Active Directory Migration Tool was used to migrate the Forest A user and group accounts into Forest B. (ADMT is also a free tool available from Microsoft's public download site http://microsoft.com/downloads). After the accounts were migrated I exported the displayName, samAccountName, mailNickname, and mail values for all mailbox-enabled users in Forest A using CSVDE as follows:

csvde -l displayName, samAccountName, mailNickname, mail -r "objectclass=user" -f c:\2003_Mailboxes.csv

This was done to use these values to mail-enable each user account in Forest B. By mail-enabling (not mailbox-enable) the Exchange 2003 users now appear in the Exchange 2010 address book allowing migrated users to communicate with unmigrated users seamlessly, thus eliminating part of the need for ILM in this project.

Before mail-enabling the Forest B users I changed the domain portion of each e-mail address to ex2003.local to use as an input value for the bulk mail-enable process. I also renamed the field in the CSV file to match the input values I used in the Exchange Management Shell cmdlet. DisplayName was changed to Name, samAccountName was changed to Identity, mailNickname was changed to Alias, and mail was changed to EmailAddress. I then ran the following cmdlet to complete the update:

Import-CSV C:\2003_Mailboxes.csv ForEach-Object –process {Enable-MailUser –Identity $_.Identity –Alias $_.Alias -EmailAddress $_.EmailAddress}

This would of course need to be manually updated for any new user accounts migrated over from Forest A.

The final step to prepare the users is run the Prepare-MoveRequest.PS1 script against the mail-enabled users. Prepare-MoveRequest.PS1 is a script created by Microsoft that updates the Forest B mail-enabled user with the MsExchMailboxGUID attribute from Forest A. This value will be used by the New-MoveRequest cmdlet to match the source Exchange 2003 mailbox to a target 2010 user. This little free script along with the –RemoteLegacy switch in the New-MoveRequest cmdlet are the new features in Exchange 2010 that help eliminate the need for third party tools in all but the most complex of cross-forest migrations.

I ran the following cmdlets in 2010 EMS, reusing the 2003.Mailboxes.CSV from the previous step:

$UserCredentials = Get-Credential

Import-CSV C:\2003_Mailboxes.csv ForEach-Object –process {Prepare-MoveRequest.ps1 -Identity $_.Identity -RemoteForestDomainController ex03.ex2003.local -RemoteForestCredential $UserCredentials –UseLocalObject}

For those new to PowerShell in general, EMS in particular, the $UserCredentials = Get-Credential cmdlet will open a dialog box requesting to enter the credentials of an account in Forest A with rights to migrate the data from Exchange 2003. Enter the credentials accordingly or the migration will fail with an error message containing 0x80004005, which means access denied in the entire Microsoft world.

Prepare Distribution Groups

Next I had to mail-enable the distribution groups migrated from Forest A. The ADMT will migrate the groups and group members as a group type of Distribution but it will not bring over Exchange attributes. This required two steps, first each migrated group had to be changed to a Universal group, as they were domain local or global groups in Forest A. Distribution Groups in Exchange 2007/2010 are Universal in scope as a result domain local or global groups cannot be mail-enabled. To do this I ran the following cmdlet in Exchange 2010 Management Shell:

Import-CSV C:\groups.csv ForEach-Object –process {Set-Group –Identity &_.Name –Universal}

I then ran the following script to mail-enable the Universal groups.

Import-CSV C:\groups.csv ForEach-Object –process {Enable-DistributionGroup =Identity &_.Name}

Now keep in mind that any new users created in Forest A and added to the Forest A version of this group, will become a member of the Forest B version of the group after the user account is migrated with the "Fix Group Memberships" option selected, thus negating the need for ILM.

Prepare Public Folders & Free/Busy

This migration occurred over a period of several weeks. Users were fully migrated to Forest B, meaning they were accessing Exchange 2003 from Forest B user credentials on workstations operating in the Forest B domain. After all users, groups, and workstations were migrated, I began the mailbox migration process.

This company relies on Public Folder data in several areas to collaborate and share information. As a result I had to maintain both public folder and free/busy synchronization between Exchange forests for a period of time. To do this I used the good old Exchange Inter-Organization Replication Tool. At preset this tool is not designed for use with Exchange 2010, but version 6.5.7408 is supported with Exchange 2007. I thought what the heck there isn't that much difference in public folder functionality between 2007 and 2010 so I gave it a try … in my lab first of course. What do you know, the darn thing worked and it worked very well.

To get it up and running I followed the steps outlined in this article: http://technet.microsoft.com/en-us/library/ee307369(EXCHG.80).aspx. It took a couple hours to get it fully functional in the customer environment, but it did the job very well and cost nothing but billable time! Hey I gotta eat too, right?

Migrating the Mailboxes

This is another area where Exchange 2010 really shines. The New-MoveRequest cmdlet offers a command-line only switch –RemoteLegacy. This switch tells Move Request to migrate a mailbox from a different Exchange 2003 or 2007 forest. It uses the MsExchMailboxGUID to match the source 2003/2007 mailbox in the remote forest with the target mail-enabled user in the Exchange 2010 forest, which was established earlier using Prepare-MoveRequest.PS1.

$UserCredentials = Get-Credential

New-MoveRequest –Identity migtest1 -RemoteLegacy -TargetDatabase "Mailbox Database 1" -RemoteGlobalCatalog 'ex03.ex2003.local' -TargetDeliveryDomain 'ex2010.local' -RemoteCredential $UserCredentials

When the move request completes it converts the target mail-enabled user to a mailbox-enabled user. It then deletes the source mailbox and converts the user to mail-enabled. As part of that process it adds a proxy address of @ex2010.local as the primary SMTP allowing users on the legacy forest to see the migrated mailbox in the global address list.

Finally using a group policy object I created a VB Script based user logon that creates a new Outlook profile by using a PRF file. The script checks for the presence of a specific profile name, if it doesn't find it Outlook is launched with the PRF as follows:

Path\Outlook.EXE Path\Update.PRF

It's quick it's easy and the code I used was readily available through a simple Bing search.

Final Words

I don't exactly recommend this process for large scale migrations, but for those of you operating on a budget and can't afford 10+ USD per mailbox for a one time use tool; this is will get you by. It isn't perfect, but it worked well for this project.

More information on Exchange

Read more!

Is Brick-level Necessary for Exchange?

By:Rik Hoffelder

---

The need for brick-level backup of Exchange mailboxes is often a topic of discussion with customers. This is of particular concern to those with large message stores, short backup windows, and demanding users. In my opinion Exchange provides enough out of the box functionality that brick-level backups are really unnecessary in all but the most crucial of mailboxes. You know the mailbox that belongs to the person who signs your paycheck! In all seriousness I feel brick-level backup is mostly a waste of tape and/or disk.

Let's first take into consideration the deleted items retention configuration on mailbox stores; a feature that has been with Exchange through many generations. This feature marks a deleted message as hidden to the database thus places it in a "dumpster." By deleted message I mean a message that has been purged from the mailbox, not left in the Deleted Items folder. The length of time the message remains in the dumpster is determined by the deleted items retention configuration on the message store. A value greater than zero will keep the message hidden for that many days, after which time the database page(s) are marked for reuse in effect purging the message from the database. However during the time the message is in the dumpster it is recoverable.
Many of you may already be familiar with the Recover Deleted Items function under Outlook's Tools menu. By default this menu option is grayed out unless you have selected the Deleted Items folder. Microsoft has a little known knowledge base article that documents a registry setting allowing the Deleted Items Recovery option to be available to all folders, not just Deleted Items. This setting not only allows recovery from all folders within the mailbox but all public folders as well. The public folder store also has a deleted items retention configuration. (Additional information on this registry setting can be found in How can I recover items that I have "hard deleted" in Outlook? )

Deleted Item Recovery using this method not only has the benefit of being able to recover any message from any folder; you can also recover messages that have been hard deleted when someone uses SHIFT+DELETE. As a result you can recover messages that have been delivered after the last backup, eliminating the data loss a SHIFT+DELETE would present using brick-level restore. Additionally all recovery is done online, you never need to mount a tape so it literally takes seconds to locate and restore messages. But wait there's more; you can configure this for all end users so they can recover their own messages never having to wait hours, even days for recovery. Do you think that can reduce admin overhead and help desk calls for those little uh-ohs?

Yes there are a few gotchas, what did you expect for out-of-the-box? For instance, each mailbox or public folder store is limited to 4 GBs of dumpster space within the database. For large message stores this will reduce the amount of time you can keep deleted items before reaching the limit. If you exceed the 4 GB limit messages are purged on a First In - First Out (FIFO) basis. It has been my experience that a 100GB mailbox store under normal utilization can support up to 14 days worth deleted items comfortably. This obviously varies by environment; fortunately Microsoft took some the guess work out. Exchange 5.5 Server or later include performance counters under the Information Store object that show current dumpster utilization.

So how do I handle a case where the message is past the recovery period? This is where the Recovery Storage Group comes into use. First introduced in Exchange Server 2003 the RSG allows you to perform an online restore of mailbox databases to a separate storage group and mailbox store instance, then merge the data with the on-line mailbox. Again this is not a perfect solution as the active mailbox must reside on the same server that the backup was taken from. In other words if I moved the mailbox to a different store since the backup I wish to restore was taken, I need to move the mailbox back in order to merge the data. This is very well detailed in Microsoft's knowledge base article How to use Recovery Storage Groups in Exchange Server 2003. The other issue is that the original user account must exist in Active Directory, if this has been deleted you cannot use a RSG. However you can follow the steps I outline in my blog posting How to Build an Exchange 2003 Disaster Recovery Server.

More information on Exchange

Read more!

How to Build an Exchange 2003 Disaster Recovery Server

By: Rik Hoffelder

---

I have recently run into spate of mailbox recoveries for several of my customers where an "offline" recovery of an Exchange 2003 database was necessary. Since no one has published this information to the world, at least for free, I felt I should. Yes, many organizations have upgraded to Exchange 2007 or are planning their 2010 deployments, there are still many out there that will be running Exchange 2003 for a few more years. This article is for you!


Exchange 2003 introduced the Recovery Store Group to allow on-line restores of mailbox databases to aid in the recovery of deleted messages or deleted mailboxes, but there are still three situations where an offline recovery of Exchange databases is still a necessity in Exchange 2003, public folder data recovery (lost/deleted messages), recovery of a mailbox when the user account has been deleted, or the mailbox is no longer on the same server where the backup to be restored was taken.
The second situation is the one I encounter most often and the subject of this posting. An Exchange 2003 Recovery Storage Group will not allow you to export the data from a mailbox database if the original Active Directory user account has been deleted. This is because of the RSG's dependency on the msExchMailboxGUID. Note that the third situation is related to the msExchOrigMDB. Microsoft does an excellent job of describing these scenarios in How to use Recovery Storage Groups in Exchange Server 2003. Also important to note that these restrictions do not apply to Exchange 2007 and from what I understand Exchange 2010 as well.
So if I am going to invest my time in building a recovery server can I use for something besides recovering single mailboxes? Sure, glad you asked! Recovery servers are great for learning and practicing disaster recovery steps in general. After all the best time to learn disaster recovery procedures is not in the middle of a disaster, right? Not only can you practice Exchange database restore and dial tone recovery, you can also practice Active Directory recovery as the recovery server will be built into its own forest and domain.
The other benefit is testing your backups. Believe it or not just because the data wrote to the tape successfully doesn't mean it will restore successfully. I speak from experience here. I once did a recovery that required us to go back 22 backups before we found one that would restore and mount due to poor tape quality. So it's never a bad idea to pull a tape and restore it to your offline server from time to time and make sure it works.
I find that virtual machines with enough storage to handle the database(s) to be recovered work very well for this situation. The nice part of is you can make a backup copy of the image and use it for testing hotfixes, upgrades, and a whole host of other lab functions and do it on a tight budget.
So here's what you need to do. Note these are high level steps; the exact steps will vary depending on your situation and need. This also assumes a single server for Active Directory and Exchange.

1. Build a new domain controller in a new forest and domain. I like to use a DNS name of exrecovery.local or the like.
   
   
   1. Assign an IP address that is routable to your backup server.
      
   2. Configuring forwarding or zone transfers between your production and recovery DNS servers. This is to ensure your backup server can locate it.
      
   3. Install the backup software agent; ensure the backup server can connect with proper credentials.
      
   
   
2. Install Exchange 2003
   
   
   1. Prepare the Forest and Domain for Exchange 2003 using setup.exe /forestprep and setup.exe /domainprep
      
   2. Install Exchange in a new organization using the same name as your production organization.
      
   3. Make sure your recovery Administrative Group has the same name as the production admin group. Note that you can create several Admin Groups within a single recovery server then as long as the organization is set to native mode you can move the server to the appropriate group for recovery purposes.
      
   4. Create a new Storage Group using the same name as the production storage group. Create a new Mailbox Store using the same name as the production mailbox store.
      
   5. Be certain to check the "This database can be overwritten by a restore" box on the mailbox store properties.
      
   6. Apply the same level of service packs and updates as your production organization to both the operating system and Exchange 2003.
      
   
   
3. Restore the database(s)
   
   
   1. From your backup application, mount and catalog the appropriate tape and select your database(s) to be restored.
      
   2. In your backup application's console go to the Exchange Restore section (I'm assuming Backup Exec, but all backup software will have something very similar) and select to redirect the restore. In the redirect enter the name to your recovery server. If you will not be restoring any additional logs from incremental backups select the mount database upon completion option, otherwise select this option after the last incremental back has been restored. VERY IMPORTANT NOTE: It is critical that you make sure to redirect the restore. If you miss this step the restore will attempt to overwrite your production database. In which case you be learning a database recovery that you didn't plan on!
      
   3. After the restore completes your database(s) should be mounted and just about ready for use.
      
   
   
4. Recovering the mailbox
   
   
   1. After the mailbox store has been mounted navigate to the Mailboxes container in Exchange System Manager. Right-click and select Run Cleanup Agent. This will cause the restored mailboxes to appear with a red X next to it.
      
   2. Create a user account in your recovery domain. Be sure to use the same display name, first name, and last name as the mailbox you are recovering.
      
   3. In the Mailboxes container in Exchange System Manager, right-click the mailbox to be recovered then select Connect to connect the mailbox to the user account you just created. Note that if you use a different display name, first name, or last name the reconnected mailbox will display that name in ESM.
      
   4. Export the mailbox to a PST using EXMERGE. Remember Microsoft doesn't support Outlook on the same server as Exchange 2003 in a production environment, but since this isn't production feel free to try it. Just remember it isn't supported!
      
   
   

I hope someone finds this information useful. If you like to see other information like this feel free to post a comment. I'm always happy to hear from you!

More information on Exchange

Read more!