Monday, 25 June 2007

Outlook Missing Appointments 2 - organizer was an invitee

In my earlier post I talked about the most important piece of information to remember when troubleshooting missing Calendar appointments:
Deleting a meeting invitation or update will delete the associated appointment.

Sometimes we see a special case of this: a meeting invitation was sent out, and now everyone seems to have the meeting in their Calendar except, perplexingly, the person who organized it.
This usually occurs when a meeting organizer invited a Distribution Group (DG) of which they are a member. Typically what happens is something like this:
  • George is in the Sales department and wants to set up the weekly department meeting
  • So he doesn't forget anyone, George invites the SalesDept DG in his address book
  • Because George is a member of the SalesDept DG, he also receives an invite to the meeting
  • George knows he already has the meeting in his calendar because he only created it a moment ago, so he deletes the invite from his Inbox
  • Outlook removes the meeting from George's calendar
The 'solution' to this problem is for George to always remember to expand out any DG he invites to a meeting before sending. But George wants to know how he can fix this meeting where the mistake was already made.
If George is lucky enough to be running in an Exchange environment where Deleted Item Recovery (aka The Dumpster) is enabled, he should go to his Calendar, select Tools > Recover Deleted Items, search for the meeting by subject, then restore it to his Calendar. He can then Cancel the meeting and re-book it with the SalesDept DG 'expanded' so that all the invitees appear individually.
If Deleted Item Recovery isn't available (or all this happened a long time ago and was only just noticed, so the item has already been purged from the Dumpster), the only option for George is to ask his colleagues to each delete their copy of the meeting from the Calendar and to re-book it.
A variation on the symptoms I described is where the Organizer has the meeting in their Calendar, but they are no longer able to make changes to it; the options available are the ones they would have if they were an attendee, i.e. Accept, Decline, etc. This usually occurs as a result of the problem above, but where further attempts have been made to get the item back either by having it forwarded from an attendee, or by recovering the original invite from the Deleted Items Folder. The root cause and solution are, however, the same.

Friday, 22 June 2007

Outlook Missing Appointments 1 - invite or update was deleted

Many of the issues I have to troubleshoot concern appointments missing from someone's calendar.
Before I start re-inventing the wheel, How to troubleshoot missing and duplicate appointments in Outlook already covers some of the background on how appointments go missing. However, by far the vast majority of missing appointment problems I see are caused by one not-so-obvious feature of mail based Calendaring in Outlook:
Deleting a meeting invitation or update will delete the associated appointment*

(*This was changed in Outlook 2007 - I guess someone finally realised how much trouble it causes.)
Today I'll cover some fairly straightforward ways this can trip up the unwary, then post soon with a special case that adds another layer of confusion.
Here's what happens - for versions of Outlook up to 2003, that is:
  • Anne invites Bob to a meeting
  • Bob accepts the invitation from his Calendar instead of from his Inbox
  • This leaves the invite in the Inbox (where accepting from the Inbox would have removed it)
  • Bob sees the invite in his Inbox and thinks "I already accepted that, I don't need it" so deletes the invite
  • Outlook removes the meeting from the Calendar
The solution to this is for Bob to remember to always Accept or Decline invites from the Inbox.
Another way confusion can occur is in a manager/delegate relationship. Say Claire has a delegate, Dan, who looks after her diary. Dan receives a copy of all Claire's meeting invitations and updates but, critically, so does Claire:
  • Dan sees an invitation in the Inbox to a meeting he knows Claire will want to attend, so he Accepts it on her behalf
  • Claire also has the invite in her Inbox
  • Claire knows Dan has Accepted the invitation on her behalf, so she decides she doesn't need it in her Inbox and deletes it
  • Outlook removes the meeting from the Calendar
The solution in this case is to change the Delegate options on Claire's mailbox so that only her delegates receive meeting items. If she really feels that she needs to see them, she'll have to remember not to delete them!
Deleting an Updates to a meeting has much the same effect, like this:
  • Evan invites Fiona to a meeting
  • Fiona accepts the invitation
  • Later, Evan sends out an updated version of the meeting including travel information for out-of-town attendees
  • Fiona doesn't need the travel information, so deletes the update from her Inbox
  • Outlook removes the meeting from the Calendar
