Mike Southby

I’ve had a number of support queries at work recently relating to NDRs being generated when a user sends meeting invites in Outlook reporting that a mailbox does not exist.  Confusingly, the NDRs relate to an account which not only was not invited to the meeting but also no longer exists within the organisation; an AD search for the mailbox yields no results.  It turns out the reason for this is due to one of the invitees having a delegate whose mailbox has been deleted.  If you have come across this issue before, you’ll know how tricky this can be to resolve.

In order to fully understand why this is happening, it’s important to know what happens behind the scenes when a user gives delegate access to their mailbox, not only will this help you to understand why this problem occurs, but it will also help to understand what actions need to be taken to resolve the problem.

Let’s assume you have an existing mailbox for user A who wishes to make user B a delegate.  When the delegation is made the following takes place:

• The appropriate sharing permissions are placed on the relevant folder in user A’s mailbox, these of course will vary depending on which permissions were set using the delegation tool.
• If the checkbox for forwarding meeting requests is set, a special hidden forwarding rule is created in user A’s mailbox.  As this is a hidden rule, you will not see the rule listed in Outlook.
• User B is added to user A’s publicDelegates attribute (or more commonly known as the send-on-behalf-of field), and user A is added to the publicDelegatesBL attribute of user B; this does not always happen depending on a number of circumstances, for example more recent versions of Outlook or when the person trying to set the delegation is not actually the owner of mailbox A.

So far so good, but let’s assume now that some time has passed and for whatever reason user B leaves your organisation and as such, their mailbox is deleted from within AD.  Further, the System Administrator performing this action would have no idea of user configured delegations and AD itself would not intuitively make them aware of any which is where the fun begins.

Once the mailbox for user B is deleted their publicDelegatesBL entry in AD gets cleared out so there is no easy way to work out who they were actually a delegate for; we can now think of them as an orphaned delegate. Even more problematic, the hidden forwarding rule in mailbox A does not get updated; as with security group membership and other AD functions, you’d have hoped this would take place automatically but as this is a client side feature, unfortunately not.

Assuming that you can narrow down whose mailbox has the orphaned delegation, you can manually fix this issue by the using the MFCMAPI tool to delete the hidden forwarding rule but even this is not without issues as unfortunately if there are other delegates to that mailbox, the forwarding for them would break as well.  So all of those delegates would need to be manually removed and subsequently re-added which would involve logging in manually to the mailboxes in question.  This may be a simple task but as in the situation I was faced with, not so.

As you can see, the reality is that you may not be able to actually resolve this issue.  In one of the situations I was faced with the originating user who received all of the NDRs (there were actually over 30 of them) had sent the meeting invite to a distribution list which itself, contained a number of other distribution lists.  Using the MFCMAPI tool I would have had to of manually logged into somewhere in the region of 500 mailboxes to identify who had the orphaned delegates and then subsequently, had to recreate the delegate rules for the users who I ran the tool on.  Needless to say on balance this was not an option.  The MFCMAPI tool is an option in instances where a single user receives NDRs sending to another user, or small group of users but not when large distribution lists are involved.

So just how do you stop the NDRs?

The reality is that you can’t, however you can create an Outlook rule for the sender to prevent them receiving the NDRs by automatically forwarding the NDR messages (the generated NDR error for this issue is 5.1.1 so by setting this rule you would not stop other NDRs being delivered) directly to their deleted items or even permanently deleting the message at source.

I hope someone will find this useful.  Enjoy.

For some time now I have been using Google Apps as my main mail provider, I’d been a long time Microsoft Exchange user until I made the switch from Windows Mobile devices to Android.  It made sense to change my mail provision so that I could use Android in the manner it was designed i.e. with  Google Mail, Contacts, Calendar and Tasks.

Generally, I have been happy with the service (especially when you consider the Standard Edition is free and isn’t a noticeably inferior product to the Premium Edition) although I do acknowledge it has a few quirks, not to mention horrendous support from Google should you require assistance.  Of course aside from push email support via my Android handset, the Google Apps service also includes plain and simple IMAP support; it’s here that I encountered one of the quirks.

