December 22nd, 2011
paulw
We have set up DAG monitoring scripts for one of our customers which tell us the status of all the mailbox copies and we noticed that one of the database copies had been stuck in a status of “Crawling” for over a day.
To rectify this problem we did the following:
1. Log onto the affected server and open up services.
2. Restart the “Microsoft Exchange Search Indexer” service:

3. Run the following PowerShell command in EMC:
Update-MailboxDatabaseCopy –Identity DATABASE\SERVER –CatalogOnly
This will update the search index of the database and then you can run the following command to ensure that the database index is now healthy:
Get-MailboxDatabaseCopyStatus -Identity DATABASE\SERVER

Cheers
Paul
If you want to run any of the Exchange PowerShell commands from a standard PowerShell environment then you simply need to add in the following line in order to run it as if it is an Exchange Management Console:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
For example, the script below will output the size of the Exchange Databases to a file and can be run as a scheduled task:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
Get-MailboxDatabase –Status | fl name, databasesize | out-file C:\dbsize.txt
What we can do then is save the above script to a .ps1 file and then edit the action to start PowerShell.exe and put the arguments as the script that you want to run:

This can be set up with the usual Scheduled Task settings and with the PowerShell snap-in for Exchange added in should be able to use the Exchange PowerShell commands.
Cheers
Paul
Here is a PowerShell command that can be used to fetch the mailbox sizes that are over a certain amount of total item size:
get-mailbox | Get-MailboxStatistics | where {$_.TotalItemSize -ge 600MB}
The script above can be simply amended to the amount of MB or GB in size that you want to find out. So, for example, if you change the value after –ge (greater or equal to) to 6GB then it will search for all mailboxes that are equal to or greater than 6GB in size.
It could be particularly useful for anyone looking to implement database limits to find out if there are any users that would be affected.
Cheers
Paul
Here’s a quick command that will set the amount of days your lagged database is lagged for
Set-MailboxDatabaseCopy –Identity “DatabaseName\ServerName” –ReplayLagTime “7.0:0:0”
The Above command will set a lag retention of 7 days, but change the days to what you need (Please note the Maximum is 14 Days) 
You receive the error below when attempting to login to Outlook Web Access (OWA). In an environment with multiple Client Access (CAS) servers where CAS proxying is being used:

Solution:
On the target CAS server, Ensure that Windows Integrated Authorisation is the only the authorisation method enabled on the OWA and ECP virtual directories.
September 27th, 2011
paulw
Just a quick post to let you know how you can get the lag times that are set on the databases if you have any configured in your DAG:
Get-MailboxDatabase –Identity dbname -Status | Format-List replaylagtimes
This should output something similar to this:

Hope this helps
Paul
We had an issue recently when we migrated some exchange 2003 mailboxes onto an Exchange 2010 (Please note Exchange 2010 was SP1) Environment.
Basically after the migration all migrated users using Outlook in online mode could only see a blank Global Address List.

After looking into the issue we found that the resolution was to clear the value from the following attribute “msExchQueryBaseDN” via ADSIEDIT for the effected user.
After clearing the value the GAL suddenly appeared correctly 
I believe Microsoft are looking into sorting this issue in Exchange 2010 SP2.
We came across an issues recently where one of our Exchange servers in a DAG started having the below errors appear in it’s Event Log.
Event ID 5301
Detected catalog corruption for database Database1
Event ID 123
At ’9/20/2011 3:17:57 PM’ the Microsoft Exchange Information Store Database ‘Database1’ copy on this server experienced a corrupted search catalog. Consult the event log on the server for other “ExchangeStoreDb” and “MSExchange Search Indexer” events for more specific information about the failure. Reseeding the catalog is recommended via the ‘Update-MailboxDatabaseCopy’ task.
Basically the events were pointing to a corrupted catalog, so we simply fixed this by reseeding the catalog from another server that has a valid copy of the catlog via the following command
“Update-MailboxDatabaseCopy –Identity Database1\Servername –CatalogOnly”
After running the above the errors disappeared 
Just to let you know Exchange 2010 Sp1 Rollup 5 has been released. We have been running it now for 2 weeks in our environment and have noticed no issues with it 
Here is the link to the update http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27193
While installing Service Pack 1 on an Exchange UM server the following error was received:
Solution:
Run Setup.com /PrepareAD from the SP1 source files to create the RMS Shared Identity User