The solution here is for Fiona to make sure she never deletes a meeting update - she should always Accept if she plans to attend or Decline if she doesn't.
A lot of troubleshooting I get involved in, the user is absolutely adamant that nothing they're doing could cause their meetings to disappear, that there must be some gremlin in the system. They've heard it's a problem with BlackBerry/our CRM application/Cached mode/the moon in Taurus/whatever, they've had this problem for months, they're sick of it and they want us to fix it for them. That's when I use my secret weapon - this article from Microsoft:
It can take some persuasion to get them to read it (sometimes I say "just so you can give some pointers to the newer team members" or "so you know what to look for when your manager is doing something wrong") but I don't think it's an exaggeration to say 99% of those ongoing problems don't come back when people follow the advice in there.
Next time I'll cover how a meeting organizer can become an attendee and get into an even deeper mess...

Friday, 15 June 2007

How to delete Outlook temporary files

Outlook* caches file attachments to %userprofile%\Local Settings\Temporary Internet Files\OLKnnn (where nnn is a random number). If you're a system administrator and you can connect to the user's c$ share then it's no problem to empty this folder, e.g. in the fairly common scenario where a user cannot view embedded attachments (a.k.a. Red-X syndrome).

* 2003 and earlier - for instructions for Outlook 2007 see my new post here.  Outlook 2000 before SR1 kept temporary files in %temp%.

But what do you do if you can't get a connection to the user's machine? Direct the user to their Temporary Internet Files folder and most likely they won't be able to see the folders underneath due to Windows' clever (?) obfuscation. (The slightly off-topic article has an explanation of this in the introduction.)

Short of writing a script and somehow getting that across to the user, I haven't found a better way of doing this than through the command prompt. Here are my preferred instructions, but let me know if you can suggest improvements!

[Update 4-Jul-2007: I forgot when I wrote this that the file locations changed for Windows Vista - for updated instructions, see my new post here]

  1. Start > Run > Type "cmd" (without the quotes) > Click OK

    In the command line, type the commands in bold (excluding my numbering and hitting return after each line)

  2. cd "%userprofile%\local settings\temporary internet files"

  3. dir /ad

    You should now see a list of folder names - one or more will begin with OLK.

  4. cd olk*

    This should make the first OLK folder the current directory - type the full folder name instead of OLK* to select a different one)

  5. explorer .

Note the space before the "."

This will bring up a Windows Explorer window showing the contents of the folder which you can then delete, but only after you've checked the address bar to make sure you're in the right folder!

If there was more than one OLK folder you can get to it by typing "cd.." at the command prompt then repeating steps 3 and 4 to select the OLK folder with the next folder name.

Type exit in your command window to close it, or just click on the x when you're done.

Thursday, 14 June 2007

Forms and Outlook item types

Regardless of whether your Outlook data is stored on an Exchange Server or in a PST file, all of your Mail, Calendar, Task, Contact and other items are stored in messages.

The fact we can see different types of item (appointments, tasks, etc.) seems to contradict this, but the messaging system that underlies Outlook deals in messages and nothing else. We see messages with different properties, being displayed in different forms.

If you use a tool such as MFCMAPI or MDBVU (the usual disclaimer applies) to look at an item's properties, you will see the PR_MESSAGE_CLASS property for a mail item is set to ipm.note, where a calendar item would be ipm.appointment. Outlook opens the correct form (a form is a defined layout for displaying an item) depending on the PR_MESSAGE_CLASS which is how your calendar appointments get scheduling information displayed and your mail items don't.

Outlook has a form associated with each folder - whether it's one of the default folders (Inbox, Calendar, Tasks, etc.) or one you created. Each folder is associated with a message type, and also with a form to go along with it. So if you wanted to create a custom form to show different information for the contacts in your Mobile Contacts folder, you could do that.

A common scenario to troubleshoot in a large corporate environment is where a user is unable to open items of a certain type, or where items of a certain type don't behave as they should (e.g. a button on the form doesn't work). Outlook caches custom forms to save loading them each time they are used, and sometimes this cache can become corrupt, so clearing the forms cache is a logical early step when dealing with this type of issue.

For more information on the forms cache and how to troubleshoot it see

Tuesday, 12 June 2007

The Outlook Inbox Sniffer

