Unified Comm

One behavior change that isn't well known to most people using Outlook and Exchange is that when you turn on cached mode on the Outlook client, your address book reverts to the Offline Address Book that is generated by Exchange/Outlook. By default the OAB is updated every 24 hours since the last time it was accessed.

Typically, that doesn't cause a lot of problems except when a new user is added or deleted from the GAL and all the cached Outlook clients still see the entries or don't see the entries that are now invalid, yet people running non-cached are perfectly fine. A lot of times you end up thinking that the RUS service hasn't done its job but it really has.

If you want your cached users to allows 'ping' to the live GAL instead of using the offline address book, use this registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Cached Mode
Parameter: DownloadOAB
Type: REG_DWORD
Value: 0x00000000

One thing worth noting: If users go offline with this registry setting, they won't have a GAL to refer to anymore, so it is almost better to setup the OAB to update more often if your Active Directory isn't huge.

More background information on OAB can be found here:
http://support.microsoft.com/kb/841273

Taken from the release notes:

[snip]

To grant access to a user whose Microsoft Office Outlook is configured for cached mode, but to deny access otherwise:

The ProtocolSettings attribute on the user object in Active Directory stores client access settings.

This attribute is a multiple-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

MAPI§§§§§§§§

The eight § separators define exactly nine fields. The fields have the following meanings.

MAPI
Specifies that this string contains settings that apply to the MAPI protocol


0 to block all MAPI access; 1 to determine MAPI access based on Bool2


0 for no effect; 1 to deny access to non-cached mode Outlook clients

Remaining 6 fields
Currently not used

If there is no MAPI string in ProtocolSettings, all MAPI clients are allowed.

Note:

The access restrictions specified earlier do not apply in the following cases:
The client is an Exchange component (for example, the mailbox moves work correctly regardless of the MAPI access settings for the mailboxes) or the client is doing delegate access to the mailbox.

If the MAPI string does not have the eight separators and conforms to the expected data types, the behavior is undefined. The ProtocolSettings attribute is cached in the MBICache and in DSAccess, and these caches may delay the time that is required for a change in the ProtocolSettings to become effective.

[/snip]

Unfortunately, it doesn't handle the situation very "nicely". It will simply deny access to anyone trying to connect in with a non-cached connection.

Many thanks to anonymous commenter, "JC", for the tip on where to find this.

I've seen this on a few Exchange servers now and it is a bit strange. Something tells me that either the setup program doesn't check the right spots, or possibly some post-SP1 hotfixes register a few IMF registry entries when they really shouldn't.

I haven't narrowed down the reasons why, since it is easy to just install the old IMF for real, then go right back into Add/Remove Programs and remove IMF for good. That seems to make the SP2 setup installer happy.

Very strange. I'm sure someone somewhere knows why, and if I had time, I'd run the setup program thru regmon to see which keys it is querying.

http://www.microsoft.com/windowsmobile/downloads/activesync41.mspx

Hopefully, this version works with Windows Mobile 2005 on Axim X50v devices. I could never get 4.0 to work properly.

I understand the reasoning, but I'm curious how it is going to pan out for organizations that are typically cheap on hardware. I love pushing 64-bit in general, so it is a good idea, but I'm curious if a lot of places are going to stick with Exchange 2003.

I guess we'll see how saturated the market is with 64-bit servers by the time Exchange 12 ships.
It seems like at least having the 32-bit version available would be a good idea.

The more I look at that title, the more I get worried I'm going to get viagra spam.

Anyway, it looks like the WM5 upgrade wasn't quite ready when it was put out. Lots of people are going back to 2003, but for now I'm just going to wait for the update, due Nov 18th.

At least, they do tonite for some reason... even though they are designed to work together.
Recently upgraded my PDA from Windows Pocket 2003 SE to Windows Mobile 5.0 aka Windows CE 2005...

Used to be able to download e-mail, not anymore!

No siiir... I've completely wiped the ROM/RAM, reset everything, redownloaded certificates, tried the back end server, the front end server, tried it unencrypted.. can't get the thing to sync... in the cradle, over wifi, over bluetooth.. nothing. I know WM5 has restrictions when it is outside of the cradle, I don't care, as long as it works in the cradle.

It's a Dell Axim X50v if anyone is curious. I don't want to go back to 2003SE, because that means I've admitted defeat.

[edit a few days later: Looks like a lot of people are having the same problems]

This is going on my roaming 'network nomad' CD that I carry with me:

[snip]

Microsoft Exchange Server Disaster Recovery Analyzer Tool v1.0
The Exchange Server Disaster Recovery Analyzer programmatically collects configuration data and header information from databases and transaction log files. The tool analyzes all headers and creates a detailed list of instructions explaining what the problem is, and how to resolve it.


http://www.microsoft.com/downloads/details.aspx?FamilyID=c86fa454-416c-4751-bd0e-5d945b8c107b&DisplayLang=en

[/snip]