Poof Your Calendar – Really!


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

Key:           HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EXCDO\Parameters
Value (DWORD): CalendarRecovery
Data:          1

Next, in the description field of the properties of the Calendar folder, set the following text:

CleanupExpansionCachesInTheCalendarFolder

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:

PowerPoof.zip

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.

Update:

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.

Comments (59)

  1. Craig says:

    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.

  2. blake says:

    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.

    Thanks!

  3. Stephen Griffin says:

    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.

  4. Courtney says:

    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

  5. Stephen Griffin says:

    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).

  6. Theresa says:

    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…

  7. Stephen Griffin says:

    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.

  8. Shawn says:

    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.

  9. Stephen Griffin says:

    yep – see previous comment (or glance over the code if you’re dev inclined!)

  10. Theresa Ebagua says:

    The script worked. Thanks Stephen. You are awesome.

  11. Rakesh says:

    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

  12. Stephen Griffin says:

    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.

  13. jlathem says:

    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!

  14. Stephen Griffin says:

    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. :)

  15. Serhat says:

    Hi There

    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.

    Thanks again,

    Serhat

  16. Stephen Griffin says:

    Poof would only address instances where OWA and Outlook render the same recurring meeting differently. If the meeting is wrong in both Outlook and OWA, Poof won’t fix it.

  17. Srini says:

    Hi, we are unable to poof public folder calendars even though we configure in online mode. Please help!

  18. Dennis says:

    Stephen…

     I’m running PowerPoof : >powerpoof -P Outlook -S server > c:Poof.txt ..

     Is this tool just opening the calendar and put the syntax in the description field, then reading the reg key?

    Thanks

  19. Stephen Griffin says:

    It just puts the string in the calendar description. Exchange is monitoring for the string to be written. When it sees it, it checks the reg key to see that Poof is actually enabled, then performs the Poof if it is.

    My sample does not read or write the reg key – it has to be written manually to the Exchange server.

  20. Efrain says:

    Sweet… just sweet! Works like a charm! You-the-man!

  21. Dennis says:

    Stephen Griffin…

      Thanks!! PowerPoof worked perfectly!!!

    Dennis-

  22. Tom says:

    Stephen,

    I went into the registry but can’t find the EXCDO. We are running on exchange 2003 enterprise SP2. Thanks

  23. Kevin says:

    The poofing fixed entries that were off, but it created duplicate entries for all recurring appointments.  Dupes are not visable through Outlook, only OWA.  Please help!

  24. Stephen Griffin says:

    Kevin – you might try the Poof again. I’ve not seen that happen before.

    Tom – you need to create the key. Craig pointed that out earlier.

  25. Joe says:

    Stephen,

    Thank-you for this tool!!  Can you elaborate on how to fix Public Folders.  I am not sure what you mean by "do it manually".

    Thanks

  26. Stephen Griffin says:

    You’ll have to set CleanupExpansionCachesInTheCalendarFolder on the description of the Public Folder calendar folder using Outlook. The sample does not operate on Public Folders.

  27. Jennifer says:

    ok…I’m a little confused.

    I did the reg key…but am unsure where to do this

    Next, in the description field of the properties of the Calendar folder, set the following text:

    CleanupExpansionCachesInTheCalendarFolder

    I thought I did it througgh outlook, but it’s not working…what am I missing?

    Is there anothe rplace to set this text?

    thanks!

  28. Stephen Griffin says:

    Assuming you’re not running into the cached mode issue I identified above, it’s possible whatever issue you’re experiencing with the Public Folder calendar isn’t the issue described in the blog.

  29. Jennifeer says:

    *doh*

    never mind…I was putting the reg key in the wrong place

  30. Jennifer says:

    can someone give me an example of what legdns.txt should look like?  I’d really appreciate it.

  31. john says:

    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

  32. john says:

    I guess it is a permissions issue.  What permissions does the user account need?  Full permissions to all the mailboxes?

  33. Jennifer says:

    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?

  34. aaron says:

    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?

  35. skyh00k says:

    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.

    skyh00k

  36. tjbruins says:

    Stephen,

    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?

  37. Stephen Griffin says:

    Interesting – you should look on the Exchange server and see if any events were written in the Application log when you did that.

  38. tjbruins says:

    There are many EXCDO Error Event ID 8209 & 8201

    Calendaring agent failed with error code 0x8000ffff while cleaning up the calendar.

  39. Carol says:

    Does Poofing work in Exchange 2007?  What is the filter to use with Process Monitor (v. 2.8)?   Thanks!

  40. Stephen Griffin says:

    Yes – poof applies in Exchange 2007. I don’t know why you’d be using Process Monitor here.

  41. Michael says:

    @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?

  42. Stephen Griffin says:

    Forgot I had mentioned Regmon. :)

    You might want to open a case to have this investigated.

  43. Jeremy says:

    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.

    thanks,

    Jeremy

  44. Stephen Griffin says:

    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.

  45. Bryan L says:

    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.

  46. Rick says:

    How do you know when a mailbox calendar is done "poofing"? Is there a event written in the Application log? Or if it's not gone from the Outlook description then it isn't working?

  47. Deb W says:

    Poof!  It works like a dream…  Thanks for great tool!

  48. TBHamil says:

    If recurring meetings are not showing in OWA but are showing in Outlook mapi client will running Poof against the calender correct that issue

  49. Todd L says:

    How does one correct the 0x8004010F error cannot locate calendar? I have tried two accounts to run Powerpoof, both are domain admins.

  50. Stephen Griffin says:

    Todd L – try running Outlook as your admin account and see if you can log on to the mailbox. You probably don't have permissions to the mailbox.

  51. Todd L says:

    I created a new user (Powerpoof) gave it full rights to the Exchange server. Created a new Outlook profile for Powerpoof and started Outlook. Added the mailbox for Abington and opened his calendar. Then went to dos and ran

    C:poofPowerPoofRelease>powerpoof -p "Outlook" -s ghsmsex5 -m "/o=ghs/ou=first

    administrative group/recipients/cn=todd.abington" -v

    INFO: OpenOtherUsersMailbox called with lpMAPISession = 0x00B61F90, lpMDB = 0x00

    E22180, Server = "ghsmsex5", Mailbox = "/o=ghs/ou=first administrative group/rec

    ipients/cn=todd.abington"

    INFO: Calling HrMailboxLogon with Server DN = "/cn=Configuration/cn=Servers/cn=g

    hsmsex5/cn=Microsoft Private MDB"

    INFO: HrMailboxLogon: Creating EntryID. StoreDN = "/cn=Configuration/cn=Servers/

    cn=ghsmsex5/cn=Microsoft Private MDB", MailboxDN = "/o=ghs/ou=first administrati

    ve group/recipients/cn=todd.abington"

    ERROR: , Code: 0x8004011D, Function lpMAPISession->OpenMsgStore( NULL, sbEID.cb,

    (LPENTRYID) sbEID.lpb, NULL, MDB_NO_DIALOG | MDB_NO_MAIL | MDB_TEMPORARY | MAPI

    _BEST_ACCESS, &lpMailboxMDB), File .MAPIStoreFunctions.cpp, Line 335

    ERROR: , Code: 0x8004011D, Function HrMailboxLogon( lpMAPISession, lpMDB, szServ

    erDN, szMailboxDN, bUseAdminPriv, lppOtherUserMDB), File .MAPIStoreFunctions.cp

    p, Line 378

  52. Stephen Griffin says:

    If it's just the one user you need to Poof, then do the Poof manually – set the comment on the calendar using the steps I gave.

  53. Todd L says:

    Thanks for your help. I have 88 users to do. I discovered my typing error, left off the cn infront of recipients. Poof now works!

    Thanks again!

  54. Stephen Griffin says:

    Ah – I see it now. Good catch!

  55. Fez says:

    Are these files hosted anywhere currently?  The link in teh article is not functional.  Thanks!

  56. Stephen Griffin says:

    Fixed

  57. Worker says:

    Does anyone know if this is still relevant for Exchange 2010 and 2013?

  58. Another Worker says:

    Yes, is this still relevant?  We are experiencing all kinds of Exchange/Outlook calendar issues.  I can't do this in our lab since our lab users don't have calendar issues.

  59. Stephen Griffin says:

    I believe this last applied in Exchange 2007. I don't see the code in 2010+.