NoMas Tool

The NoMAS Tool

Abstract

Microsoft Product Support Services (PSS) can provide you with a useful tool called NoMAS. In this article I want to cover what the NoMAS tool is and under what circumstances you might want to use it.
Note: This article is published with permission from www.msexchange.org

What Is NoMAS?

Well, I guess those Exchange professionals who are also boxing fans may argue that ‘no mas’ were the words Roberto Duran allegedly said as he quit in the eighth round of his rematch with Sugar Ray Leonard. However, in this context NoMAS stands for no master account SID and is the name given to a tool that you can obtain from Microsoft to help with problems relating to the master account SID attribute (msExchMasterAccountSid). There seems to have been an increase lately in the number of people enquiring about this tool on the various Exchange newsgroups and mailing lists. Before I talk further about the NoMAS tool, it’s important to understand what is meant by msExchMasterAccountSid and why there might be problems with it.

The 9548 Event Log Entry

Perhaps the most common way in which you’ll get to know about msExchMasterAccountSid is when you examine the application event log on your Exchange server and notice warning event log entries with an event ID of 9548:

The event ID of 9548 shown above is self explanatory in that it tells you that the disabled user neilh doesn’t have the msExchMasterAccountSid attribute set. I created this event log entry simply by disabling my Windows user account and then adding it as a delegate via Outlook to another mailbox. However, I didn’t take any further steps to enable the msExchMasterAccountSid attribute, hence the warning. So exactly what is this msExchMasterAccountSid attribute?
When granting permissions in Exchange 2000 or Exchange 2003 Access Control Lists (ACLs), such as public folder ACLs, there are two possibilities for permissions calculation depending on whether the Active Directory account that is being granted permissions is enabled or disabled. If the account is enabled, the permissions are calculated by using the objectSID or sIDHistory attributes. If, however, the account is disabled, the permissions are calculated by using the msExchMasterAccountSid attribute. It therefore follows that enabled accounts should never have the msExchMasterAccountSid attribute set and conversely, disabled accounts should have it set. In the warning above, the Exchange store cannot determine the correct SID for the user account since it was expecting to find the msExchMasterAccountSid for the disabled user, but this hasn’t been set as I’ve explained.
One of the best ways to understand how msExchMasterAccountSid is used is to describe what happens during an Exchange 5.5 to Exchange 2003 migration. In such a migration scenario, the Active Directory Connector (ADC) is used to synchronize the Exchange 5.5 directory with Active Directory. If the ADC cannot find an Active Directory user with a SID that matches the SID of the Exchange 5.5 mailbox Primary NT Account, it creates a disabled Windows account and sets the msExchMasterAccountSid attribute with the SID of the Exchange 5.5 mailbox Primary NT Account. The result is a disabled Windows Active Directory account whose SID is essentially the Windows NT4 domain user, which therefore means that the Windows NT4 user can access the Exchange 2000 or Exchange 2003 mailbox.
Additionally, the ADC will also set the Read, Full Mailbox Access and Associated External Account rights for the account whose SID has been set in the msExchMasterAccountSid attribute. The important points to note here are that the account that has been set with the Associated External Account right must have its SID stored in the msExchMasterAccountSid attribute and that there can only be one account listed with the Associated External Account right. One additional thing that you may have noticed is when the SELF account has been assigned the Associated External Account right. This is most typically seen when the ADC synchronizes resource mailboxes into the Active Directory as disabled Windows accounts. Setting the SELF account with the Associated External Account right means that the resource mailbox is available to those who have permissions to access it.
That’s how things should work normally so how do things change causing the generation of event 9548? Well, consider the scenario where someone leaves your organization and your helpdesk disables their mailbox-enabled Windows account. You’ll be in a position where you have disabled users without the msExchMasterAccountSid attribute set. Alternatively, if your helpdesk does indeed correctly set the msExchMasterAccountSid attribute, what happens if the user returns and the helpdesk re-enables their account? Will they remember the msExchMasterAccountSid attribute? It’s not difficult to see how we get into these situations and having such problems may prevent users from accessing desired resources. Certainly there are many event logs that I’ve examined recently that have their fair share of event 9548s being logged. It’s also interesting to note that the setting of the msExchMasterAccountSid attribute is not enforced by things like the Active Directory Users and Computers snap-in.
Finally, on the ‘problem’ side of things, it’s worth noting that if you disable a mailbox-enabled Windows user account and do not set the msExchMasterAccountSid attribute, that mailbox will no longer be able to receive new messages since Exchange will not be able to determine that user’s correct SID. Therefore, all new messages sent to that account will receive a non-delivery report unless you take action.

The Fix

