Deployment Scanner reports Exchange Server permissions errors differently

OK, this sounds strange.

I'm sorry, but I would do a RECHECK again.

First thing: Write down any changes you make :)
Second thing: Try removing the Service Account from local Administrator on the Exchange Servers.

Further, test the following:

Begin with REMOVING the service account from delegation, on ORG level and on Administrative Group level:

Then enable the Security Page in ESM by modifying registry:

Important To change the security on an administrative group object, you must turn on the display of the Security tab in Exchange System Administrator. To do this, follow these steps:

1. Click Start, click Run, type regedit , and then click OK.
2. Locate and then click the following registry subkey:
   
   HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type ShowSecurityPage, and then press ENTER.
5. In the Edit DWORD Value dialog box, type 1 in the Value data box, and then click OK.
6. Quit Registry Editor.

Restart ESM.

(http://support.microsoft.com/kb/883381/en)

Then go trough all those Levels:

- Organization
- Administrative Group
- Exchange Servers
- Storage Groups
- Mailbox Stores

On every level, right click, and choose "Properties", and then choose the "Security" Tab.

On every Security Page, make sure that:

<EXCHANGE SERVER>\Administrators has no DENY set (Remember: DENY take precedence over ALLOW!, and the Service Account is Local Admin on the Exchange Servers!)
CHG\chgevservice has ALLOW everywhere and NO DENY

I'm sure you will find a deny somewhere....

Cheers
Michel

Check to make sure the VSA does not have a GPO assigned to it that might be causing the issue. Also open Outlook on the EV box with the VSA.

--Good luck.

This does indeed seem strange and we have gone through the points suggested and even have created a new service account and applied the permissions to that.

We have 22 exchange servers in a single forest, multi domain AD across the world. Server 2003 and Exchnage 2003 SP2

The deployment scanner check to verify the version of Exchange, etc passes on all sites.

It is the test for verifying Service Account permissons that fails on some sites.

The deployment scanner works quite happily against some exchange servers and not against others.

I do not beleive this an issue with exchange permissions because.

On the sites that fail when we run the deployment scanner the EV servers.  If we run the deployment scanner directly on those exchange servers the check for permissions passees!

On the sites that work if we have not configured permissions we get a deployment scanner fail that states that there are not the required permssions on the mailbox store and the public folder store.

On the sites that are failing the error states that either server permissions are not set or permissions cannot be read from Active Directory - a subtle difference that suggests the failure is at a higher level before it even gets to read from the information stores.

It appears to me that on the sites that fail it is a falure to read permissions full stop, not a recognition of incorrectly configured permissions.

As well as a straight forward answer to our problem and explanantion of what exactly the deployment scanner is looking for and where it would be looking in Active Directory would be helpful so that we can narrow our scope of where to look in AD.

We have compared ADSIEDIT records and permissions of AD SItes, Domains, Servers. Exchange Admin Groups, Servers, Information stores and can see no identifiable differences betwen where it works and where it fails.

Any help, advice, direction will be most aprreciated, think this one will nake a good knowledge base article when we resolve it!!!

Thanks Michel,
I think that I saw a small glimmer of the logic inside Deployment Scanner (and EV itself) regarding the permissions on the AD objects for the Exchange Server.

What you indicated was that the code may go down all of the way through the levels to the Exchange Storage Group (and maybe even the individual databases).
However, would it not be true that if there was a Security Permissions problem with the AD objects, then it would not be possible to run Exchange System Manager from the same security context as the Deployment Scanner (running on EV server under the EV service account)? This has previously been a very useful touchstone, if ESM didn't work, then EV wouldn't work - and visa versa.

But in this case ESM works, but EV doesn't work.

We may not have drilled down all of the way into the Exchange Database objects inside ESM - and it is possible that although we have set security correctly up at the Exchange Server level, complete with propagation down to lower objects, there may yet be a DENY on the objects lower down.

However, to repeat, the EV service account is NOT a member of any groups, except Authorised Users.

I have previously provided the output of ACLDIAG (from Windows support tools) with /geteffective which is a better way to authoritatively collect a text file with all of the permissions, and very carefully compared the contents between one Exchange server that passes, and another that fails - to not discover anything significant.

Simon is on site and can provide practical tests and experiments, and I am sure will look deeper into ESM to see if the Database objects can be accessed and let you know.

Thanks - once again, we are quite comfortable that this is most likely to be a problem with AD security, but we are just doing a Due Diligence exercise to make certain that this is not a bug in EV code (or an incomplete understanding of its logic) since three of us have quite extensively checked the AD permissions.

- SteveD

Michel

In fact that is the first test I did.

With the EV Service account in Outlook on the EV Server you can indeed send and recieve email as any user.

and as stated above if I run the deployment scanner directly on the Exchange server as the EV Service user the ev service account the permissions test is successful.  It is only accross the network that it fails.

We do have a Symantec Ticket opened and are contiuning to look at our AD structure

Thanks for taking the time to look at this.

If this is the case, then i would see a bug in deployment scanner.
what you also could do is just test it on a testmailbox. i think you have really done the permission testing job very well now :)

We're seeing the same thing in a domain.

Thanks