A reader asked if there was a way to add a column to display the Message ID in the Inbox view.

Of course you can, it's an Extended MAPI property and is easily exposed using a *.CFG. Since it's always easier to do if someone has a ready-made CFG available, I asked around and my "resident CFG expert" Outlook MVP Michal Bednarz sent me a link to a CFG that exposes the Internet Message ID.

You can download it from his website. (Use right click, File, Save Target As)
http://www.codetwo.com/downloads/EXTENDED-PROPERTIES.CFG 

Place the CFG into the same Office folder with the *.ICO files, usually found at
                        C:\Program Files\Microsoft Office\OfficeXX\forms\[4 digit language ID]
In the English version of Office 2007, this would be
                       C:\Program Files\Microsoft Office\Office12\FORMS\1033.

The "short version" instructions for installing and using a CFG:
Go to Tools, Options, Other, Advanced Options, Custom Forms, Manage Forms. Click the Install button. Choose the.CFG file and install it. Return to Outlook and customize your view using the fields in the form you installed.

See Adding Extended MAPI Fields to Outlook for additional CFG files and detailed installation instructions.
http://www.slipstick.com/exs/customfields.htm 

by Michael B. Smith, MCSE/Exchange MVP

Long long ago at Microsoft there was a project known as LanMan 3.0. One of the first things a new guy named Jim Allchin did when he joined Microsoft was to cancel LanMan 3.0. Before joining Microsoft, Mr. Allchin was responsible for the development of a directory service known as Banyan Vines. In 1991, when all this was occurring, there were three network operating system contenders: Novell, Banyan, and Windows NT.

A couple of things survived from the LanMan 3.0 project - a small directory service and an X.400 MTA. These two items were picked up by the email group at Microsoft and ported to Windows NT. The LanMan 3.0 project was (in these almost pre-historic days!) being based on OS/2. The email group took this opportunity to use a new database called JET as the basis for the directory service.

JET was brand new in 1990. JET stood for Joint Engine Technology and referred to a project - code-named Cirrus - designed to produce a robust database engine. JET produced two separate products: Jet v1 (called JET RED - for the color of the flag of Russia) and Jet v2 (called JET BLUE - for the color of the flag of Israel). Jet Red and Blue had a completely common API, but they shared no code at all.
Jet Red went on to become the backend for the product we know as Microsoft Access.
Jet Blue is now known as ESE - the Extensible Storage Engine.

Next after basing the directory service on Jet Blue, the email group decided to continue with open standards, and built a communications protocol based on the X/Open XDS API - this is what became the basis for all Exchange communications - RPC.

Microsoft acquired an email system that used MAPI called Network Courier. MAPI stands for the Messaging Application Programming Interface - that is, it is a way for a program to manipulate messages. Microsoft used this early version of the MAPI protocol (which is now known as Simple MAPI), on top of RPC and merged it with the directory service and the X.400 MTA. This product, after lots of performance work and redesign, became Exchange 4.0.

There were also other familiar features present in Exchange 4.0: the KCC for Knowledge Consistency Checker, the ISTG for Inter-site Topology Generator, a modifiable schema, etc. All of these represent the beginnings of what became Active Directory.

When Exchange 4.0 shipped, there was very little of the original code left. After Exchange 4.0, the email team continued to develop the directory service and added LDAP v2 and the X.500 directory interface and the Internet Mail Connector. This product shipped as Exchange 5.0 and with the inclusion of LDAP v3, became Exchange 5.5. (Note that there were lots of other feature and changes involved too!)

In 1995, Cairo (which was the project that replaced LanMan 3.0) was cancelled. This left the operating system group at Microsoft in need of a directory service for the “next big operating system” (Windows 2000) and they didn’t have one. So, the code for the directory service from Exchange was “forked”. That is, a copy was made, moved over to the operating system group along with some of the personnel, and began life anew.

The rest is pretty much history. Exchange’s original directory grew up to be Active Directory as we know and love it. Starting with Exchange 2000, Exchange divorced itself from the old original directory and merged back into its descendant named Active Directory. They both still extensively use JET v2 - Jet Blue - also known as ESE.

Over the last few weeks, I've seen several questions that go something like this: "When I send a meeting invite to a staff member who has their calendar shared with other staff members, how do I stop the invite being sent to the other staff members? I would just like the invite to go to the recipient, not to everyone who has access to their calendar."

Although "There are seldom good technological solutions to behavioral problems", there are some things you can do in Outlook to reduce problems but it may not be enough to keep all uninvited staff members from receiving your meeting requests.

As the sender, you have one option: mark the invitation private. Click on the lock icon in the Options section of the ribbon or open the Properties dialog on the File menu (Office Orb in 2007), then select Private from the Sensitivity dropdown. However, delegates with permission to see private items will be able to see it. If the recipient wants delegates to see their private items, there isn't much you can do except discuss the problem with the recipient and their delegates.

If you are the recipient there are two settings you use to control who gets the meetings requests. The Tools, Options, Delegates dialog is the first place to look. The exact options available vary with the Outlook version, but the option for delegates to receive the meeting requests should be unselected if you don't want them to get your meeting requests. Secondly, highlight the delegates names and click on Permissions, check the setting for "Delegate receives copies of meeting related messages sent to me".

It's also possible the invitee is forwarding the invitation to others. There is little you can do to prevent this behavioral problem if your site is not using rights management solutions, other than asking the recipient not to forward it without your permission.