I ran into this issue a week or two ago when launching he Exchange Management Console (ESM) for Exchange 2010. As a work-around, I would connect directly to an Exchange server and access ESM from there but given how regularly I do administration work in Exchange I got fed up with the constant logging in and finally fixed the issue.
I did some googling and found a blog that advised me to remove a specific registry entry.
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:
The error message is as follows:
“Error: Active Directory operation failed on emailserver.organization.com. This error is not retriable. Additional information: insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
The user has insufficient access rights. “
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.
I was involved in the process of migrating a company from Exchange 2007 to 2010. So far, it’s been smooth sailing with the exception of a small hiccup here and there. One of these hiccups, has to do with the new implementation of the RBAC security model in Exhcange 2010 and how that affects managers of distribution groups.
An organization may have hundreds of distribution groups set up in Exchange for various projects, management groups, initiatives, you name it. In a dynamic environment such as this, people are being added to and removed from distribution groups all the time. This is why Exchange admins appoint managers for distribution groups.
A distribution group manager is a regular user with the exception that they can add or remove people from the group that they manage. The manager usually makes changes to the group using the address book in Outlook. In previous versions of Exchange, when an administrator would appoint a user as a manager of a distribution group, all the administrator would have to do is open the Exchange Management Console, add the user as the manager, open Active Directory Users and Computers, open the distribution group properties and give the manager rights to modify the group.
I suppose that like most admins who had upgraded from earlier versions of Exchange, I was surprised when managers of various distribution groups started complaining that they were getting an error when they tried to add or remove people. Distribution group managers who were able to modify the group before the upgrade to Exchange 2010, were getting errors stating something to the effect of:
Turns out there may be a couple of different things going on here. First, the default permissions for Exchange don’t allow users to manage groups and must be changed. The Default Role Assignment Policy for users needs to be changed if you want your managers to be able to administer their distribution groups. To do this, log into your OWA server’s Exchange Control Panel and take the following steps:
Click on Roles and Auditing
Click on User Roles
Click on Default Role Assignment Policy
Click on Details
Put a check in the box next to MyDistributionGroups
Marvel at how easy that was. A little too easy…
There is one caveat: enabling this setting allows users to create, delete, and modify distribution groups resulting in… DISTRIBUTION GROUP ANARCHY! RUN FOR YOUR LIVES!!!
I think that for most organizations, this setting isn’t sufficient for their needs. To further button down these access settings, a custom role can be created using The Exchange Management Shell. Luckily for us, the sharp folks over at the Exchange Team Blog created a PowerShell script that restores sanity to your distribution group settings by giving managers back the ability to manage their distribution groups while keeping them from being able to make new groups or delete them.
Second, you may find that you can use the Exchange Management Console (EMC) to modify distribution group memberships but managers who need to use Outlook to administer their groups can’t. To make editing distribution groups work in Outlook, you may need to change each distribution group to be Mail Universal Distribution Groups as well. You can do this in the EMC by right-clicking on the distribution group in question and selecting the “Convert to Universal Group” option.
I recently ran into an interesting bug in Exchange 2007. I was creating a dynamic distribution list in the Exchange Management Shell. I set up a custom filter so that if a user’s AD account description had the word “common” in it, that user would be excluded from the distribution list.
When I tried to test the filter by viewing the filtered list of recipients using the Exchange Management Console or by using the Exchange Management Shell, I would be shown a list of the users that the filter had been applied to BUT that list would not be limited by the RecipientContainer that had been specified.
So I did some searching and asking around and was pointed to this guy’s blog. He found out that this is actually a bug in Exchange 2007! The dynamic distribution group and the filter work just fine. It’s Exchange 2007’s functionality to SHOW the correct list of users that the DL is applied to that’s wonky.
From time to time I find myself looking for an account that is associated with a specific email address. If the email address in question is an alias, a simple search in Exchange won’t turn up any results. Running a query in Active Directory Users and Computers can locate the information easily.
To run this query, take the following steps:
Open the Active Directory Users and Computers mmc.
Right-click on the domain and select the “Find” option.
Select the “Custom Search” option from the “Find:” drop down menu.
Click on the “Advanced” tab.
In the field under “Enter LDAP query:” type the following: “(proxyAddresses=smtp:firstname.lastname@example.org)”.
If you have installed Rollup 3 on your Exchange 2007 SP3 email server then you might experience the following: When Mac users who send emails with .tiff or .pdf attachments to Windows users, the Windows users won’t be able to view the attachments! Sometimes Windows users who receive the attachment laden email, won’t even see the telltale paperclip symbol on these emails. It is only when the email is viewed from OWA or another Mac client that it’s attachments are made apparent.
Even though the rollup was released in April, Microsoft still hasn’t released a publicly available patch for it. At this time, you’ve got three things that you can do to try and resolve this issue:
Call 1-800-microsoft and talk Microsoft support into giving you the hotfix
Entering the following command in power shell on your Exchange server has reportedly helped some people: set-OrganizationConfig -ShowInlineAttachments:$true
Anyone with an Exchange 2007 email account who recently upgraded from Office 2008 to 2011 on the Mac might find themselves unable to send emails with attachments that are over 10MB in size. While Entourage used WebDAV, Outlook 2011 uses Exchange Web Services (EWS) for email access. The default size limit for sending emails using EWS is 10MB. To fix this, you’ll need to edit a few files named “web.config” on the Exchange server, run a few commands and then reboot the sucker just because its a good time.
Here’s what you do:
On your Exchange server go to “C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews”
Make a copy the “web.config” file – just in case you break something.
Open up the “web.config” file in notepad or Notepad++ (if you’re badass)
Find the line with the following “httpRuntime maxRequestLength=”13280″”
Change the 13280 value to whatever you want. Note that this value is in KB.
Save and close the file
Next, you’ll want to repeat steps 1-6 with the “web.config” files in the “\ClientAccess\owa” and “\ClientAccess\sync” folders.
Open up the command prompt and enter “CD %windir%\system32\inetsrv”
Enter the following commands:
“appcmd set config “Default Web Site/ews” -section:requestFiltering -requestLimits.maxAllowedContentLength:#########”
“appcmd set config “Default Web Site/owa” -section:requestFiltering -requestLimits.maxAllowedContentLength:#########”
“appcmd set config “Default Web Site/Microsoft-Server-Activesync” -section:requestFiltering -requestLimits.maxAllowedContentLength:#########”
Note: Replace the # with the values you entered in in the web.config files but this time in bytes. If you entered 100000 in the web.config file, enter 100000000 for the value in the command line.
Enter the “iisreset” command
Take a moment to reflect on how awesome you are for winning.