none
Event ID 7016 "Completed Registry Extension Processing in x milliseconds" / SetRegistryValue: Failed

    Question

  • Hello Everyone,

    I have recently run into a strange problem with a new policy that I am working on. We have a domain running in 2003 mode. On a DC running 2012R2 I have created a user policy that uses the following settings:

    For some odd reason this policy applies to some computers without problems but is not applied completely on some others. On the problematic computers the policy is only applied partially. In event viewer I get error

    7016 "Completed Registry Extension Processing in ... milliseconds"

    I have turned on logging and created a gpsvc.log file. In the (huge) file I find the following info:

    GPSVC(17c.1060) 10:26:25:819 SetRegistryValue: DisableLockWorkstation => 1  [OK]
    GPSVC(17c.1060) 10:26:25:819 SetRegistryValue: DisableChangePassword => 1  [OK]
    GPSVC(17c.1060) 10:26:25:819 SetRegistryValue: Failed to set value <DisableRegistryTools> with 5

    So some settings are applying but for example "DisableRegistryTools" is not set. When I access the registry as the user that should receive the policy and navigate to HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System, I can see that some entries are set by the policy. I can create a test entry there manually, but I cannot create an entry specifically called "DisableRegistryTools":

    Google has not been helpful either. Does anyone have an idea why setting the registry value sometimes fails?

    Thanks for your help!

    HarryNew





    • Edited by HarryNew Friday, November 13, 2015 11:37 AM
    Friday, November 13, 2015 11:33 AM

Answers

  • > .... Help .... :-O
     
    Hmpf... Odd...
     
    Any additional software that is "somehow" security related? If yes,
    uninstall...
     
    • Marked as answer by HarryNew Wednesday, November 18, 2015 3:04 PM
    Wednesday, November 18, 2015 9:26 AM

All replies

  • > Google has not been helpful either. Does anyone have an idea why setting
    > the registry value sometimes fails?
     
    regedit does NOT show all registry values - there are certain value
    types that are hidden. It _might_ be that DisableRegistryTools ist
    present as one of these value types (REG_NUL or REG_QWORD for example).
     
    I'd suggest to delete the whole "System" key - it will be re-created
    when running "gpupdate /force".
     
    Monday, November 16, 2015 11:37 AM
  • Hello Martin,

    thanks for your answer! I deleted the key and updated the policies. The System key was rebuilt and populated with

    DisableChangePassword

    DisableLockWorkstation

    NoDispScrSavPage

    but DisableRegistryTools and DisableTaskMgr still don't work. Relevant lines in the gpsvc.log are

    RegCleanUpKey:  Failed to delete value <DisableTaskMgr> with 5
    DeleteRegistryValue: Failed to delete Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr
    SetRegistryValue: Failed to set value <DisableTaskMgr> with 5
    SetRegistryValue: Failed to set value <DisableRegistryTools> with 5

    EventViewer shows

    Do you have any other ideas?

    Regards

    Harry

    Monday, November 16, 2015 1:39 PM
  • > RegCleanUpKey:  Failed to delete value <DisableTaskMgr> with 5
    > DeleteRegistryValue: Failed to delete
    > Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr
    > SetRegistryValue: Failed to set value <DisableTaskMgr> with 5
    > SetRegistryValue: Failed to set value <DisableRegistryTools> with 5
     
    Never seen that before... "5" usually means access denied.
     
    Delete the system key again, run process monitor with a filter on the
    path, then do gpupdate /force - which processes do show up in procmon?
     
    Might be some kind of "sophisticated" AV solution :)
     
    Tuesday, November 17, 2015 11:02 AM
  • Hello Martin,

    Thanks for your help! Your assumption is right - 5 seems to stand for "access denied". ProcMon shows the following two entries for the path:

    I suspect that "svchost" is the process that gpupdate is running in? I am currently looking at two computers, one physical, the other VM.

    On the physical computer I only see this issue during normal background processing of the policies. As soon as I run gpupdate /force manually the "DisableRegistryTools" key gets written to the registry correctly and the tool is disabled. After the next reboot I can run regedit again, though :-(

    On the VM the policy is not executed properly at all, not even when I run gpupdate /force.

    I have looked around to see if I can further troubleshoot the relevant CSE but it seems that gpsvc is the only way for the Registry CSE ({35378EAC-683F-11D2-A89A-00C04FBBCFA2})

    .... Help .... :-O

    Harry

    Tuesday, November 17, 2015 4:52 PM
  • > .... Help .... :-O
     
    Hmpf... Odd...
     
    Any additional software that is "somehow" security related? If yes,
    uninstall...
     
    • Marked as answer by HarryNew Wednesday, November 18, 2015 3:04 PM
    Wednesday, November 18, 2015 9:26 AM
  • Any additional software that is "somehow" security related? If yes,
    uninstall...
     

    Hello Martin,

    Your hunch about security related software is 100% correct! I looked deeper into our virus scanner software and was able to determine that McAfee is the culprit. Even though the problematic behavior is not exactly the same on all my test computers, I found that the settings DisableRegistryTools and DisableTaskMgr can be written without problems on all test computers as soon as the access protection of McAfee is tuned off, no matter if gpupdate is triggered manually, runs in the background or runs during user login. It turns out that an update of McAfee added a rule "Prevent registry editor and Task Manager from being disabled" to one of the rule-sets and that went unnoticed in our IT.

    Thanks for your help, hints and insights!

    Regards

    Harry

    Wednesday, November 18, 2015 3:04 PM
  • > background or runs during user login. It turns out that an update of
    > McAfee added a rule "Prevent registry editor and Task Manager from being
    > disabled" to one of the rule-sets and that went unnoticed in our IT.
     
    Bummer :-))
     
    Thursday, November 19, 2015 11:12 AM