DS - 當您執行 "gpresult" 指令時發生 Access Denied 錯誤

徵狀:
================
1. 您打開 DOS 執行 "gpresult" 後得到 "Access Denied" 錯誤
2. 您執行 "gpupdate" 沒有問題，GPO套用成功
3. 您發現同一個 OU 下的其它台伺服器沒有這個問題。
4. 執行以下測試問題都無法解決。
    A. Use "klist purge" command to purge all Kerberos tickets, run "gpresult /V", do you still get "Access Denied" error?
    1. Download and install "Windows Server 2003 Resource Kit Tools" for the klist tool https://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en
    B. Delete existing "JeffreyAdmin" user profile, logon as JeffreyAdmin again to re-create user profile, run "gpresult /V", do you still get "Access Denied" error?
    C. Select a testing domain user and configure it as local admin (make sure the user does not have user profile on this server already), run "gpresult /V", do you still get "Access Denied" error?
    D. Isolate the server into a new OU
        1. Create a new OU and disable GPO inheritance on this OU.
        2. Move the computer object into this OU
        3. Logon to server as Domain Admin, run gpupdate /force
        4. Rebbot the server, does the problem still persists?
    E. Reboot the server into safe mode with network and run "gpresult /V", do you still get "Access Denied" error?
    F. Collect netmon trace and process monitor while running the "gpresult /V" to reproduce the "Access Denied" error
    G. Reset security settings back to the defaults <https://support.microsoft.com/kb/313222>
     secedit /configure /cfg %windir%repairsecsetup.inf /db secsetup.sdb /verbose

解決方法
================
1. Verify the default permissions for the RSOP namespace in WMI Management Console are correct.
325353 HOW TO: Set WMI Namespace Security in Windows Server 2003 https://support.microsoft.com/?id=325353

2. 依照以下步驟重建 WMI

-Open a console window (cmd) and change to the WBEM folder (cd "%windir%system32wbem").
-Carefully enter the following command to ensure that all of the WBEM DLLs are properly registered.

for /f %s in ('dir /b /s *.dll') do regsvr32 /s %s

-Also enter the following command to ensure that the provider host is properly registered.

wmiprvse /regserver

3. Stop the WMI service and rename the repository folder (WMI database) by entering the following commands. (WARNING: This step can potentially cause data loss. Read "Background Information" below for an alternative approach.)

if exist "repository.old" rmdir /s/q "repository.old"
net stop winmgmt /y
rename "repository" "repository.old"
net start winmgmt

-The above commands will cause WMI to rebuild the repository. After executing the above commands you should wait a few minutes (5 or so) before proceeding to give the rebuild process a chance to complete.

<< BACKGROUND INFORMATION >>
Renaming the repository folder causes WMI to rebuild the database. This can have some negative impact on the system. This is especially true if an application has stored static data in the repository. As an alternative to rebuilding the repository you can try manually recompiling all of the default WMI MOFs and MFLs using the following command. (Note: This can take a while to complete.)

for /f %s in ('dir /b *.mof *.mfl') do mofcomp %s

-In either case, if the system in question hosts Exchange 2000 you should also run the following additional commands after the WMI service is verified to be back up and stable (see below). Once again, all of these commands are executed from the %windir%system32wbem folder.

mofcomp exwmi.mof
mofcomp -n:rootcimv2applicationsexchange wbemcons.mof
mofcomp -n:rootcimv2applicationsexchange smtpcons.mof
mofcomp exmgmt.mof

4. Verify that the WMI service is back up by using WBEMTEST to execute a WMI query against the CIMV2 namespace.
a. Start -> Run -> Open : WBEMTEST
b. Click "Connect"
c. Enter "rootcimv2" for namespace and click "Connect"
d. Click "Enum Instances..."
e. Enter "Win32_OperatingSystem" and click "OK"
f. Double click on the returned instance to view data
g. Click "Close", click "Close", click "Exit"

-The above test ensures that the repository was successfully rebuilt. As an alternative to the above test you could also simply execute the following VBS script (i.e. cscript os.vbs).

set WMI = GetObject("WinMgmts:")
set objs = WMI.InstancesOf("Win32_OperatingSystem")
for each obj in objs
WScript.Echo obj.GetObjectText_
next

-If you receive errors with the above script (or WBEMTEST procedure) you can try manually recompiling all of the MOFs and MFLs as described in Step 3 (above).

6. From the console prompt (in %windir%system32wbem folder), ensure that the RSOP namespaces are rebuilt by executing the following commands.
mofcomp rsop.mof
mofcomp rsop.mfl

<< BACKGROUND INFORMATION >>
The RSOP classes depend on the corresponding providers being properly registered under HKEY_CLASSES_ROOTCLSID. These providers are as follows.

- Rsop Planning Mode Provider
%SystemRoot%system32rsopprov.exe
CLSID = {F0FF8EBB-F14D-4369-bd2e-d84fbf6122d6}

- Rsop Logging Mode Provider
%SystemRoot%system32userenv.dll
CLSID = {B3FF88A4-96EC-4cc1-983F-72BE0EBB368B}

7. Change to the SYSTEM32 folder (cd "%windir%system32") and execute the following command to make sure that the RSOP providers are properly configured.

regsvr32 /n /i userenv.dll

8. Reboot system.