OK, enough of the gloom and doom. Fixing the problem is very easy and I’ve basically covered the solution already. If you disable a mailbox-enabled Windows account, all that needs to be done is to grant the SELF account Associated External Account and Full Mailbox Access permissions to the mailbox. This is done via Active Directory Users and Computers, where you navigate to the affected user account, bring up the properties, click the Exchange Advanced tab and then click the Mailbox Rights button. This is fully documented in the Microsoft knowledgebase article 278966


Now, for one or two accounts, that’s no big issue. But what if you find that you have many accounts that need fixing? Or, more importantly, how can you reliably search for problematic accounts? Well, the Microsoft knowledgebase article I’ve mentioned above does have a useful method for searching for affected accounts via LDIFDE. However, there is a better solution and this is where the NoMAS tool comes in.

Using NoMAS

To make bulk changes to fix these issues, you can use the NoMAS tool. This is a tool written by Alex Siegler of Microsoft, although Alex says that it is now owned and maintained by Dave Goldman. To get your hands on a copy of the NoMAS tool, you’ll need to contact Microsoft Product Support Services (PSS). For this article, the version of the NoMAS tool that I am using is 2.2004.05.03; you may want to check to see if a newer version is available. The tool itself is a single executable file called nomas.exe which I have simply copied to my Exchange server into the c:’program files’exchsrvr’bin folder, although you can place it where you like. Running the tool gives you the simple screen:

Note that, by default, the log file is set automatically to nomas.log in the same folder as you placed nomas.exe. You then need to choose your domain and container to work in via the Browse… buttons on the right-hand side; you’ll see from Figure 3 below that I’m going to be performing a check on the Users container. Also on the main screen are two options: Mode selection and User selection. In my test, you can see that I am going to be performing the Check mode against Disabled users.

One thing that I did notice was that the Start button is unavailable until you select an option from the User selection area. If you then neglect to configure the relevant domain field and click Start, you’ll be presented with an error informing you that you must choose a domain. You must also choose a valid log file too. However, the same constraints do not apply to the container field as you can leave this blank if you wish to. If you do leave the container field blank, NoMAS searches the entire domain.
Let’s examine what the different modes do.

The Modes

With the check mode that I’ve selected, NoMAS simply queries Active Directory for enabled users that have the msExchMasterAccountSid attribute set, disabled users that don’t have the msExchMasterAccountSid attribute set, or both, depending on the selections you make within the User selection area. No changes are made to Active Directory, since this is just a check mode. Whilst the check is being performed, NoMAS will keep you informed of progress:

Once NoMAS has finished, a log file is created as dictated by the Log File setting shown above in Figure 3. The resulting log file is shown below. Note that the line containing the phrase ‘is missing msExchMasterAccountSid’ has been manually split for readability.

You can clearly see from the resulting log file that we have a disabled user missing the msExchMasterAccountSid attribute. If we now run the same query in Fix mode, then NoMAS performs the same query operation but this time actually goes ahead and sets the SELF account with the Associated External Account right. After running the operation in Fix mode, the resulting log file is shown below:

We can confirm that NoMAS has worked correctly by now bringing up the Mailbox Rights screen for the affected user. The result, shown below, is that the SELF account does indeed now have the correct rights set.

The Resynchronize mode is interesting in that it queries all mailbox-enabled user accounts and synchronizes Associated External Account and msExchMasterAccountSid, since they must always be synchronized. Then, the Fix mode is automatically run with both enabled and disabled users selected to ensure that all accounts are now correctly configured.

Do It For Performance

Whilst it can be annoying to have many 9548 event log entries written to your application event log, there is another reason why you should use NoMAS to resolve any msExchMasterAccountSid issues. According to Microsoft PSS, there have been cases on larger servers where performance has suffered on Exchange servers that are logging many 9548 event log entries. This is because Information Store threads can hang and go through a timeout when checking ACLs that contain disabled user accounts that don’t have the msExchMasterAccountSid attribute set.

Summary

NoMAS is a really simple tool to fix the issues you’ll be made aware of when you see event 9548 logged in the application event log on your Exchange servers. Check your logs for evidence of the 9548 event log entry and if you find some, consider getting your copy of the NoMAS tool to fix them. It’s worth doing; I have seen quite a few Microsoft Operations Manager (MOM) deployments raise alerts that show event 9548 is being generated excessively.
Neil is a Principal Consultant with Silversands, a UK-based Microsoft Gold Partner and is responsible for solution design, implementation and support for major clients across Europe. He has been in the IT industry since 1987 and has specialized in messaging since 1995, having worked with Exchange since v4.0 days. He is also an Exchange MVP and spends some of his spare time helping others in various Exchange mailing lists, the public Exchange newsgroups and also contributes to the MSExchange Blog over at http://www.msexchangeblog.com
Note: This article is published with permission from www.msexchange.org