There's not much information around on the web about the Sniffer, but I was lucky enough to get hold of some pretty good documentation last year that covers how it works. Outlook's Inbox Sniffer is a piece of built-in code that keeps an eye on your Inbox for items of a certain type, and performs certain actions for you. The complete list is as follows:
  • Meeting invites (adding tentative meetings to your calendar)
  • Meeting updates (updating details in your calendar)
  • Task updates
  • Message recall (when someone recalls a message you've received)
  • Responses to voting buttons (when you sent a mail with voting buttons, this adds the voting responses back to the original item)

This applies to Outlook versions from 2000 onwards. The results are slightly different in Outlook 2007 (e.g. the way meeting updates are processed) but - as far as I know - the mechanism is the same.

The Sniffer runs as a MAPI idle process. This means it starts processing when the messaging system that underlies Outlook isn't otherwise busy. This doesn't necessarily correspond to whether the Outlook application is busy though. You could be typing an email message and the Sniffer would still fire, whereas it won't fire if mail is downloading from a server, even though you're not 'using' Outlook at the time. This is why sometimes invites appear to show up as tentative Calendar entries almost straight away, and sometimes they take a little longer.

So far so good... but what do you do if the Sniffer isn't working?

(This bit bit contains technical advice, so my usual disclaimer applies.)

  • First, is the actionable item actually in the Inbox? If, say, a meeting invite got moved to a folder by a rule then it may have left the Inbox before the Sniffer got to it. If the rule is client-side then you could get a Rule vs. Sniffer race occurring.

  • Next, have you told Outlook not to process some item types? The settings Process requests and responses on arrival and Process receipts on arrival need to be selected (Tools > Options > Email options > Tracking Options) for those actions to take place.

  • Is this machine able to run the Sniffer against this mailbox? To deal with users running Outlook on more than one machine with the same mailbox, a mechanism was put in place where only one can be the Sniffer at a time (the Sniff Owner). Run Outlook with the /sniff switch to set it as the Sniff Owner, or /cleansniff to delete and recreate the Sniff Owner information.
  • Is there any idle time? An add-in or another application calling Outlook could be keeping MAPI busy (or making it think it's busy). Try closing down any applications that may interact with Outlook, e.g. synchronisation tools, and waiting at least five minutes before checking if items have been processed. If that didn't isolate the problem, try disabling any add-ins you have loaded in Outlook, wait five minutes and check again.
  • Is thre a long idle time specified in the registry? Under the key HKEY_Current_User/Software/Microsoft/Office/11.0/Outlook/Options/General check for these values
    • AutoProcessIdleTime - this is how much idle time is required before the Sniffer will act
    • AutoProcessIdleTimeMax - this is how long the Sniffer waits before trying again if MAPI was not idle on the previous attempt
  • Both the values are specified in milliseconds (so a value of 10000 is 10 seconds). If these don't exist in the registry then the defaults are used, 30 seconds and 600 seconds respectively. Setting a lower value for both would cause the Sniffer to run more frequently, but there would be an associated performance hit on the rest of Outlook. Setting the value very low would cause the Sniffer to run almost continuously, taking up system resources that could be used for other tasks.
  • Is another application or add-in marking the items as 'sniffed'? This is the least likely scenario but theoretically could happen. To test for this you would need to look at the message properties of the Inbox item using a tool such as MDBVU or MFCMAPI. If the PR_PROCESSED property is set to TRUE then the Sniffer will not act on this item again because it thinks it has already done so. (If the property doesn't exist or is set to FALSE then the message has not been marked as sniffed.)

That covers just about everything I know about the Sniffer - I hope this post has been useful to someone out there!



One of the main reasons I started this blog was as a place to post technical troubleshooting tips. In an ideal world I wouldn't need to post a list of DON'Ts (and in the real world the people who most need them are least likely to read them) but this seems like the responsible thing to do. So here's a list of things you should bear in mind before following any advice I might post, to safeguard your data, your job and my conscience:
  1. Most of my technical posts are aimed at IT Professionals who already have a good understanding of Windows and the products I'm talking about. If you're not comfortable working at that level then get individual help from someone who is.
  2. Don't edit the Windows Registry unless you're pretty sure you know what you're doing.
  3. Don't make any changes through MFCMAPI, MDBVU or similar tools unless you're certain you know what you're doing - they give you access to things in your mailbox that you're not supposed to see, and those things are hidden for good reason.
  4. Your boss will not come looking for me if you screw something up because of some 'good idea' I post in my blog. Everything I say here is in good faith, but I make mistakes just the same as everyone else. Treat every bit of information here with healthy scepticism and don't do anything on a production system unless you understand the consequences and (ideally) have tested in a non-production environment first. That goes for anyone else's blog too, and even perfectly trustworthy vendor information has been known to cause problems if used slightly differently to how it was intended so it's good advice regardless of the source.
Sorted. Now we can get back to talking like grown-ups.

Monday, 11 June 2007

Face search in Google

Here's a very cool trick to return just photos of faces using Google's image search... (I'm still working on the promised post about how Outlook's Inbox Sniffer works)

Thursday, 7 June 2007

Appointments, meetings, invites, updates and responses

And so for my first proper (read: useful) post. This post was going to be about how Outlook's Sniffer works on calendar-related mail items - largely because this feature is pretty much undocumented and I find myself explaining it quite often. However, I realised there's some background information to cover first. I hear the terms appointment, meeting and invite used interchangably, which doesn't matter too much at a user level but can cause confusion when you try to troubleshoot calendar problems. In fact the three things are different, and it's useful to understand the distinction.
  • An appointment is an Outlook Calendar item
  • A meeting is an appointment with invitees
  • An invite is a mail item that tells Outlook to create a Calendar item (also known as a meeting request)

...and while I'm writing a mini-glossary of calendar terms...

  • An update is a mail item that tells Outlook to change a Calendar item
  • A response is a mail item that tells the user that someone accepted or declined their meeting, and tells Outlook to update the meeting's Tracking information

In fact, at the mailbox level, all of these (along with Tasks, Notes and pretty much anything else you can store in a mailbox) are messages regardless of their type or whether they live in your Calendar, Inbox or wherever. One day I'll write a post about different message types and how Outlook knows what to do with each, but it isn't important for the purpose of understanding how calendaring works.

Anyway, a typical calendar scenario might go like this...

  1. I decide to book a meeting with my colleagues Anne and Bob. I create a meeting item, and add them as invitees.
  2. When I've finished entering all the details, I hit Send. At this point, my meeting item is saved in the Calendar, and Outlook creates a meeting request (a type of mail item) containing the relevant details of the meeting, which it sends to Anne and Bob.
  3. Anne receives the invite in her Inbox. (Bob does too, but we're just looking at Anne's mailbox right now. Thankfully neither of them have delegates because this post is getting long enough without covering delegate behaviour - again, another post for another day.)
  4. On Anne's machine, Outlook's Inbox Sniffer - that's our undocumented friend that acts on certain types of message in your Inbox - sees a new invite has arrived so uses the details from it to create a new meeting item in her calendar, which it marks as Tentative.
  5. A few minutes later Anne sees the invite herself, opens it and clicks on Accept then chooses to send the response without editing it. At this point, Outlook creates a response (a type of mail item) which it sends back to me, and marks the meeting in Anne's calendar as Accepted.
  6. I receive the response item in my Inbox. The Sniffer sees it and marks Anne's Tracking status for the meeting as Accepted. Because I have the option selected to delete blank meeting responses after processing, it also deletes the response from my Inbox.

So far we've created two calendar entries (one in each of our calendars) and two message items (an invite and a response). This is the crux of mail-based calendaring, every action on one calendar has to be communicated to the other calendar(s) by messages. A point of note is that mail items arrive in the Inbox, meetings and appointments live in the Calendar. They're connected (Outlook has an identifier property on the original Calendar item which all the other items reference so it should always know which response or update refers to which meeting) but very much separate - knowing this is useful when trying to troubleshoot missing appointments, which at my place of work is something we spend a lot of time doing!

If I later decide to change the time of the meeting, I can change the meeting item in my Calendar, and send an update (another mail item) to Anne and Bob, which their Inbox Sniffer will process much the same as before. And again, they can send a response which my Inbox Sniffer will process.

There are pitfalls around this mail-based structure, especially if you bring a delegate into the mix (one meeting, one Calendar, but potentially two copies of the invites/updates and two sniffers... it's a recipe for confusion) and I guess that's something else to add to my ever-growing Topics For Future Posts list.

I said at the start of this post it would be useful. I'm not sure if it actually is directly useful but it should give an idea of how calendaring works in Outlook, which will be relevant when I post on more practical topics in future.

That's all for now


Wednesday, 6 June 2007


Hello and welcome to my BWAINdump. (BWAIN = Blog Without An Interesting Name.) I expect this will be a kind of public notepad for me to jot down observations, hints and tips on whatever technology I'm working with most at the time - right now it's Microsoft Office. Instead of emailing people technical articles and explanations for problems I get involved in troubleshooting, I can post them here and just email links. That way I get to repeat myself less, and the rest of the world gets to share any nuggets of wisdom I accidentally stumble across. Oh, and this is my first venture into the blogosphere, so if I screw up please tell me what I need to put right and don't be too hard on me. TTFN TechieBird
Creative Commons License This work by TechieBird is licensed under a Creative Commons Attribution-No Derivative Works 2.0 UK: England & Wales License.