No doubt many of you are familiar with the event commonly seen in application logs of Exchange 2000 and 2003 servers, MSExchangeIS event 9548, indicating that the information store came across a disabled user who is missing the msExchMasterAccountSid attribute while processing some various task. There are many KB articles associated with this event, such as 291151, 326990, 278966, 328880, 316047, and possibly more. There have also been countless support cases where this design was at least a contributing factor. Almost every application log from an Exchange 2000 or 2003 server ever seen has likely been littered with 9548 events, to the point where it has become an annoyance event. For additional information on the event and the related information, I suggest reading this article: http://www.msexchange.org/articles/NoMAS-Tool.html.
A CDCR (Critical Design Change Request) was accepted last year to resolve the issue without having to run tools or scripts, and the first version of this fix was released last week. The KB article is 903158.
The problem was that a decision was made during the development of Exchange 2000 that every disabled user account with a mailbox had to have the msExchMasterAccountSid attribute. This is because in order for a mailbox to function within the store, a SID must be associated with the mailbox. The logic worked like this:
1. If the user account associated with the mailbox is disabled, and has msExchMasterAccountSid, AND msExchMasterAccountSid is not the well-known SELF SID, then msExchMasterAccountSid is the SID that is associated with the mailbox.
2. If the user account is enabled, or if it is disabled and has msExchMasterAccountSid set to the well-known SELF SID, then use objectSid.
3. If the user account is disabled, and has no msExchMasterAccountSid, OR if we cannot tell if the user is enabled or disabled due to access control on the user object, or if we cannot read the objectSid due to access control, fail the operation and log the 9548 event.
In the 3rd case, the vast majority of the 9548 events came from the first part - that is, almost all 9548 events are due to disabled user accounts which are missing msExchMasterAccountSid. The new logic works as follows:
1. If the user account associated with the mailbox is disabled, and has msExchMasterAccountSid, AND msExchMasterAccountSid is not the well-known SELF SID, then msExchMasterAccountSid is the SID that is associated with the mailbox. (NOTE: No change here)
2. If the user account is enabled, or if it is disabled and has msExchMasterAccountSid set to the well-known SELF SID, OR if the user is disabled has does not have msExchMasterAccountSid, then use objectSid. (Big change here)
3. If we cannot tell if the user account is enabled or disabled due to access control on the user object, or if we cannot read the objectSid due to access control, fail the operation and log the 9548 event.
So now, the only way you will get the 9548 event is due to a real problem with the user account associated with a mailbox.
