Ben’s Tech Blog

We recently noticed that there were some blank entries in the GAL, in other words, there was a completely blank line between some objects in the GAL. If I double-clicked on any of these blank entries I’d receive the following message:

The properties dialog box could not be displayed. Internal MAPI error: An unsupported interface was requested of an object property. Contact your administrator.

The blank entries where only included in the ‘online’ GAL, offline address books were not affected, as well as Outlook Web Access and Outlook Mobile Access.

It turned out that someone had modified the security ACL of an OU, and Exhange no longer had access to view these users. The OU contained user objects for users who had left, but they were still mail-enabled, although interestingly enough, hidden from address lists. Once I set the permissions of the OU back to the default (which includes rights for the Exchange Domain Servers and Exchange Enterprise Servers, and rebuilt the domain RUS object the blank entries disappeared.

I was updating a link that we have in our MailSweeper 4.3 notification messages (i.e the messages that are sent to recipients when an email is blocked), and came across an issue. The new link contained a space, so it had ‘%20′ in it. For example, http://intranet.net/email%20policy. The problem was that Mail Sweeper uses the ‘%’ symbol to identify a ‘token’ as they call it. This was screwing up the message notification and causing it to remove all the text between the ‘%’ in ‘%20′ and then next ‘%’, which happened to be a few lines down. This makes sense because it assumes that any text between two ‘%’ symbols is a token.

I managed to implement a work-around by encapsulating the link with < > brackets instead of using ‘%20′ for the space. So, I inserted the link like this instead:

<http://intranet.net/email policy>

Despite being an excellent product, Microsoft Exchange has some limitations when it comes to email management for teams. There are several approaches to implementing a team email delivery/management solution with an ‘out of the box’ Exchange deployment but unfortunately each solution has a drawback.

This topic has been on my mind a fair bit recently as we have been setting up team messaging solutions under a new company structure. In the past I’ve implemented custom form solutions to manage team messages so that all of the desired features are incorporated, however custom forms are not used by this company and they don’t wish to use them moving forward. With that in mind, we had to look at the default solutions and compare their behaviors before making recommendations to the various teams.

The following table illustrates the solutions that we offered to each team with the behavior of the replies to messages that are sent to the team. Interestingly enough, accessing a shared mailbox via OWA was often the best solution for customer service teams that wanted to be able to track their sent items.

I’ve added 2 scripts that I created recently to the scripts page. Check out the links below.

VBScript - Export a list of Mail Enabled Public Folders visible in the GAL
VBScript - Export a list of all Mailboxes with their home Server, Storage Group and Database.

We had a user contact us yesterday who had deleted a public folder that contained a large number of subfolders and items. This is not usually too much of a drama, we have a 14 day deleted items retention period on our public folder stores, so its usually just a case of adding the DumpsterAlwaysOn key to the registry on the client, browsing to the parent public folder, clicking on Tools, then Recover Deleted Items and selecting the folder to recover. This time however, we received the following message when attempting to recover the folder:

“Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder, and try again. If the problem persists, contact your administrator.”

Naturally, we checked the permissions; in fact we tried to use the Exchange service account mailbox to recover the folder but received the same error. We also tried temporarily disabling Trend ScanMail (our Exchange level antivirus) in case it was interfering with the recovery process. The folder would actually appear in Outlook temporailly before it produced the error, at which point it would disappear again.

We did a lot of searching around to find a solution; most forums and articles that we came across either suggested to check permissions and disable the antivirus like we had done or use isinteg to repair the database (which I’m not such a fan of). Others suggested that it wasn’t possible to recover the folder at all. After some more searching I came across a tool called MFCMapi.

Once I downloaded MFCMapi, I was able to browse the folders that had been deleted. I tried to recover the folder that the user had deleted, but it produced an error. However, because I was able to browse the sub folders, I attempted to recover one of the them and it was successful. I tried several folders, some were successful and others were not. I figured if we could get some of the contents back it would be better than nothing. It appeared that some of the contents were corrupted, which would explain was why Outlook was unable to recover the folder. Outlook doesn’t provide the option to recover the sub folders, and this is where MFCMapi really helped. I was able to restore the majority of sub folders with 5 or 6 of them not wanting co-operate.

You can download MFCMapi from here.

Once downloaded and extracted, run MFCMapi.exe and close the welcome window. To browse deleted public folders do the following:

1. Click on the Session menu and click on Logon and Display Store tables. You’ll see that it uses Outlook to connect to the stores, select your Outlook profile and click on OK

2. Click on the MDB menu and select Open Public Folder store. Tick the Use Admin Privilegesbox and click on OK.

3. Expand Public Root and IPM_SUBTREE. You’ll then see the public folders that you would normally see under “All Public Folders” in Outlook.

4. Navigate through the public folder tree until you get to the parent folder of the folder that you are trying to restore.

5. Right click on the parent folder and select Open Deleted Sub Folder Table. A new window will open displaying the deleted subfolders. Right click on the folder and select Restore Deleted Folder. A box will open up that allows you to select to also restore the subfolders, tick that option and click on OK. You may receive an error message stating that the folder couldn’t be restored, much like I did.

If you don’t receive the message then the restore was successful and you should see the public folder and items appear in Outlook. If not, don’t panic just yet, you may be able to restore some (hopefully most) of the subfolders. If this is the case, just navigate through the folder structure and attempt to restore each folder. Unfortunately it doesn’t allow you to select multiple folders using CTRL or SHIFT; I spent a fair bit of time restoring each folder one by one.

Considering that I was able to restore most of the folders and items that had been deleted, I was happy with the result, and so was the user. MFCMapi proved to be a very useful tool and I’m sure there will be times when I’ll need to use it again.

I have added a script that I created last week to search for text in Outlook message attachments.

VBScript - Search Outlook Message attachments

Summary: To force Outlook to resolve a name from the Contacts folder instead or the GAL, add ‘(e’ after the name that you want to resolve.

If you’re using Outlook in a corporate environment, you will most likely use two address books: the global address list (GAL) and your Outlook contacts.  The order in which these are searched when performing a ‘Check Names’ is determined by the order specified in your profile.  In Outlook 2003, you can modify the order by opening the address book and clicking on Tools, then Options.  You will be presented with the following dialog box, and can use the arrows to the right of the lower box to change the order of the address books.

In most cases you will specify the GAL as the first entry and your Contacts as the second entry as most users send a greater volume of emails internally than externally.The problem however is that if you want perform a check names for an external recipient and you have a large GAL, chances are the name is going to resolve to one or more names in the GAL and not the recipient in your Contacts folder.  A while back I discovered a little trick to overcome this.  The display name of recipients in your Contacts folder is suffixed with ‘(email)’, so all you need to do to ensure that the name that you enter will resolve against your Contacts folder instead of your GAL is to include ‘(E’ after the name.  For example, if you have a recipient called John Black in the GAL, and a recipient called John White in your contacts folder, typing ‘John (e’ and performing a ‘check names’ will force Outlook to resolve the name to John White from your Contacts folder, because the ‘(e’ doesn’t exist in the display name for John Black in the GAL.

This trick regularly saves me time so I thought I’d share it with you

How reliable is email? I get that question alot from users, and in recent times I’ve had to tell them that it’s not very reliable at all. There’s no doubt that spam is to blame; several years ago I beleived that email was reliable - you could realistly expect that if you addressed a message properly that the recipient would receive it, if not you’d receive a mail failure.

In Fred Langa’s experiement he found a 40% failure rate for valid, non-spam emails. Based on his findings, Fred concludes that spam filters are often to blame. Over-sensitive spam filters are definitely the main cause for most lost mail, and the problem is that if a message is blocked as spam, the sender won’t receive a mail failure and therefore is unaware that the message never got to the intended recipient.

The other problem however is that spam has bred a culture of ‘delete key happy’ users; if an email looks like spam then it’s probably going to get deleted, and in alot of cases it will be deleted without being opened at all. Although spam filters appear to be the main cause for lost email, the human element is starting to play a large role too. I’ve come across cases where users have asked me to track down an email that “they never received”; after checking the mail gateway where our filtering takes place, and performing an Exchange message tracking center search, I’ve discovered that the message was in fact delivered to their mailbox. Take a quick look in either their deleted items or the items that have been permantely deleted from their mailbox (retreivable by using the DumpsterAlwaysOn reg key) and its not rare to find the message that was “never received”. Usually in these cases the user was not actually expecting the message and the subject looked like spam so they deleted it. Afterwards, the sender has told them that they sent them a message but the user doesn’t make the connection between the message that they deleted and the message that they are now expecting to have received.

While there are efforts by various vendors and groups to improve SMTP (like Microsoft’s Sender ID for example) I think it will be a while yet before internet mail will be reliable and trustworthy.