Article ID: 18280
Product: GMM Exchange
Date: 8 July 2008

Title: "Send As" Permissions Issue Overview

Due to changes made in recent years to Windows Server, Exchange and AD, Microsoft has deemed specific built-in groups as being "protected".

What does this mean?

It means that if you belong to one of these protected groups, you run the risk of having your permissions stripped out after applying additional service packs, hotfixes, or even just rebooting Exchange. There doesn't appear to be any real identifiable logic as to when the permissions will be removed, but as long as you're a member of those groups (i.e. Domain Admins), it's definitely going to happen sooner or later.

There is unfortunately no real workaround to combat this issue other than ensuring that permissions are set for GoodAdmin and are replicating down to the user level, as well as removing users (up to and including GoodAdmin) from these protected groups.

We will now take a look at a brief checklist of things to look for when you are working on the Send As issue. We will also cover the procedures for confirming that a user is indeed affected by this issue.

Verifying that a user is paused due to "Send As":
If you suspect that a user is experiencing this issue, but would like a definitive answer, there are a couple of things you can look for that will help clarify the cause. First, you can locate the user in the Good Management Console, right-click their name and go to Properties. Once there, click on the Sync Details tab. If the pause value is "yes" and the reason listed is "Exchange Not Accessible", it is almost guaranteed to be the Send As issue. The reason you see the "Exchange Not Accessible" is because the user lacks sufficient rights to access the mailbox and/or have the GoodAdmin send on their behalf.

You can also use ADSI Edit (one of Windows Server Support Tools) to confirm the issue, and this is generally a bit more reliable. If there is any lingering doubt as to whether or not a user is affected by Send As, this is the method you can use to obtain proof one way or another. Simply launch ADSI Edit, then navigate through your OU structures to locate the user in question. Once you've found them, right-click and go to Properties. Here, you'll see a list of attributes. There is only one that matters in these cases, though, and that is "AdminCount". If the value for this attribute is "1" or greater, then you have absolute proof that the user belongs to one or more protected groups. ADSI Edit will not lie to you, and should reflect real-time values, so this can be a tremendously helpful diagnostic tool for Send As.


Troubleshooting Checklist

GoodAdmin Permissions and Rights Replication:
First, you will want to confirm GoodAdmin's permissions and group membership. In Active Directory Users and Computers (ADUC), locate the GoodAdmin's account. Make sure that Advanced Features are enabled (View > Advanced Features). Right-click the GoodAdmin account, then go to Properties. You want to first visit the Security tab. In the list of users and groups, you should see GoodAdmin listed. If you do not, go ahead and add it using the GAL lookup. The default set of permissions are normally fine, with two exceptions; There should be ZERO permissions set to deny, and Send As must be checked in the "Allow" column. Once you've confirmed that this is done, you will want to click on the "Advanced" button. There is only one thing we really need to worry about here, and that is the checkbox for "Allow inheritable permissions from the parent to propogate to this object and all child objects. Include these with entries explicitly defined here." In order for GoodAdmin's permissions to properly reach the end user's mailbox, this option must be enabled. Concurrently, you'll want to verify the GoodAdmin does not belong to any protected groups. Click on the Member Of tab, and ensure that none of the protected groups are listed there. If you do see any, you will need to remove them in order for mail delivery to resume. Remember, the GoodAdmin service account should ONLY belong to Domain Users, with its permissions explicitly granted from there as per the Administrator's Guide (https://good.com/download). Go ahead and apply the changes, then wait for replication to complete (on average, 30 to 90 minutes).

User-level Permissions and Group Membership:
After we've ruled out the GoodAdmin as being the source of the user becoming paused, we need to look at that user specifically. After using one of the aforementioned methods of confirming Send As, you will want to launch ADUC and more or less repeat the steps listed above. First, make sure that GoodAdmin is listed in the users and groups on the Security tab, that no permissions are set to deny for GoodAdmin, and that Send As is enabled. After this is done, the next part is going to be critical. Click on the Member Of tab. Again, we want to ensure that no protected groups are listed there. In order for the issue to be permanently resolved, those groups would absolutely have to be removed. Otherwise, it will keep happening over and over and over again, ad nauseam. We will later discuss some options that may work in the event of a user needing special rights/permissions in the environment.

Nesting:
One of the most common (and also most overlooked) causes of the Send As is a result of "nesting". What this means is that the GoodAdmin service account or individual user may not belong to any protected groups directly, but their permissions are still being removed, resulting in the pause status. This is most often due to the user belonging to a custom group or distribution list (DL) that is nested within one or more protected groups. This is where things can become a bit more complicated, but it's important to rule this out. You can right-click the custom group or DL, go into Properties, and then to the Member Of tab. If you see any of the protected groups here (these are all listed below), they will need to be removed. Alternatively, you can also do this from the ground up, so to speak. Instead, you can also view the Properties of a protected group itself by checking the Members tab. This will tell you what individuals or groups are nested within them. This can sometimes be a painstaking and time-consuming process, but once it is corrected, you'll likely never have to worry about it again.

Tips for those who need specific rights and permissions:
Although Microsoft has deemed many of its built-in Exchange/AD groups as being "protected", there are still ways to obtain the rights you need without belonging to said groups. One of Microsoft's suggested workarounds (which is the preferred method) is to create a custom group-let's call it "IT Admins". That group can have ANY permissions or special access you want to give it. From there, it's simply a matter of making sure that the group's rights are replicating down to the users who belong to it. There are absolutely no restrictions on the permissions that a custom group can have, so this truly is the best option. The only thing to be aware of after creating these groups is to make sure they don't end up being nested within a protected group, as mentioned above.

Occasionally, you'll encounter someone who will not remove a user from these protected groups. Another alternative solution is to create a second mailbox for that user, setting group membership to Domain Users only. You can then have mail from the primary mailbox (protected group member) forwarded to the second mailbox. The second mailbox would be the one used to provision the handheld device. This would allow the user to send/receive normally without having to be afraid of losing their normal domain privileges.

Protected Groups:
Below are the "protected" built-in groups as mandated by Microsoft:

The following list contains the protected groups in Windows 2000:

The following list contains the protected groups in Microsoft Windows Server 2003 and in Windows 2000 after you apply hotfix 327825 or after you install Windows 2000 Service Pack 4 (SP4):

Additionally, the following users are considered protected:

Resources and Documentation:
Listed below are links to various articles outlining this issue, both on Good's public knowledge base as well as Microsoft's. These should provide some additional detail that may have been missed in this article.

http://good.com/faq/17540.html
http://good.com/faq/17773.html
http://good.com/faq/17772.html
http://good.com/faq/17771.html

http://support.microsoft.com/kb/907434/
http://support.microsoft.com/kb/912442
http://support.microsoft.com/kb/916803