As you may already know, I’ve been struggling with a bug in an environment running Exchange Server 2003 and Windows Server 2003 with SP1. The bug is manifested as an error that appears when users with the properly delegated permissions attempt to add or modify an e-mail address on an already mail-enabled or mailbox-enabled object. The error, listed as error ID c10308a2, contains text along the lines of being unable to determine if the Microsoft Exchange System Attendant service is running.
The underlying issue is a change that Windows Server 2003 SP1 makes to the security descriptors applied to the Service Control Manager. This change in security descriptors now makes it impossible for non-administrators to query service status; hence, the error message.
In trying to apply the fix suggested by Microsoft in KB905809 (the use of the SC.EXE command), the error was never resolved. It turns out that the workstation I was using the test environment was configured not to use the primary DNS suffix, but instead use a predetermined DNS suffix search list. This configuration resulted in the system’s AD domain name not being in the suffix search list. As a result, even though the fix from Microsoft was applied, errors still occurred.
This morning I double-checked everything on the test servers as well as the test workstations, corrected the problem described above, and reset the environment to match the production environment. Then, walking through the tests again, I confirmed that running the SC command to add permissions to the Authenticated Users group (see the KB article linked above for more details, then see this explanation of SDDL syntax) does indeed resolve the issue.
So, finally, we can put this issue to rest. If you are running Exchange Server 2003 with Windows Server 2003 SP1 and finding that your non-administrative users can’t add or modify e-mail addresses using Active Directory Users & Computers, see KB905809 and run the SC command listed in there.
Tags: ActiveDirectory, Exchange, Windows
-
well, you are right… adding on to that note, i would like to mention the following:
How to verify if this is applicable to you or not:==================================
The problem was caused because once SP1 is applied, access to the service control manager is restricted as follows:C:\>sc sdshow scmanager
This is SP1 info
==============
D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)This is the RTM info:
================
D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)Solution to the above problem
=======================
- SC.EXE sdset scmanager D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)In case you run the command with a space, you are screwed up. you end up removing all the permissions for SCMANAGER. here is what you can do to fix it:
—–SOLUTION FOR “ACCESS IS DENIED” AFTER RUNNING SC.EXE—–
- Dont panic. delete the key with the name “security” from following Registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\Security
- Restart the server.
- Now run the sc.exe command originally meant for the problem WAY above WITHOUT the SPACES.Thank you!
Rajshekhar Murthy
Microsoft – India. -
Rajshekhar,
Thanks for the confirmation. I had a fellow administrator mess up the SC.EXE command, and luckily we discovered the Registry key fix as well (see http://blog.scottlowe.org/2005/10/08/just-in-case/ for more information). It’s good to see that confirmed as well.
Keep the feedback coming!
-
Hey,
The link to the Registry hack seems to have changed, do you still have the hack to correct the sc.exe permissions?
thanks
-
Khanand,
No, sorry. I tried searching for it again and couldn’t locate it. The SC.EXE command works reliably (assuming you don’t mess up the syntax), so I’d go that route.
Scott
-
Hi,
I tried to find out how to apply this solution in a clustered environment with no luck. Do you have any clue? MS want me to pay to have this information
Thanks!
-
Dany,
You should be able to just run this command on each of the cluster nodes and be good to go. I believe that this problem originated in a cluster environment and that was all we had to do to implement the solution.
Scott
Comments are now closed.
Site Sponsors
6 comments