The Kerberos Contraint Delegation fix and a 8197 Event for MSExchangeFBPublish

This is a blog entry for Exchange 2003, which is meanwhile in Extended Support (which means, that we will deliver non-security Hotfixes only to customers with a custom support agreement. In December 2006 we released a Hotfix for OWA Smart Card Authentication in Exchange 2003 over Exchange 2003 Front End Servers and ISA Server. It uses Kerberos Contrained Delegation ((also called KCD) and reuses mixed Mode AD properties in the Configuration Container of the AD, mainly the attributes msExchLegacyAccount, msExchLegacyDomain and msExchLegacyPW. In a mixed mode Exchange 5.5 / Exchange 200x environment these attributes contain all the relevant details for the Exchange Service Account, which was needed for an Exchange 5.5 site. Ca. mid 2007 a large customer of us had a CritSit, after he deployed this Hotfix for Smartcard Authentication concerning Exchange ActiveSync. (A CritSit is a Severity "A" Situation for our Premier customers, where we offer some special support steps like rapid Onsite, Escalation Services Support and special management awareness).  Not immediately after the KCD Hotfix, but after a while and users started complaining, that booking resources was giving errors. When end users looked up the Free/Busy of the resources - it looked like, that they were free, but after they invited them, they got a message, that the resources were already booked. What was wrong?  As we found out after a while, the problem was with his implementation of the Auto Accept Agent and our implementation of the Smartcard Auth for OWA fix. The Auto Accept Agent, like OWA, registers its Free/Busy times (which is an entry in public system folder, namely the Free/Busy Folder over a component which is called madfb and logs events under the name of MSEXchangeFBPublish. MADFB logged 8197 Events. The community links this event normally to the following: https://www.eventid.net/display.asp?eventid=8197&eventno=840&source=MSExchangeFBPublish&phase=1. Well, as we understood in that CritSit, it can also be due to Hotfix KB 920209. Why? Well the MADFB runs under the Account of the local Server, until.... yes, until it finds an msExchLegacyAccount. If there is one, than it uses this account to log onto the System Attendant mailbox (the SA mailbox) to push and calculate the Free/busy entry there after it than goes out to the Public store, where the relevant Free/Busy Folder is located. If the account does not have permissions to the SA mailbox or to the pub store, we cannot publish Free/Busy. So the calendar entry for the resource or user mailbox is there, but the Free/Busy entry is wrong, stays with the old information. If meanwhile any Outlook version comes along and logs on to the mailbox, than the Free/Busy entry gets updated via the Outlook mechanism (which has a Sniffer for calendar entries and a local (hidden) Free/Busy Folder, which it synchronizes regularly every 15 Minutes with the Free/Busy public folder. So the Outlook process for Free/Busy Publishing in Exchange 2003 is different from the OWA or AAA or any other custom Free/Busy publishing mechanism, which also uses the MADFB process. Outlook Free/Busy Publishing can fix the broken OWA or AAA Free/Busy publishing. But for resource mailboxes the following is true - probably nobody logs on via Outlook and the Free/Busy entries can get stale in that situation.
Why the Hotfix KB 920209 once more populates the msExchLegacyAccount and the other 2 attributes. Well - it is the so called KCD service account, which you need to enter into the OWA FE configuration after you install the Hotfix. But what is the KCD service Account for. Our KB article does not explain this, so let me do it here. This account is not the account which is used for constrained delegation - it is the account which looks up the environment periodically, if there are other new Front End Servers, which are also to be enabled for Kerberos Constraint Delegation and moreover - for the sheer enabling of the Constraint delegation you need an account under which that is done. So in the fix process the colleagues, who wrote the Hotfix, decided to reutilize these 3 attributes.
How you can fix the situation with the installed Hotfix and the need to publish Free/Busy over the madfb process?
You have 2 methods:
1) Clean out the msExchLegacyAccount and the other attributes, after you have enabled the delegation. Delegation will continue to work after that, because in the process of following the instructions of Hotfix KB 920209 you already enabled Kerberos Contrained Delegation. What is really used in the daily Process of Constrained delegation are the Service Principal Names associated with the relevant computer accounts. The process of cleaning that attribute is described under the exbpa article for the msExchLegacyAccount. As a side note; the statement in the exbpa article: "This attribute is only used in mixed mode Exchange organizations where Exchange Server 5.5 is still present." is not completely correct. With the setup of the Hotfix KB 920209 we also can get a msExchLegacyAccount in a native Mode Administrative Group.
2) The second approach would be to give the KCD service account appropriate permissions to the SA mailboxes and the public stores with the Free/Busy Folder. In that situation Free/Busy Publishing would also succeed and so you can leave that KCD account in that attribute.
Another side note: Sometimes the password of that KCD Service Account can expire or was reset or whatever - and nobody changes it via the Interface from the Hotfix. Well - than you also will get 8197 events and all the follow-up.
Why I wrote this? Last week we had another customer with 8197 events and Hotfix KB 920209. A colleague of mine digged out my dealing with that 2007 CritSit, where I had opened an internal request for collaboration and we even had thought about another Hotfix (which would have changed the behavior of the MADFB process - why after all it still uses the msExchLegacyAccount in a native Admin Group). But the Hotfix proposal was never written, because no Hotfix was requested and I missed to engage someone to update at least the KB article for Hotfix KB 920209.  Sorry for that. So this blog post shall be an amendment for KB 920209 and for the exbpa article concerning the msExchLegacyAccount