Public folders not visible in OWA

During an Exchange 2003 to Exchange 2010 when you try to view public folders in OWA you might receive the message "The public folder you're trying to access couldn't be found. If the problem continues, contact your helpdesk and tell them the following: The public folder couldn't be found because there is no Exchange 2010 public folder server." You'll find several possible solutions online, but none of them worked for us. What finally fixed the problem was moving the public folder hierarchy from the Exchange 2003 administrative group to the Exchange 2010 administrative group, restarting the OWA server, and waiting for everything to sync up. Here are directions on how:

http://exchangeserverpro.com/moving-the-public-folder-hierarchy-during-an-exchange-2007-migration

Monitoring Exchange 2010 database maintenance

By default Exchange 2010 will performance maintenance activities throughout the day. If you're monitoring your storage performance, and if it's virtualized you should be, you can see a higher level of disk utilization than normal, especially during off hours. To make sure it's just database maintenance and not an issue:

- Start Performance Monitor by going to Start>Run>Perfmon

- Under "Monitoring Tools" select "Performance Monitor"

- Click the green plus sign to add a monitor.

- Select the local computer, scroll down to "MSExchange Database Instancess", select "Database Maintenance Duration", "I/O Database Reads / Sec", and "I/O Database Writes / Sec", and select all database instances in the pane below it. 

- Right click in the graph, select properties, select the "graph" tab, and change the view to report.


Now you can see how long the maintenance has been running, and the load it's placing on your storage system. Maintenance appears to generate about 30-35 IOPS and about 7-8 Mbps per database being processed.

245 error creating database copy in Exchange 2010 DAG

Here's an annoying one which Microsoft technical support had a hard time with. When you try to create a database copy in a DAG the initial seed fails with a 245 error on the source server. You can work around the problem by dismounting and remounting the database and then telling it to resume replication. The problem is the system essentially tries to start replication before the database is even created on the target server. While Microsoft wasn't able to answer why it's trying to do that, they did give me the correct shell cmdlet to create a database copy with postponsed seeding, which allows you to skip the error and the whole procedure to start initial seeding:

Add-MailboxDatabaseCopy -Identity "Database Name" -MailboxServer "Server Name" -ActivationPreference 2 -SeedingPostponed

That said, even doing it this way you'll might still get an error on the target mailbox server, but it's easier to ignore and don't stop the initial seeding.

The "SeedingPostponed" option is normally used for an existing database, and will create the database copy but leaves replication suspended so you can manually seed it. However, when used for a brand new database the initial log with the database creation command in it is copied over, and that command causes the database copy to be created and begin replication. So the end result is different when using it on a new database like in this scenario.

Errors with a dismounted database in Exchange 2010

If you keep a database dismounted in Exchange 2010 you can keep getting indexing errors in the application log. This is normal, but annoying. To remedy the situation drop to your shell and disable indexing on the dismounted database using the following cmdlet then restart the indexing service:

Set-MailboxDatabase "Database Name" -IndexEnabled $false

1114 Warnings in Exchange 2010

We've kept getting clusters of 1114 Warnings in the application log for certain databases in Exchange 2010. After working with Microsoft support on the problem, the final conclusion was some 1114 warnings are normal and to be expected.

UPDATE: After 1 year we still get periodic 1114 warnings on all of our databases but they've haven't affected performance in any way, just as Microsoft support said and it's safe to ignore them.

Physical size discrepancy between DAG databases

I noted something interesting. With an Exchange 2010 DAG you have one active database and one or more logical copies. All the databases are logically identical. However, they can vary in physical size by several hundred megabytes.