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.
If you're creating the CalendarRecovery registry value manually:
- it is a DWORD data type
- if the \EXCDO and/or \Parameters keys don't exist you should manually create them.
Do we make this registry change on the backend servers or the frontend servers or both?
will your app make this registry change for us?
all our owa users' dst appointments are off by an hour after installing all the appropriate patches in the right order.
I also ran powerpoof on my profile and it doesn't seem to be updating my calendar when I view it in OWA.
The registry key needs to be written on the mailbox servers. The sample application does not write the registry key - it only writes the string to the Calendar folder.
Perhaps you hadn't set the registry key properly on the server? Try doing the POOF manually - the sample is really better for doing a batch of mailboxes than for doing a single one.
Stephen, Thanks for all you do! I need to know the last step in the manual process. After I create the registry keys on the exchange server on which my mailbox resides, then add the description to my calendar properties, then do I just open Outlook? Do I run something? When will it finish poofing my calendar?
Thanks so much! Courtney
Setting the description in the Calendar is the last step. Exchange spots this change and kicks off the task of reexpansion right then. Depending on the load on the server, the reexpansion should be done in just minute or two (if even that long).
Hi Stephen, thanks for this. I have issues with the sample script. I ran it against a bunch of mailboxes, it didn't set the text on the discription fields of their calendars. help...
After powerpoof sets the string, it then restores whatever was originally there. So don't expect to see the string in there when you look. If you want detailed output on what the tool did, use the -v switch. If it didn't report any errors, then it did it's part for triggering the poof.
If it did report errors, you can report them back here.
Does PowerPoof remove the string from the Calendar Description once it's finished "poofing"? (I can't believe I'm using the word 'poof')
I have run PowerPoof several times, and once finished, I do not see the CleanupExpansionCachesInTheCalendarFolder string in the Calendar description.
yep - see previous comment (or glance over the code if you're dev inclined!)
The script worked. Thanks Stephen. You are awesome.
We added registry Key on server which has users mailbox
Added CleanupExpansionCachesInTheCalendarFolder for couple of users from outlook , unfortunately it didnt worked in my case.
Is there any logging i can turn on which will actually say that cache is deleted
It's quite possible the issue you're seeing isn't actually the issue described in the post.
Try going to one of the items in OWA that you think isn't rendering right and change the subject. Doing this from OWA will force re-expansion for the item. If that doesn't fix the problem for this item, then you're not seeing a problem that Poof would address.
If you want to verify the reg key is being read on the server, use regmon with a filter of "CalendarRecovery". The key should be read any time you set CleanupExpansionCachesInTheCalendarFolder on a calendar folder.
If you don't see the reg key being read, then it's possible ExCDO isn't starting on your Exchange server (which is a much bigger problem) - check the event logs for related errors.
Does this work for calendars stored in public folders, too? Or is it just for the calendar in the user's Inbox? If not, is there a similar way to force a Poof of a public folder calendar? Thanks!
The Poof process should work on public folder calendars, but you'll need to do those manually. The caveat about cached mode applies if the PF calendar is cached.
The sample I wrote doesn't hit public folders, but you're welcome to write your own. :)
I am running the PowerPoof script. But I still have some users complaining about their calendar being off by one hour. Mostly PDA users with intelli sync. Can you help me or let me know what i am doing wrong. I have followed your instructions to the dot from above.