The items that do need watching are just a subset of the “old days.”

• Maintain your daily backups – probably the most important thing you can do for Exchange
• Examine your message queues for log jams or stuck messages
• Check available disk space (but you’ve already automated this, right?)
• Examine the event logs for errors and warnings
• Make sure your anti-malware software is functioning properly, i.e. turned on and getting updates (some people host this service, so that would only leave four items :)

Thanks to Jim McBee for providing guidance in his many excellent books.

“Delivery has failed to these recipients or distribution lists:
 
Jane Doe
Your message wasn’t delivered because of security policies…”

In our case, Jane Doe was no longer an employee and her account was disabled. The sender of the message was requesting a meeting with someone who had Jane as his admin, so he had her as a Delegate for his Calendar. Once we removed her from his Outlook’s Delegate list, there were no more errors.

Pretty simple, but they’ve moved Delegate Access in Outlook 2010, now you go to File > Account Settings > Delegate Access

For Outlook 2007 and earlier, go to Tools > Options > Delegates tab.

To confirm that this was the case, I opened the trusty EMS and ran this command on an affected individual.

test-exchangesearch username | fl

This result confirmed the catalog corruption:
ResultFound : False
SearchTime : -1

The fix is rather easy, but depending on your database size, can be rather lengthy. The script below stops the Microsoft Exchange Search Indexer, deletes the Catalog of the database in question and restarts the Indexer which fires off a complete rebuild.

You can find the script here (from where it must be run): <drive>:\Program Files\Microsoft\Exchange Server\Scripts

Syntax: ResetSearchIndex.ps1 -force <database>

Example: ResetSearchIndex.ps1 -force “Mailbox One“

The rebuilding of our catalogs took almost an hour for a 80GB database. And that was on a fairly powerful system with 32GB of RAM.

Should you wish to give the script below a try, copy it into a text file and change the extension to .ps1

Note: This script should be run from a system with Outlook and the Exchange Management Tools installed (they both need to be 32 or 64-bit) for this to work).

rem Gathering names for labeling the exported PST
$fname = Read-Host “First name?”
$lname = Read-Host “Last name?”

rem Assigning the current date to the $date variable
$date = get-date -uformat “%Y_%m_%d”

rem Capturing name of mailbox account (assigning to $uname variable)
$uname = Read-Host “Username?”

rem Capturing admin acct that is currently logged in to add mailbox permissions (assigning to $admin variable)
whoami > $admin

rem Adding permissions for admin allowing export
Add-MailboxPermission -AccessRights FullAccess -Identity $uname -User $admin

rem Exporting mailbox to D:\PSTs (change path to your liking)
Export-Mailbox -Identity $uname -PSTFolderPath D:\PSTs\$fname”_”$lname”_”$date.pst

If at some point I get time or get paid to do so, I’ll make a script to allow the use of a list for mass export.

This error comes about when multiple users have the same resource open, in this case a conference room, and make edits causing the Free/Busy information to become corrupt.

In order to fix the issue, just change one of the scheduling settings within Outlook > Options > Calendar > Resource Scheduling…, such as “Automatically decline recurring meeting requests,” click OK, then change it back. It’ll cause the Free/Busy data to rebuild and scheduling may once again take place.

Little did I know someone changed the top-level permissions of the folder I previously created, removing any admins from the list, so any new folder in the tree inherited the lack of admin rights. Now I had to change permissions on 472 folders, not something to be done individually.

A short search yielded just the info I needed. There is a script called AddUsersToPFRecursive.ps1 in the \Microsoft\Exchange Server\Mailbox\Scripts directory; use and syntax is below.

AddUsersToPFRecursive.ps1 -toppublicfolder \Finance -User “Joe Admin” -Permissions Owner -Confirm:$False

Change the -toppublicfolder to \ or \Marketing\Calendars, whatever suits your needs. And be sure to add the -Confirm:$False switch, otherwise you will have to hit Enter (or Yes) for every folder change. Don’t ask me how I know…

The Exchange cluster was using iSCSI, thus was offline during the outage and now would not mount the databases; both the System Attendant and Information Store services would not start. After trying a reboot and examining the Failover Clustering, these error messages were found in the Event Log:

System attendant – EventID: 1005 Unexpected error The clocks on the client and server machines are skewed. ID no: 80090324 Microsoft Exchange System Attendant occurred.

MSExchangeIS – EventID: 5003 Unable to initialize the Microsoft Exchange Information Store service because the clocks on the client and on the server machine are skewed. This may be caused by a time change either in the client or the server machine, and may require a reboot of that machine. Other than that, verify that your domain is properly configured and is currently online.

I didn’t even consider the fact that the Exchange server’s system time didn’t match the domain controllers’. Both nodes were a full six minutes behind! Once the clocks were synced with the DCs, both services started, databases mounted and we were back in business.

Due to the fact we’re running a hybrid UNIX/Windows DNS network, oddities like this seem to creep up. Once I have this sorted, there will likely be a blog post about that as well.

Just replace the text in bold red and run it in an Exchange Command Shell:

Set-MailboxAutoReplyConfiguration jsmith@contoso.com –AutoReplyState Scheduled –StartTime “11/2/2011” –EndTime “11/9/2011” –ExternalMessage “External OOF message” –InternalMessage “Internal OOF message”

This function is apparently one of the many that fall under the Microsoft Exchange System Attendant Service, once this service was restarted I was able to create my account and head out for a much deserved lunch.

After much searching, we found that during a reinstall some bits were left in C:\Users\Default\AppData\Local\Microsoft\Exchange Server

Once the files therein were removed, I was able to login successfully. We surmised that since the files were in the Default profile, something was stopping a new profile from being generated.