All Exchange 2013 Servers become unusable with permissions errors


The title might sound a bit scary but this one was actually a pretty easy fix. It’s a lesson in not digging yourself into a deeper hole than you’re already in during troubleshooting. I wish I would’ve had this lesson 10yrs ago 🙂


The customer was unable to login to OWA, EAC, or Exchange Management Shell on any Exchange 2013 SP1 server in their environment. The errors varied quite a bit, when logging into OWA they would get:

“Something went wrong…

A mailbox could not be found for NT AUTHORITY\SYSTEM.”

When trying to open EMS you would receive a wall of red text which would essentially be complaining about receiving a 500 internal server error from IIS.

In the Application logs I would see an MsExchange BackEndRehydration Event ID 3002 error stating that “NT AUTHORITY\SYSTEM does not have token serialization permission”.

Something definitely seemed to be wrong with Active Directory as this was occurring on all 3 of the customers Exchange 2013 servers; one of which was a DC (more on that later).


So one of the 1st questions I like to ask of customers is “when was the last time this was working?” After a bit of investigation I was able to find out that the customer had recently been trying unsuccessfully to create a DAG from his 3 Exchange 2013 SP1 servers. They could get two of the nodes to join but the 3rd would not (the one that was also a DC). The customer thought it was a permissions issue so they had been “making some changes in AD” to try to resolve them. I asked if those changes were documented; the silence was my answer….. 🙂

However, this current issue was affecting all Exchange 2013 servers & not just the one that’s also a DC so I was a bit perplexed as to what could’ve caused this.

So a bit of time on Bing searching for Token Serialization errors brought me to MS KB2898571. The KB stated that if the Exchange Server computer account was a member of a restricted group then Token Serialization Permissions would be set to Deny for it. These Restricted Groups are:

  • Domain Admins
  • Schema Admins
  • Enterprise Admins
  • Organization Management

The KB mentioned running gpresult /scope computer /r on the Exchange servers to see if they were showing as members of any of the restricted groups (see article for further detail & screenshots of the commands). I ran this command on all 3 Exchange 2013 servers & it showed their Computer accounts were all members of the Domain Admins group. In Active Directory Users & Computers I looked at each Exchange Server Computer account (on the Member Of tab) & unfortunately there were no direct ACL assignments so I had to search the membership chain of each common group that the servers were members of. The common groups that all Exchange Server Computer accounts were members of were:

  • Domain Computers
  • Exchange Install Domain Servers
  • Exchange Servers
  • Exchange Trusted Subsystem
  • Managed Availability Servers

Eventually I found that the Exchange Install Domain Servers group had been added as a member of the Domain Admins group during the customers troubleshooting efforts to get all their servers added as DAG members. I removed the Exchange Install Domain Servers group as a member of the Domain Admins group & then rebooted all of the Exchange servers. After the reboots the issues went away & the customer was able to access OWA/EMS.

Now this is where I had to explain to the customer that it was not supported to have an Exchange Server that was also a Domain Controller as a member of a Failover Cluster/DAG. This was why they were having such a hard time adding their Exchange server/DC as a member of their DAG.


I have a saying that I came up with called “troubleblasting”. i.e. “John doesn’t troubleshoot, he troubleblasts!” It started out as just a cheesy joke amongst colleagues back in college but I’ve started to realize just how dangerous it can be. It’s that state you can sometimes get into when you’re desperate, past the point of documenting anything you’re doing out of frustration, & just throwing anything you can up against the wall to see what sticks & resolves your issue. Sometimes it can work out for you but sometimes it can leave you in a state where you’re worse off than when you started. Let this be a lesson to take a breath, re-state what you’re trying to accomplish, & if what you’re doing is really the right thing given the situation. In this case, an environment was brought to its knees because a bit of pre-reading on supportability was not done beforehand & a permission change adversely affected all Exchange 2013 servers.

If you can make it to Exchange Connections in Las Vegas this September, I’ll be presenting a session on “Advanced troubleshooting procedures & tools for Exchange 2013”. Hopefully I can share some tips/tools from the field that have proven useful & can keep you from resorting to the “Troubleblasting Cannon of Desperation” 🙂


14 thoughts on “All Exchange 2013 Servers become unusable with permissions errors

    • Yep. I’ve even seen customers attempt to build/design their own “SBS 2013” servers. One box with AD/Exch2013/SharePoint2013/Lync2013 on it & fail miserably.

  1. Pingback: Interesting things that i see on the internet, 30th May. | 503 5.0.0 polite people say HELO

  2. Pingback: Weekly IT Newsletter – May 26-30, 2014 | Just a Lync Guy

  3. Pingback: NeWay Technologies – Weekly Newsletter #97 – May 30, 2014 | NeWay

  4. Wow! At last, I have found the solution! Thank you so much!

    I had struggled with this issue for a week after I updated from CU5 to CU6. I added the Exchange Server computer account to “Schema Admins” and “Organization Management” to run PowerShell script with LOCAL SYSTEM account.

    I was blind, but now I see.

    Again, thank you very much!

  5. Just found this. Saved our bacon this morning. I watched in horror as my 3500 user exchange environment went to heck in a handbasket this morning because I had added the three cas servers to Org Management a month ago to finish out a Cisco VOIP build needing access to certain cas features. I intended to remove them but forgot. Fast forward one month, and the Cas servers resync their AD accounts and all hell breaks loose. If it hadn’t been for this article I would have been on the phone with Microsoft for a while. Thanks much for this.

  6. I realize this post is 3 years old, but it was a great find and I wanted to thank you for posting it.

    I had a situation while building out an Exchange 2016 environment in our lab forest/domain. EMS was throwing an error that the user (computer account) wasn’t assigned to any management roles, so I threw the three servers into the Org Management AD group for troubleshooting purposes, then forgot to remove them after discovering and resolving the real root cause. Fortunately, I did document my changes along the way, so when I Googled the error and hit this page, I knew immediately which change broke things 🙂

    In case anyone cares, my misleading permissions error was actually the “PowerShell (Exchange Back End)” IIS virtual directory not having gotten set up correctly during Exchange 2016 installation on one of the three servers (naturally the one I was attempting to configure from). The folder was present in IIS, but it wasn’t configured as an application associated with an AppPool. Fix was to right click > convert to application > associate with powershell app pool > OK, then manually configure auth settings (enable Windows Auth, disable Anon), then IISRESET.

  7. I know this is an old post, but it saved my bacon tonight. I had added our exchange servers security group to the organization management group while troubleshooting an issue and forgot to remove it. For the life of me I couldn’t figure out what broke it.

    Thank you so much!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s