I work for a company who’s network and server environment represent a fairly common scenario in the corporate IT world. They had moved to Active Directory and Exchange about a decade ago and continued to upgrade and grow based off of a general configuration or structure that had been established when those services (AD, Exchange, etc.) were first set up.
Over time, various administrators made changes to these systems to accommodate new services, programs, and initiatives. These changes, being completely necessary and reasonable caused the IT infrastructure to grow and change in a somewhat organic fashion. When I use the word organic in this case, I mean it in the sense that servers and the network were configured around the changing needs of the company, bit by bit. Consequently, I occasionally run into quirks or issues like the one I’ll be discussing below. I like to think these quirks give the infrastructure character. It keeps me on my toes.
I was changing an Exchange user’s mailbox properties the other day to remove a quota that had been set. When I clicked the OK button to apply the new settings to the mailbox, I received the following error:
After some moderate googling, I came across some blog and support forum posts by others who had encountered this error. The general consensus was to check the user’s AD security settings to ensure that the “Exchange Enterprise Servers” group had appropriate permissions. Permissions could be fixed by ensuring that inheritance was applied to the user.
I confirmed that the user object had inheritance enabled but I was still unable to apply the changes to the mailbox. I had gone back to skimming the blogs again when I noticed a suggestion in a post to check the inheritance settings for the OU that the user account was in. It turns out that the OU’s inheritance setting had been disabled.
The story goes as follows:
At some point before we had upgraded to Exchange 2010, we had delegated some permissions for the Help Desk so that they could reset user’s passwords. There were some users, people in Accounting, HR, and Executives who’s passwords we felt the Help Desk should not be able to reset. The delegated permissions had been set on an OU that the user’s department OUs were sub-OUs of. In the above example, the North America OU would be where the delegated permissions for the Help Desk had been set. The sub-OU’s (Executives, Marketing, IT, Etc.) would inherit those permissions unless inheritance was disabled in their security settings.
In the end, I concluded that disabling inheritance to the affected user’s OU, prevented the application of new permissions to that user’s account that would have been set when we updated to Exchange 2010. To resolve the issue, I had to go ahead and re-enable inheritance on the department OU of the user who’s mailbox quota I couldn’t change. This caused the necessary permissions which had changed or been added with the upgrade to Exchange 2010, to be applied to the user’s account.
I still wanted to prevent the Help Desk from being able to reset the user’s passwords, so I disabled inheritance on the OU in question and manually removed the permissions that I didn’t want applied to the users. I think that the delegation of rights to the Help Desk maybe should have been applied differently but that’s the moral of this story: The reality of IT is that very rarely if ever, is any configuration ideal for all uses and situations. Tread carefully, it’s a jungle out there.Further reading: Technet