Whenever someone shows me a Calendar folder where OWA and Outlook have different ideas of when recurring meetings are, I always ask if they've tried to poof the calendar. This always generates a chuckle, even though I was dead serious.
OWA doesn't know anything about expanding recurring meetings and appointments. Instead, it relies on a task which runs in Exchange that expands the recurring items for it. Under certain scenarios, Exchange may not realize that a recurring item has changed and needs expansion again. Sometimes this is because of a bug, sometimes it's because of corrupted data. Sometimes a little of both.
Anyway, the process for fixing this is called Poof. I think the name stems from the expression "Poof! Be gone!". When a Poof is performed on a calendar, Exchange deletes all of the cached expansions and performs them again.
Poof is enabled by first setting the following registry value on the Exchange server
Value (DWORD): CalendarRecovery
Next, in the description field of the properties of the Calendar folder, set the following text:
This signals Exchange to perform the Poof for this Calendar.
I haven't posted a MAPI sample in a while, so I whipped one together to demonstrate how one could Poof a set of Calendars:
As usual, all caveats and disclaimers for samples apply. One big caveat here - Poof is an expensive process. Running Poof against every mailbox in a server in a short period of time could place a heavy load on the server. So - if this is something you want to do, I'd recommend doing the Poof in batches, like so (assume legdns.txt contains a list of legacy DNs for mailboxes you wish to Poof):
for /F "delims=" %i in (legdns.txt) do @PowerPoof -p "Default Outlook Profile" -m "%i" -v
Note also that if you put this in a batch file, you'd need to use %%i instead of %i.
One of my colleagues pointed out why Poof sometimes won't work - if you're using a cached mode profile, when you write the text to the Calendar folder, nothing is changed on the server until the client syncs with the server. And even then it's unclear whether that would actually trigger the Poof. So - if you are performing Poof manually, make sure the Outlook profile you use isn't cached.
If you're using PowerPoof with the -m or -s switches, the connection made to the mailbox is uncached regardless of the profile type, so this won't be an issue. If you're using PowerPoof with -p and no other parameters, then it will make the setting on the calendar folder of whatever profile you specified, so if that profile is cached it's likely the Poof won't happen.
Also - another issue I've seen frequently with PowerPoof. If you run it with the legdns.txt file, make sure the DNs listed in legdns.txt do not have extra spaces at the beginning or ending of the line. If they do, those spaces will passed in with the -m switch and PowerPoof won't be able to find the mailbox.
Getting an error running powerpoof with the -P ans -S switch
It seems it can't locate the calendar for all the mailboxes. Any ideas?
INFO: 0x8004010F - ProcessMailbox failed to locate Calendar
I guess it is a permissions issue. What permissions does the user account need? Full permissions to all the mailboxes?
so I've got the script worked out a bit, but quick question
I'm trying to verify that the script is working by look into the properties of the calendar in question (in this case, mine)
But I do't see the string there. Does it happen so quickly that I won't...or does this mean the script is not working?
We have a user that has all of her calendar appointments off by several hours. I mean these appointments are well after the 3 week time period. They were thrown off after TXMove was ran. Do you have a fix for this?
I created a couple of PowerShell scripts that actively monitor for 8230 events on remote servers and execute PowerPoof against the suspect mailboxes.
The corrupt calendar item issue had been creating some havoc just after migrating all of our mailboxes to the 2007 servers. disk utilization and transaction log creation would spike and actually crippled our server once (I'm not sure because we have another issue that is causing denied connections). :(
Anyway, try the code if you like. The links are on my blog.
I created the regedit keys and value on the server manually. When I try to add the CleanupExpansionCachesInTheCalendarFolder in the Description field of the Calendar Properties for the user and hit Apply I get an "Unknown Error" box. Any ideas?
Interesting - you should look on the Exchange server and see if any events were written in the Application log when you did that.
There are many EXCDO Error Event ID 8209 & 8201
Calendaring agent failed with error code 0x8000ffff while cleaning up the calendar.
Does Poofing work in Exchange 2007? What is the filter to use with Process Monitor (v. 2.8)? Thanks!
Yes - poof applies in Exchange 2007. I don't know why you'd be using Process Monitor here.
@Carol: In the Process Monitor filter, use Path / contains / CalendarRecovery.
@Stephen Griffin: Sysinternals no longer provides Regmon since Process Monitor does everything Regmon did and more.
Also, I can see a SUCCESS entry in Process Monitor when I set the CleanupExpansionCachesInTheCalendarFolder description on the calendar, but the description text is never removed from the calendar when I check it later, and it does not fix the issue, either. I'm not sure what else to do. Only once did I get some other EXCDO error (27 minutes my last poof attempt), which was Event ID: 8218 "A transaction failed during initialization". Any advice?
Forgot I had mentioned Regmon. :)
You might want to open a case to have this investigated.
I do not see a sample script in the .zip file. Can someone tell me the file name or Can someone point me to the format? I have about 50-60 people we want to run this against to get this taken care of.
I didn't provide a script - just the tool and the source. If you want to write a script to automate the tool you're on your own. The for loop I suggest should be a good starting point.
Hey Stephen. Thanks for a great article! Following your instructions I think the Poof is executing as it should, but it's failing to correct the 8217 Errors. Minutes after I manually trigger the Poof on an affected calendar, I have fresh 8217 errors listed for the recurring appointment. The appointment is visible and appears to open normally in Outlook, but it's still completely missing from OWA. I haven't seen any discussion online of the next step to take when a Poof fails - or even discussion of the possibility that a Poof CAN fail to correct the problem.
I should note that the recurring appt in question was created by acceptance of a recurring meeting invitation that was sent to all employees. She seems to be the only employee having the error with this recurring meeting calendar item.
Thanks in advance.