Our security consultant have implemented Microsoft's recommended Windows and Office Group Policy settings.
The result right now is that our SCCM Client Center 188.8.131.52 comes with the following error:
Access is denied (Exception from HRESULT: 0x800700005 E_ACCESSDENIED).
I 've Checked almost all Group Policy settings but can not find it setting that generate this error.
Do you have a suggestion?
Client is Windows 7 Enterprise 64-bit
Thank you in advance
Access denied means exactly that-you aren't allowed to remotely connect to that computer. Forget about that it's client Center you are using to connect-any remote administration tool would generate the error; whether you are trying to use regedit remotely, or computer management remotely. It's a generic error-and not specific to Client Center.
With that in mind, can you get to \\thatcomputername\c$ ? If not, start with confirming three things: 1) the account you are currently logged in with on your computer (not the target, but you), is that account in the local administrators group in the target (or nested in a group which is?) If not, you'll never get to remotely manage it. 2) if that account is a local admin, then on the Target, disable the firewall (just to test). Can you get to c$ now? if so, then it's firewall rules. and your security consultant will need to adjust their GPO to have firewall rules to allow for remote management. 3) if ensuring local admin NOR disabling the firewall helps, then unfortunately (since apparently your security consultant can't help you) you will need to move a test computer into a test ou. make sure the new GPO does NOT apply. Copy that GPO, and apply THAT to the new OU. Confirm the problem still exists. Now… the sad part. One by one by one… with group policy updates and/or reboots inbetween each GPO edit you make… remove a setting. Test. If the problem is still there, remove another. Test.
I had to do #3 once for something similar. Took two days to narrow down which exact setting it was. So… painful. But the tortoise will win in the end.
Oh, I forgot to say… after moving the computer to a new OU and explicitly denying that the current GPO is applied, and before applying the copy-make sure the problem doesn't exist without the GPO. You don't want to waste 2-4 days removing settings in a test GPO-just to find out something else completely unrelated to the GPO just so happened to hit your clients at the same time as the GPO. So you blame the GPO-but days/weeks later find out it is something else.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.