exchMasterAccountSid bytes again, and again.

I have recently spent a considerable amount of time supporting one of our customers who for some reason was unable to perform MAPILOGONEx command via MFCMAPI. We were issuing the OPENSTORE_USE_ADMIN_PRIVILEGE OPENSTORE_TAKE_OWNERSHIP which translate to using Administrative Previleges.

After much speculation about lack of permissions, it turned out that customer's environment was at Exchange 2003 SP2 but did not have a fix for msExchMasterAccountSid issue. That same issue that even had msexchange.org guys write a tool, NoMas. Apparently, Information Store disallows the administrative permission resolution as well. NoMas can help a lot with the short-term workaround, while applying KB916783 ensures the correct behavior.

Now, I need to actually look at some of our apps and review their functionality under this scenario.

Changing focus of the blog a bit

Ok,
so I went quiet a bit just as I planned to blog more. The reason is simple. I have swapped jobs . Now, entrached in development as opposed to IT support, my focus is still with MS Exchange and Messaging. However, my day-to-day tasks are now involve looking deeper at AD integration with Exchange (various versions) and with time MAPI.

Getting Export-Mailbox Cmdlet to work

After installing Exchange 2007 SP1 Management Tools on Windows 2003 SP2 x86 and Outlook 2007 with SP1, the export-mailbox cmdlet was returning this error:

Export-Mailbox : Error was found for "Name" () because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221233

Running FixMapi.exe from the command prompt easily fixes the problem.

Entourage 2004/2008 caveat in Exchange 2007 environment

One thing that I found is a bit frustruating the lack of documentation regarding Entourage connectivity to Exchange mailboxes in co-existence scenario.

The first challenge actually happened a few weeks when our team has deployed Exchange 2007 CAS farm to replace our existing Exchange 2003 FE. We found that by default when deploying CAS role, it will enable legacy virtual directories to support OWA for exchange 2003 mailboxes but not WebDAV to support Entourage. Thus, our team had to set it manually via GUI or ADSI IIS provider in powershell. Big thanks to Nathan Winters and his article to elaborate on this.

The second challenge came when a mailbox was migrated to Exchange 2007 CMS. Entourage 2004/2008 started to display "Unexpected Error (170)". My initial research kept pointing me to KB947802, however that was not the problem as I verified that HTTP protocol settings exist in AD. The actual solution to the error message ended up KB931350. It appears Entourage users must now enter a fully qualified URL to their mailbox https://domain.com/exchange/user@domain.com. This does not look too apealing at all. It's time to change the user docs!

ActiveSync caveat in Exchange 2007 co-existence scenario

In Exchange 2003 FE/BE configuration, Active Sync default virtual directory authentication is set to basic. Admins have to rely to transport level security, such as IPSEC, to secure proxying credentials from frontends to backends.
By introducing CAS role as a replacement for FE, our group immediately ran into problems. The toughest problem was actually to set "Integrated Authentication" because ds2mb service will overwrite our attempt to set it in IIS snap-in. We found this KB, thanks to my co-worker, and that enabled us to set the correct authentication option.

Migration WorkShop: How do I set up Journaling?

I've only experimented with journaling in Exchange 2003, so I do not have too much experience with this. However, curiosity was killing me. In 2003 environment, journaling is enabled per mailbox store basis. The similar functionality is available in 2007 using standard Journaling:
Enable Journaling: Set-MailboxDatabase -JournalRecipient
Disable Journaling: Set-MailboxDatabase -JournalRecipient $Null

If you want to find out more about premium Journaling, which requires enterprise CALs, then waltz over here.

Migration WorkShop: Can Exchange Security Groups be moved to another OU or Domain?

As the Microsoft White Paper, here, points out that the Exchange Universal Groups (USG) are added to otherWellKnownObjects AD mutli-valued attribute. This means that AD will maintain the location of the groups, their distinguished name. Therefore, it should be safe to move the groups to another OU or even another domain.