Ever since configuring the account on my machine, whenever sending an email using Outlook two copies of the mail appear shortly after in my Gmail sent items folder (although only one copy is actually sent to the recipient).  Now this may not seem such a big deal but it has a couple of issues; firstly over time it will fill up my quota a lot quicker, perhaps not a major issue for most people but if let’s say you are sending a 1Mb file attachment, you’re going to be using 2Mb of space.  Secondly, perhaps more importantly is that when you use the Gmail web client instead of Outlook, it’s going to really mess up your conversation thread as there will be 2 copies which can be a little confusing.

So how do you solve getting two copies of sent mails while using IMAP in Outlook?

It’s important first to understand why the two copies appear and not just accept that they do.  When you send an email through Outlook, Outlook saves a copy of the sent mail and transmits it to the server (in this case smtp.gmail.com).  When the email is sent from the server to its destination, Google save another copy of the sent mail automatically which is then of course – as you’re using an IMAP connection – synced back to your machine hence the two copies.

Of course Google should be smart enough to know that the mail is being sent from a dedicated client such as Outlook and check to see if a copy has already been saved before saving it again, but alas not.  So the solution is to change where Outlook saves its local copy of the sent mail; it’s not an ideal situation but it does stop your Gmail folder from becoming full of duplicates!

To make the change, go to Tools>Account Settings>Email and select the email account in question and then Change.  This will open a window titled Change Email Account.  Click the More Settings option at the bottom.

Click the Folders tab which will enable you to choose where to store a copy of all outgoing messages (remembering that Google is going to automatically store one for you in your Gmail sent items) and change the default choice to Save sent mail in the Outlook Sent Items Folder, this will save the duplicated copy in a local unused folder instead which of course can be cleaned up when required; or you can also choose not to have Outlook save a copy of sent mail at all (again remembering that Google will automatically place a copy in your sent items).

I have been more than happy with the ability to synchronise my calendars between my Outlook and Google using Google’s own sync tool until recently when I began using Outlook 2010.  You see the problem is that Google have yet to release an update to their tool to allow the tool to work with Outlook 2010, a surprise considering how long Outlook 2010 has been available and the positive feedback it has been receiving.  Remember that positive feedback equates to more and more people using the latest version.

The problem appears to be not that Google’s sync tool will not work with Outlook 2010 but that it performs a version check on execution and will not get past the fact that it ‘thinks’ it will not work, so it simply gives an error and halts.

There is of course a way round this.

Caveat:  I take no responsibility if you manage to break your Outlook installation, remember to take a backup first and if you are unsure or have no experience of Hex editors, perhaps think twice before following these steps.  If you do a search on Google there are already Outlook.exe files available for download that have had the change made, although – importantly – be very careful downloading and running .exe files unless you are sure they come from a trusted source!

You’ll need to use a Hex editor, there are a few available in you do a search; I used Notepad++ with the ‘Hex-Editor’ plugin.  Firstly locate and make a backup (very important in case something unexpected happens!) of the Outlook.exe file which is located at c:Program FilesMicrosoft OfficeOffice14 and at assembly location 0x000c09b2 change the value to 0×32 in the ascii dump (it will have originally been 14.0.0 but now should read 12.0.0).  This in theory should only change the version number that the Outlook Add-In Manager reports to add-ins.

It works fine for me, I’m now happily synchronising between Outlook 2010 and Google once again.

Enjoy!

UPDATE: I have been getting a lot of emails asking if I can upload an OUTLOOK.EXE file with the Hex changes in place, so, if you simply want to download a patched file without making the changes yourself heres the link.  It goes without saying that you download this file at your own risk. To prevent antivirus programs blocking the file I have placed it inside a ZIP archive so you will simply need to unpackage it and place it into your c:Program FilesMicrosoft OfficeOffice14 folder but please remember as always to backup the original file first.  If you find this useful, please leave a comment.  Thanks.