Shared calendar items are shown incorrectly in Exchange 2007 (Fixed in SP3 RU1)

Sumatra enterprise clients use shared calendars to allow Managers to look at employee calendars, employees to access common calendars (e.g., the 'vacation' calendar, or to look at conference rooms (when free/busy doesn't contain enough information.)

Unfortunately, the calendar events are often shown at the wrong time.

Microsoft KB 976100 offered a hotfix for this issue. It was also included in the Exchange 2007 SP3 Rollup 1 (KB 2279665)

For clients who share calendars -- apply this rollup.

Exchange 2010 Calendar Permissions Using PowerShell

One of the Microsoft blogs did a great article on setting calendar permissions using PowerShell in Exchange 2010.
Their earlier article on setting Outlook Delegate permissions with RBACs is also worth reading for sites migrating into 2010.
Many thanks!

Dilbert on the importance of Conference Rooms

Dilbert from Sunday September 12, 2010 had an excellent strip on the importance of conference room scheduling.

We normally see this as the attempted "great conference room land rush" during migrations, which you can avoid by hiding your resources in the GAL for the migration period.

Circumvent Outlook Rules in Exchange 2010

We just completed an Exchange 2007 migration this past weekend. After each migration we review what worked and what didn't. One of the problems we faced - clients setup delegate forwarding rules, so the "bosses" and their delegates had copies of the meeting invites in their inboxes. The client used Redemption to write a MAPI script to disable those rules, but it didn't work as planned. The good news-- the Sumatra process correctly built the bosses calendars! The bad news - delegate had a bunch of meeting requests in their inbox that they had to delete (Not a show stopper -- just tedious!)

Had they migrated to Exchange 2010, this would not have been necessary because Exchange 2010 allows you to manage rules using these six commandlets: Get-InboxRule, Set-InboxRule, Remove-InboxRule, Disable-InboxRule, Enable-InboxRule and New-InboxRule.

One approach is to use "Get-InboxRule" to find all enabled, server-side rules. Disable those rules (remember which rules you disabled so you can re-enable them after the migration.)

We came up with another approach: Add a new rule that has the "highest" priority, have that rule do nothing, then say "stop processing rules." After the migration, remove that rule.

Here's how we approached it for one user, say, Zyg:

• New-inboxrule -mailbox:zyg@mailbox.sumatra.com -name:"_sumatraHiPriorityRule" -Priority "0" -StopprocessingRules:$true -Confirm:$false

and then to remove:
• Remove-inboxrule -mailbox zyg@cod.sumatra.local -Identity:"_sumatraHiPriorityRule" -Confirm:$False

Caveats:

• Note the priority zero (0) makes this rule the highest-priority rule. All others drop down one.
• We are ignoring the power-rule-user scenario: the user exceeds Exchange's inbox rule memory size buffer limit (it's 32KB) (or about 40-50 rules.) Obviously when you're at the limit you can't add any more rules. We don't have a suggestion except to say "look" for disabled rules and ask the end user if a few could be removed.
• The "-force" parameter - removes disabled rules AND all Outlook client-side rules.
• new-InboxRules doesn't accept pipelined userlist from "get-mailbox -filter {isResource -eq $false}". What happens if you have 5,000 accounts? Stay tuned ---

Sumatra Utilities - Holidays for the remainder of 2010

Since the year is drawing to a close, we're going to put up the Sumatra Utilities for 2010 for no charge for the rest of 2010.

So Exchange Admins in the USA can server-side insert Columbus Day, Thanksgiving, Christmas, and New Years, and Canadian users can do Thanksgiving and Remembrance Day, and UK users can do bank holidays from now until the end of the year and... OK OK you get the idea.

This version will only insert data up to January 2011. This version works with both Exchange 2007 and Exchange 2010, and will not work for hosted Exchange (i.e., Live @ Edu). Hosted sites working with us on migrations already have versions that will insert holidays.

To download the ZIP file just click here. If you want to read through the documentation first, please do.

Look for an update from us in October about what we'll do with server-side Exchange holidays in 2011.

If you are looking to private label or distribute and support the Utilities holiday insertion tool we'd be happy to discuss that.

Exchange 2010 SP1 - ErrorRecord: Database is mandatory on UserMailbox error

We planned to upgrade our Exchange 2010 servers to SP1 this labor day weekend to take advantage of these calendar-related improvements:

• Outlook Web App Improvements
• Calendar Repair Assistant supports more scenarios than were available in Exchange 2010 RTM.
• Mailbox Assistants are now all throttle-based (changed from time-based in Exchange 2010 RTM).
• Internet calendar publishing allows users in your Exchange organization to share their Outlook calendars with a broad Internet audience.
• Importing and exporting .pst files now uses the Mailbox Replication service and doesn't require Outlook.

(fyi be prepared to install hotfixes before installing SP1!)

But what happens when it fails on the mailbox role with these two errors?

1. ErrorRecord: Database is mandatory on UserMailbox. Property Name: Database



2. Microsoft.Exchange.Data.DataValidationException: Database is mandatory on UserMailbox. Property Name: Database

It seems we had to upgrade active directory (i.e, run setup.com /ps, then /p, and then /pad)

But that threw an error "Setup previously failed while performing the action "BuildToBuildUpgrade"

There are two fixes to this problem. The FIRST Fix - edit the registry (seems like that's always part of a fix), and SECOND remove a few system mailboxes:

Edit the registry. Under the key HKLM\Software\Microsoft\ExchangeServer\v14\MailboxRole you will find two keys - Watermark and Action. Export the mailbox role settings, then delete the two keys. Now re-run setup.com /ps, then /p, and then /pad. )I tried running the setup GUI, but it didn't completely upgrade AD.)

The SECOND fix: Now we're back to the initial "Database is mandatory on UserMailbox" problem. Launch AD Users & Computers, and delete the discovery mailbox, system mailbox(es)

Finally, if you are deploying Exchange 2010 for the first time, Exchange 2010 SP1 is a full install package. Pat Richard's Exchange2010Prereqs.ps1 script simplifies installation.

>>Update After I brought the servers back online and started writing this post, I found Brian Day's post in Technet (...wish I had found it earlier!)

--Russ