none
Patch Tuesday - KB3159398

    General discussion

  • Hi All,

    I installed windows patches last night and this morning found out that there were a number of issues with my GPO's.

    Example: desktop image would not show up, A, B, C and D drives that were meant to be hidden from users is now showing up.

    I found out that it was because of this update KB3159398. Here is the support article

    https://support.microsoft.com/en-gb/kb/3163622

    When I uninstalled this update and rebooted, everything was back to normal.

    Just though I write something up incase someone else is having this issue after applying the updates last night on windows 2008 R2 server.

    Kind Regards

    Wednesday, June 15, 2016 10:11 AM

All replies

  • I have exact te same issue on our windows 2012 r2 rds environment

    we uninstalled kb3159398 rebooted the servers and it works as normal.

    Regards



    • Edited by heugy Wednesday, June 15, 2016 10:39 AM
    Wednesday, June 15, 2016 10:35 AM
  • We are having the same issue on client workstations.

    It appears to be an issue with where a group policy has used an Active Directory Security group in the Security Filtering section.

    In that scenario the GPO's that are filtered to specific security groups do not apply, where as the GPO'swhich use the default Authenticated Users group in the security filtering do seem to apply.

    Uninstalling KB3159398 resolves the issue.....

    Wednesday, June 15, 2016 11:04 AM
  • Same here.

    KB3159398 has broken the application of group policies.

    Drive maps don't appear, setting aren't changed by GPO's

    Thanks Microsoft again for through testing

    Wednesday, June 15, 2016 11:26 AM
  • We are having the same issues on Win 7 Workstations and on Server 2012 RDS. Removing KB3159398 manually or through WSUS fixed the issue. On the other hand we're having no problems on Server 2008 (without R2).

    We feel again like beta testers for updates.


    • Edited by Alex4RZ Wednesday, June 15, 2016 11:38 AM typing
    Wednesday, June 15, 2016 11:38 AM
  • We are having the same issue on Windows 2008 R2 servers
    • Edited by APOLOGIC Wednesday, June 15, 2016 11:56 AM
    Wednesday, June 15, 2016 11:54 AM
  • Disabled ipv6 on the server network controller. Restarted server and Everything is backup and running.
    Wednesday, June 15, 2016 12:37 PM
  • I found out that if you give the Group authenticated users the right to read the GPO (Just Read, not to  Apply the GPO) then the Policies work again. 
    • Edited by DC_FS Wednesday, June 15, 2016 1:01 PM
    Wednesday, June 15, 2016 12:54 PM
  • Same problem here, lost shortcut to applications on user's desktop...
    Wednesday, June 15, 2016 12:59 PM
  • Reporting the same issue here.  We're also seeing it on Win 10 v1511.  Now the big question do you uninstall the one cumulative patch that includes all other security updates for Win 10.  Not a great way to start a Wednesday.
    Wednesday, June 15, 2016 1:07 PM
  • I can confirm that our broken GPO's were missing the Read permission for Authenticated Users on the delegation tab.  Once that was added back the GPO's processed as expected, but clearly this is a change from the patch. It would be nice to know if the patch will be fixed, or do we need to start "fixing" GPO permissions.
    Wednesday, June 15, 2016 1:11 PM
  • It's the applying computer itself that needs the read permission on the GPO. You'd probably only be affected if you use User GPO's directly on User OU's.

    If you use User GPOs on Computer OUs with loopback processing, it will continue to work as before, as the applying Computer already requires "read" for the loopback processing to work.

    Hopefully MS will release a fix soon...
    • Edited by Jings Wednesday, June 15, 2016 1:28 PM
    Wednesday, June 15, 2016 1:21 PM
  • Had the same issue here with Windows 7 machines.

    Remove the update, reboot and then run gpupdate, log off and log back on.

    Wednesday, June 15, 2016 2:00 PM
  • Same issue here. It was with every GPO filtered in Delegation tab for special groups. GPOs with authenticated user-Group worked fine. Removing this update works, but can't be the solution with 1000 Clients...
    Wednesday, June 15, 2016 2:08 PM
  • Completely agree with it not being a fix for a large number of clients, M$ need to release a fix asap!
    Wednesday, June 15, 2016 2:13 PM
  • Same here with Windows 8.1. No Mapping Drives with GPO.
    Wednesday, June 15, 2016 2:13 PM
  • You can unistall this update with WSUS.
    Wednesday, June 15, 2016 2:17 PM
  • I have the same problem, but with the the cummulative update KB 3163018. I have used the following steps :

    Used gpupdate /force and gpresult /H report.html

    Some GPO are listed as "denied" : Reason Denied : Inaccessible, Empty or Disabled. I have tested the same account on another computer without this update : it works.

    Used UserEnvDebugLevel on Group Policy core (UserEnv) and registry CSE

    As explained here : https://technet.microsoft.com/en-us/library/cc775423.aspx And compared %windir%\debug\usermode\UserEnv.log between two machines.

    For the machine without the KB applied, I have the ProcessGPO section with GPO successfully applied :

     ProcessGPO(User):  ==============================
     ProcessGPO(User):  Searching <cn={0F94E4D1-CE82-4263-98F9-94A3A55733FF},cn=policies,cn=system,DC=xxx,DC=xxx>
     ProcessGPO(User):  User has access to this GPO.
     ProcessGPO(User):  Found common name of:  <{0F94E4D1-CE82-4263-98F9-94A3A55733FF}>
     ProcessGPO(User):  GPO passes the filter check.
     ProcessGPO(User):  Found functionality version of:  2
     ProcessGPO(User):  Found file system path of:  <\\xxx\SysVol\xxx\Policies\{0F94E4D1-CE82-4263-98F9-94A3A55733FF}>
     ProcessGPO(User):  Found display name of:  <xxx>
     ProcessGPO(User):  Found user version of:  GPC is 42, GPT is 42
     ProcessGPO(User):  Found flags of:  0
     ProcessGPO(User):  Found extensions:  [{00000000-0000-0000-0000-000000000000}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}][{5794DAFD-BE60-433F-88A2-1A31939AC01F}{2EA1A81B-48E5-45E9-8BB7-A6E3AC170006}]
     ProcessGPO(User):  ==============================

    For the machine with the KB :

    ProcessGPO(User):  ==============================
    EvalList: Object <cn={0F94E4D1-CE82-4263-98F9-94A3A55733FF},cn=policies,cn=system,DC=xxx,DC=xxx> cannot be accessed/is disabled/or has no extensions

    And I have the following line before :

    Failed to query Kerberos Armoring in Registry = 0x80070002

    ...

     1 GetLdapHandle:  Getting ldap handle for host: xxx in domain: xxx.
     2 GetLdapHandle:  Will force the Kerbeors as this is not overriden
     3 GetLdapHandle:  Server connection established.
     4 GetLdapHandle:  Binding using only kerberos.
     5 GetLdapHandle:  Bound successfully.

    The lines 2 and 4 are not present on the computer without KB (do not know if related or not).

    • Edited by Thomas B_65 Wednesday, June 15, 2016 2:48 PM
    Wednesday, June 15, 2016 2:39 PM
  • Hi All,

    Just adding it affected USER applied policies for printer deployments, but the Computer policies worked still.

    I'm using Security filtering for the group, and it does appear on the delegation tab as applied through security filtering with read, but doesn't work...

    Keith

    Wednesday, June 15, 2016 2:47 PM
  • Ditto here for printer pushes using security filtering for User Policies... The Computer policies seem to work still.
    Wednesday, June 15, 2016 2:49 PM
  • I found out that if you give the Group authenticated users the right to read the GPO (Just Read, not to  Apply the GPO) then the Policies work again. 
    I can confirm that it works with this change.
    Wednesday, June 15, 2016 2:50 PM
  • We had the same thing come up this morning. GFI Languard pushed out the June security updates and this one broke some drive mappings for some of our users. What a PITA. We added Read permissions to Authenticated Users on the GPO because that's easier than removing the update from all of the workstations. Thanks for figuring this out.
    Wednesday, June 15, 2016 3:05 PM
  • We had the same thing come up this morning. GFI Languard pushed out the June security updates and this one broke some drive mappings for some of our users. What a PITA. We added Read permissions to Authenticated Users on the GPO because that's easier than removing the update from all of the workstations. Thanks for figuring this out.

    Has anyone tried this with Security filtering?  Does adding the Auth Users to a filtered policy apply it to everyone rather than the group?

    Thanks!

    Wednesday, June 15, 2016 3:14 PM
  •  > I can confirm that it works with this change.
     
    Confirmed too. Thanks for the quick analysis - would have taken me quite
    some effort to discover that :)
     --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Wednesday, June 15, 2016 3:25 PM
  • > Has anyone tried this with Security filtering?  Does adding the Auth
    > Users to a filtered policy apply it to everyone rather than the group?
     
    You should not add them to the security filtering (which indeed will
    make it apply to everyone), but to the delegation tab... and of course,
    with "Read" and nothing more :)
     
    --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Wednesday, June 15, 2016 3:29 PM
  • Hello guys! thank for the information, we are facing the same issue... ;_ ;
    But I'm trying to do this on a server 2008R2 and does not work for my POS station.

    Can someone explain me step by step how to add this on delegation tab.
    Perhaps I'm missing some step here...

    Wednesday, June 15, 2016 4:56 PM
  • I found out that if you give the Group authenticated users the right to read the GPO (Just Read, not to  Apply the GPO) then the Policies work again. 

    Many thanks for that!  This worked perfect.

    For me the only group delegated GPs I have are deployed printers and those are all USER side.  So based on what we know so far only those qualified for not getting applied and everything else was fine.

    So only USER side GPs and ones that are delegated by security groups got affected here.  Adding back Authenticated Users and giving them READ only permissions got everything back up and running.

    THANKS MICROSOFT!


    EDIT:

    The advice to simply remove the bogus update isn't an option for everyone as some of us received this update via a cumulative update and removing that on a couple machines was more trouble then it was worth!

    • Edited by JEmlay Wednesday, June 15, 2016 6:25 PM
    Wednesday, June 15, 2016 6:20 PM
  • You should not add them to the security filtering (which indeed will
    make it apply to everyone), but to the delegation tab... and of course,
    with "Read" and nothing more :)
     

    It doesn't matter if you add them to "security filtering".  Once you take away APPLY permissions they get auto removed from that area anyway.
    Wednesday, June 15, 2016 6:22 PM
  • I can confirm this is affecting us as well.  I now have to update 20+ GPOs to add Authenticated Users back in to the Delegation list:

    http://windowsitpro.com/patch-tuesday/patch-tuesday-security-update-group-policy-breaks-group-policy

    Removing this update from 70+ computers is just something I am not doing without a centralized update server (which I don't have).  Great going Microsoft.

    Wednesday, June 15, 2016 7:39 PM
  • I have added "Authenticated User" to my printer GPOs.  Now everyone has every printer, I guess that is better than no printers.   We need some real feedback from Microsoft.  
    Wednesday, June 15, 2016 8:06 PM
  • As others have eluded to you can fix this by adding "Authenticated Users" as a "Read" permission status. I had "Domain users" as the group but this does not seem to work anymore. Here's how you do this:

    • Open up group policy management and select the GPO you want to edit
    • Select the delegation tab and click add. Type "authenticated users" and hit enter. It will confirm the group and permission status of Read. Hit ok to confirm
    • Go to a machine that has the update and open the command prompt. Type "gupdate /force" and it will update
    • Restart or log off of the machine and it should start working

    This is likely just a temporary fix but it beats trying to uninstall the update on all your workstations

    Wednesday, June 15, 2016 8:14 PM
  • Hi Lon- You may be modifying the permissions in the wrong place.  In GPMC, you want to go to the GPO in question and then to the Delegation tab.  From there you want to add Authenticated Users with Read permission.  Do not modify anything on the Scope tab - doing it there will change who the GPO gets *applied* to, which isn't what we want to do.
    Wednesday, June 15, 2016 8:17 PM
  • Hi Lon- You may be modifying the permissions in the wrong place.  In GPMC, you want to go to the GPO in question and then to the Delegation tab.  From there you want to add Authenticated Users with Read permission.  Do not modify anything on the Scope tab - doing it there will change who the GPO gets *applied* to, which isn't what we want to do.
    Jeff, you are correct and thanks.  I did put it in the wrong place.  Deployment works correctly now.
    Wednesday, June 15, 2016 8:32 PM
  • Yup. Took me all morning to figure it out. Declined KB3159398 and KB3163018 and KB3163017.
    Wednesday, June 15, 2016 9:45 PM
  • Thanks! We also found out this issue this morning on a few machines that had the update applied and thank god I found a Reddit article that pointed to here to figure out that uninstalling was the best option, since specific GPOs for printers are applied only for specific staff or departments, and adding 'authenticated users' to them would essentially defeat the purpose of using the GPO to deploy printers in the first place. We ended uninstalling it and everything worked as usual. Microsoft, please fix this update and test it before publishing it! It breaks your own software.
    Wednesday, June 15, 2016 11:05 PM
  • Hi Lon- You may be modifying the permissions in the wrong place.  In GPMC, you want to go to the GPO in question and then to the Delegation tab.  From there you want to add Authenticated Users with Read permission.  Do not modify anything on the Scope tab - doing it there will change who the GPO gets *applied* to, which isn't what we want to do.

    Agree with this. This is definitely a workaround !!!

    We have the same issue concerning 5+ GPOs with Folder Redirections. Security filtering gets broken with KB3159398 and then the Folder redirection gets disabled.

    Putting "Authenticated Users" with Read Permissions into the Delegation tab restores the old behaviour and does truly NOT bypass security filtering completely. 

    Asking myself if this is a (security) feature or a bug !!!

    Wednesday, June 15, 2016 11:34 PM
  • I have just updated my Win 10 computer with the cumulative update, but not any of the servers, and all is well so far.

    I'd speculate that since root cause is Authenticated Users not having a Read ACE, that the only machines where the update can cause a problem is DCs. Can anyone confirm that if the update is removed (or never installed) on DCs, that the problem does not occur?

    Thursday, June 16, 2016 12:35 AM
  • Found out that this behavior is actually described in https://support.microsoft.com/en-us/kb/3163622, which was in the original message.

    One way to fix this is to add "Authenticated Users" with Read permission into the Delegation tab. Another way is to add "Domain Computers" to Security Filtering list.

    - - - - -

    Symptoms

    All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

    Cause

    This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

    Resolution

    To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:

    • Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
    • If you are using security filtering, add the Domain Computers group with read permission.
    Thursday, June 16, 2016 5:39 AM
  • We do not have the patch on any of our DC's (or any server for that matter). And if I install the patch on a PC in the domain the problem occurs immediately on that particular PC regardless of patch level on the domain controllers. And on our Windows 10 PC's KB3163018 is causing the same problem.

    Adding read only permission on our Group policy objects that is using security filtering for any thing other than authenticated users solves the problem. But i'm not sure if that's a temporary workaround while waiting for Microsoft to correct the patch, or a permanent fix to solve the problem.

    Thursday, June 16, 2016 6:20 AM
  • If anyone's interested, I wrote a quick PowerShell script that "fixes" GPO permissions in cases where Authn Users or Domain Computers doesn't exist. Wrote it up here: https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/

    I have no idea if this is considered a bug, or, as the article notes, "by design" and therefore the way things are in the future, but hopefully this script helps folks out there who are urgently trying to fix this.

    Darren


    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"


    Thursday, June 16, 2016 6:31 AM
  • If anyone's interested, I wrote a quick PowerShell script that "fixes" GPO permissions in cases where Authn Users or Domain Computers doesn't exist. Wrote it up here: https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/


    Thanks for the PowerShell Script, works perfectly ;)

    Greetings from Austria - Salzburg

    Thursday, June 16, 2016 8:56 AM
  • I had the same problem with printers, and changing security it was fixed.

    But after the installation of KB3163018 and KB3149135  my clients logon became slow, and they wait about 1 minute on "Foldere redirection " task at logon, anyone else had this?

    Before this updatelogon process was very fast

    (windows 10 platform)

    Thursday, June 16, 2016 9:09 AM
  • > pointed to here to figure out that uninstalling was the best option,
    > since specific GPOs for printers are applied only for specific staff or
    > departments, and adding 'authenticated users' to them would essentially
    > defeat the purpose of using the GPO to deploy printers in the first
     
    No, severe misunderstanding :-)
     
    You are supposed to add auth users to the "Delegation" Tab, NOT to the
    security filtering on the general tab...
     
    Or use Darrens little PoSh script:
     
    Thursday, June 16, 2016 9:16 AM
  • In our environment the issues after applying KB3159398 where even worse. After applying the fixes mentioned above still no client could access “\\<domainname>\SYSVOL”. They always got an access denied and in the system eventlog messages from “GroupPolicy (Microsoft-Windows-GroupPolicy)” Event ID 1058:

    The processing of Group Policy failed. Windows attempted to read the file \\<domainname>\SysVol\<domainname>\Policies\{4560EDE3-B896-4FF4-98C1-6ACE5F832240}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

    a) Name Resolution/Network Connectivity to the current domain controller.

    b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).

    c) The Distributed File System (DFS) client has been disabled.”

    As we found out this was caused by the policies:

    “Local Policies | Security Option | Microsoft network server: Server SPN target name validation level” being set to “Required from client”, and

    “Administrative Templates | Network | Network Provider | Hardened UNC Paths” containing “\\*\SYSVOL”.

    As we couldn’t edit group policies from our management workstations we proceeded as follows:

    1. Disable the group policy containing the policies shown above. (This still worked from gpmc)
    2. Run the following PS commands on each domain controller:
      • Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters -Name smbservernamehardeninglevel -Value 0
      • Remove-Item -Path HKLM:\Software\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
    3. Reboot the domain controller

    After this access from clients was restored and we could properly change the group policies.

    If anyone else is using these policies I hope our experiences will help.



    • Edited by JSp42 Thursday, June 16, 2016 9:28 AM
    Thursday, June 16, 2016 9:22 AM
  • We have had the same issue this morning with desktop backgrounds and printers.

    I have issued removal from WSUS and added the read as per instructions.  This has worked.

    Having read JSP42's comments I think we got away easy...  Well done on the PS fix.

    What a start to a morning, half a day wasted, cheers MS!

    Thursday, June 16, 2016 10:24 AM
  • We have applied the new read permissions and these are working.

    But we have deny permissions applied to certain groups to filter out individual users from the group policy where it is applied to authenticated users and these are being ignored.

    Anybody know a way around this?

    Thursday, June 16, 2016 10:35 AM
  • > But we have deny permissions applied to certain groups to filter out
    > individual users from the group policy where it is applied to
    > authenticated users and these are being ignored.
     
    Then deny "apply group policy", this will work even if "read" is granted.
     
    Thursday, June 16, 2016 11:04 AM
  • I fell victim to this too.  It was only GPO's where users or groups we specified.  I'm uninstalling KB3159398.  Now to work out a script to do it!
    Thursday, June 16, 2016 11:05 AM
  • Hello everyone,

    we do have the same troubble. All our printers deployed through GPO dissappeared from all workstations - Win7 and Win10 also. When I added the "read" permission to our GPO objects, the problem was temporary solved. I still do not know if this is a bug or a feature. I hope there will be some article or fix released by Microsoft soon.

    Regards,

    Jiri Simek

    Thursday, June 16, 2016 11:06 AM
  • Having this issue this morning, but the problem is not only KB3159398. I removed that update from the client PC and it did not solve the problem. As I haven't had time to pinpoint the actual update causing the issue (on windows 7 with Server 2012R2), I removed all updated installed last night, these included:-

    KB3164035

    KB3164033

    KB3161958

    KB3161949

    KB3161664

    KB3161561

    KB3160005

    Removing all of these resolved the issue. I just need to pinpoint which one caused the issue.

    Thursday, June 16, 2016 11:19 AM
  • Same problem here

    I make a workaround:

    Get-GPO -All | foreach-object { if($_ | Get-GPPermissions -all -TargetType Group -ErrorAction SilentlyContinue) {$_ | Set-GPPermissions  -TargetName "Authenticated users" -PermissionLevel gporead -TargetType group }}

    In new GPO add Delegation to  "Authenticated users" read permission.

    OR

    Get-GPO -All | foreach-object { if($_ | Get-GPPermissions -all -TargetType Group -ErrorAction SilentlyContinue) {$_ | Set-GPPermissions  -TargetName "Domain Computers" -PermissionLevel gporead -TargetType group }}

    OBS: in my case PT-BR "computadores do domínio"

    In new GPO add Delegation to  "Domain Computers" read permission.



    • Edited by Ademar_Feil Thursday, June 16, 2016 12:23 PM
    Thursday, June 16, 2016 12:01 PM
  • Same problem here

    I make a workaround:

    Get-GPO -All | foreach-object { if($_ | Get-GPPermissions -all -TargetType Group -ErrorAction SilentlyContinue) {$_ | Set-GPPermissions  -TargetName "Authenticated users" -PermissionLevel gporead -TargetType group }}

    In new GPO add Delegation to  "Authenticated users" read permission.

    OR

    Get-GPO -All | foreach-object { if($_ | Get-GPPermissions -all -TargetType Group -ErrorAction SilentlyContinue) {$_ | Set-GPPermissions  -TargetName "Domain Computers" -PermissionLevel gporead -TargetType group }}

    OBS: in my case PT-BR "computadores do domínio"

    In new GPO add Delegation to  "Domain Computers" read permission.



    The same result can be achieved with an even shorter command line, which is also language neutral:

    Set-GPPermission -All -PermissionLevel GpoRead -TargetName (Get-ADGroup "$((Get-ADDomain).DomainSID)-515").Name -TargetType Group -ErrorAction Continue
    I'd expect the update to also change the behaviour of the GPMC by issuing some kind of information about this when creating new GPOs, but I also expect to be disappointed.

    • Edited by DMoenks Thursday, June 16, 2016 12:48 PM
    Thursday, June 16, 2016 12:28 PM
  • Hi Codeworx1,

    i had the same, but it is the KB3159398 but the computer needs im my case 2 restarts after uninstall to get all back working normally. Had the issue to 150 Computers, but in the end I solved it with the "Authenticated Users" with "Read Rights" to all group restricted GPOs in delegations tab.

    Hope it helps you.

    Thursday, June 16, 2016 12:40 PM
  • The problem I have with this security fix is it breaks the ability to filter GPOs on user security groups.  I understand there are ways to workaround preferences using item-level targeting, but we have, for example several GPOs which use administrative templates and were original filtered on user security group which I can no longer use.. Im really hoping Microsoft can look into an alternative way to fix the security flaw without breaking user security group filtering on the GPOs...
    Thursday, June 16, 2016 1:08 PM
  • The problem I have with this security fix is it breaks the ability to filter GPOs on user security groups.  I understand there are ways to workaround preferences using item-level targeting, but we have, for example several GPOs which use administrative templates and were original filtered on user security group which I can no longer use.. Im really hoping Microsoft can look into an alternative way to fix the security flaw without breaking user security group filtering on the GPOs...

    You can continue to use security groups as filter, only need to delegate the domain computer the ability to read te GPO.

    I have more than 400 GPOs, among these 380 GPOs with security groups filter and WMI filter.

    I apply permission fix to all existing GPOs and changed my GPU creation procedure, adding a step to delegate computer permission to read. 


    Thursday, June 16, 2016 1:25 PM
  • The problem I have with this security fix is it breaks the ability to filter GPOs on user security groups.  I understand there are ways to workaround preferences using item-level targeting, but we have, for example several GPOs which use administrative templates and were original filtered on user security group which I can no longer use.. Im really hoping Microsoft can look into an alternative way to fix the security flaw without breaking user security group filtering on the GPOs...

    What I get from the the KB article is that only the way of accessing the GPOs was changed, not the actual application of the GPOs. Based on the given information by Microsoft I would expect security filtering to still work like it did before the update.
    Thursday, June 16, 2016 1:27 PM
  • > the given information by Microsoft I would expect security filtering to
    > still work like it did before the update.
     
    It does. It's only a misunderstanding about "security filtering" and the
    "delegation" tab.
     
    Thursday, June 16, 2016 1:31 PM
  • I can confirm that adding Authenticated Users read access to the security of each GPO object fixes the issue.
    Thursday, June 16, 2016 1:59 PM
  • I'm not sure if this is really a bug !!!

    I think the update corrects some LDAP calls where Kerberos authentication obviously was not needed and therefore MITM attacs were possible. I guess Unfortunately the whole security filtering thing depended on these calls and now is broken.

    IMHO the solution (not only a Workaround) is to set the "authenticated users" read permission on the affected GPOs

    Thursday, June 16, 2016 2:29 PM
  • So it is by design!

    https://www.reddit.com/r/sysadmin/comments/4odkev/ms16072_issues/

    One of our PFEs just emailed me this about a recent patch

    SUMMARY:

    There has been some reported issues surrounding a patch that was just released in June. MS16-072 is an important update that targets Group Policy and security filtering. This means that to avoid a man in the middle attack (MTM) the product groups have decided to remove security filtering by users. So any GPOs you might have in place that relies on scoping GPOs to users will break if this patch is applied.

    Here’s more additional information:

    MS16-072 changes the security context with which user group policies are retrieved. The intent of this by-design behavior change to protect customers’ computers from a security vulnerability. Prior to MS16-072, user group policies were retrieved using the user’s security context. After installing MS16-072, user group policies are retrieved using the machines security context.

    Symptoms:

    New and existing user group policy that has been security filtered on user accounts and / or security groups may fail to apply on domain joined computers.

    Cause: This issue may occur if the Group Policy Object is missing ‘Read’ permissions for the Authenticated Users group -OR- This issue may occur if you are using security filtering and are missing ‘Read’ permissions for the domain computers group

    Resolution: Using the Group Policy Management Console (GPMC.MSC)

    Add the ‘Authenticated Users’ group with Read Permissions on the Group Policy Object (GPO)

    -AND / OR-

    If you are using security filtering, add the ‘Domain Computers’ group with read permission.

    This particular patch can be put on hold until you have put in place the fixes outlined in this email. Afterwards, apply the patch normally. If you have further questions, let me know.

    * If you use GPOs that are scoped to users or groups they will break if you install this patch.


    Hello!


    • Edited by Grimson Thursday, June 16, 2016 2:53 PM
    Thursday, June 16, 2016 2:52 PM
  • How do we change the default permissions on new GPOs so that Authenticated Users have read permissions set?  When I go to Advanced security settings on any policy, it shows the default permissions as not inherited so where does it get set from?  I apologize in advance if any updates from yesterday changes this behavior as I have yet to install them.  I will be installing later today. Thank you.
    Thursday, June 16, 2016 3:41 PM
  • This would have to be done within the AD schema by changing the defaultSecurityDescriptor attribute on the gpContainer class. This article describes it generally: https://support.microsoft.com/en-us/kb/321476

    Darren


    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"

    Thursday, June 16, 2016 4:34 PM
  • My experience with the MS suggested fix varied.

    The authenticated users, Domain Computers read permissions did not fix my drive mapping policy, but did fix my background image registry policy.  I am using security filtering on both, but the difference I found between the two was that I was NOT using item-level targeting.

    Once I added item-level targeting to all machine OUs, the policy started working again.

    -Ryan

    Thursday, June 16, 2016 4:38 PM
  • So MS, please can you answer a couple of questions about this.

    • Where was the advanced notification of this change so that we can adequately plan modifying our GPOs for this behavioral change? There should be widespread and significant advance publication of these behavioral changes prior to release.
    • When will GPMC be updated because currently GP modelling does not reflect the changes in behavior.

    I'm glad this has only affected me and not my 2500 users yet. I'm our guinea pig and am one of the few in our organisation to automatically get updates as they are released.

    Thursday, June 16, 2016 4:46 PM
  •  in regards to Codeworx1's point that there is more than just 3159398 causing a problem... KB3161561 if installed on domain controllers, and if you have UNC hardened access enabled (as it should be) on sysvol with require authentication and integrity, will stop group policy processing in its tracks and lead to access denied errors when accessing sysvol using your domain's namespace, at least I have seen. My post from from a Patch Management Mailing List Below:

    "Greetings:

    Earlier today we installed KB3161561, as well as other June patches, and avoided installing KB3159398 on our server 2012R2 Domain Controllers. The results were that sysvol was providing access denied errors during group policy processing and when attempting to manipulate Group Policy objects via GPMC. We could not open \\DOMAINNAME\sysvol but could open \\DCNAME.domain\sysvol . After verifying and checking permissions on sysvol we weren’t left with much other than looking at our UNC hardening GPO which has been in place for a good amount of time without any issues. Setting Authentication and mutual integrity values to 0 (for sysvol only) on an isolated DC and rebooting it magically allowed group policy processing and namespace based access to sysvol. We removed June updates from our other DC’s and then found that we could set integrity and authentication back to 1. On a hunch, I tried installing 3161561 and the issue returned. Upon removal, all was working again. I’m not sure if this update is meant to ONLY be installed in conjunction with 3159398 or if there are other mitigating circumstances with our security group policies which have been in place for quite some time and have not caused any interaction such as this. I hope this saves someone else some time and frustration. FFL/DFL 2012R2."


    • Edited by TallEd-MSsys Thursday, June 16, 2016 5:14 PM clarity.
    Thursday, June 16, 2016 5:02 PM
  • We are having the same issue on client workstations.

    It appears to be an issue with where a group policy has used an Active Directory Security group in the Security Filtering section.

    In that scenario the GPO's that are filtered to specific security groups do not apply, where as the GPO'swhich use the default Authenticated Users group in the security filtering do seem to apply.

    Uninstalling KB3159398 resolves the issue.....

    Same issue with 2012 R2 and group policy applied to a security group
    Thursday, June 16, 2016 5:47 PM
  • I was pointed here due to my post under another thread and I wanted to let folks know this behavior is "by design".  This is from Microsoft Windows 10 KB 3163622 Known Issues

    "MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context."

    Therefore, security filters can now only be used against machine security contexts, not user contexts.


    Pete

    Thursday, June 16, 2016 6:24 PM
  • In this line of thoughts and thinking ahead (if this is by design and will not be altered in future updates) then all of us IT guys should probably be thinking about adding the "domain computers" group to the security group that we are going to filter a future policy for. By default whenever you use security filtering the specific group you are filtering for gets "read" permissions to the policy in the delegation tab. Therefore putting the "domain computers" group in advance into the filtering group will guarantee you a working policy. The more intelligent way to fix this by Microsoft is to add by default the domain computers group into the delegation tab whenever a security filter is set. Either way it will work fine.
    Friday, June 17, 2016 5:33 AM
  • The script to update GPO permissions with more debug output.

    $DebugPreference = 'Continue'
    
    Write-Debug "Get list of the all group policy objects in the domain."
    
    $AllGpo = Get-GPO -All | Sort-Object -Property 'DisplayName'
    
    Write-Debug "Select group policies for permissions changing."
    
    $ProcessGpo = foreach ($Gpo in $AllGpo)
    {
        Write-Debug "Process the group policy `"$($Gpo.DisplayName)`"."
    
        Write-Debug "Get permission for the `"Authenticated Users`" group."
        $AuthUsersPermission = $Gpo | Get-GPPermissions -TargetName 'Authenticated Users' -TargetType Group -ErrorAction SilentlyContinue
    
        Write-Debug "Get permission for the `"Domain Computers`" group."
        $DomainComputersPermission = $Gpo | Get-GPPermissions -TargetName 'Domain Computers' -TargetType Group -ErrorAction SilentlyContinue
    
        if (-not ($AuthUsersPermission -or $DomainComputersPermission))
        {
            Write-Debug "No permissions found."
            $Gpo
        }
        else
        {
            Write-Debug "Permissions found. Skip group policy."
        }
    }
    
    if ($ProcessGpo)
    {
        Write-Debug "List of the selected group polices."
        $ProcessGpo | Select-Object -ExpandProperty DisplayName | Write-Debug
    
        Write-Debug "Change permissions for the selected group polices."
    
        foreach ($Gpo in $ProcessGpo)
        {
            try
            {
                Write-Debug "Process the group policy `"$($Gpo.DisplayName)`"."
    
                Write-Debug "Add the `"Read`" permission for the `"Authenticated Users`" group."
                Set-GPPermissions -Guid $Gpo.Id -PermissionLevel GpoRead -TargetName 'Authenticated Users' -TargetType Group -ErrorAction Stop | Out-Null
                Write-Debug "Permissions changed successful."
    
                $Gpo
            }
            catch
            {
                $_ | Write-Error
            }
        }
    }
    else
    {
        Write-Debug "No group policy found."
    }
    


    Friday, June 17, 2016 8:15 AM
  • Really? This is about as bad as it can get with updates, I'm all for security but where is the testing and pre-warning from Microsoft. It shouldn't be left to the community to provide workarounds and resolutions to what has been considered a perfectly reasonable way of controlling the application of group policies.

    What gives Microsoft.

    ??????????????????????????????????????


    Friday, June 17, 2016 9:16 AM
  • Not really 100% Microsoft's fault. Normal and best practise for GPOs is not to remove Authenticated Users for Read anyway........

    http://www.grouppolicy.biz/2010/05/how-to-apply-a-group-policy-object-to-individual-users-or-computer/


    Lee Bowman MCITP MCTS

    Friday, June 17, 2016 9:45 AM
  • Not really 100% Microsoft's fault. Normal and best practise for GPOs is not to remove Authenticated Users for Read anyway........

    http://www.grouppolicy.biz/2010/05/how-to-apply-a-group-policy-object-to-individual-users-or-computer/


    Lee Bowman MCITP MCTS

    I disagree. If you read through https://msdn.microsoft.com/en-us/library/aa373513(v=vs.85).aspx, they state:

    There are different methods administrators can use to prevent a GPO policy from applying to a specific group (for example, to administrators). The recommended method is to remove (clear Allow) both the Read and Apply Group Policy ACEs for the group.

    This has the effect of removing the group from the security filtering tab. Also, if you read https://technet.microsoft.com/en-us/library/cc752992(v=ws.11).aspx, this says you need to remove the Authenticated Users group from the security filtering tab.

    Whilst your link may work and mean that the loss of GPO access caused by this update are no longer an issue, the Microsoft documentation on their own website is recommending us to remove the Authenticated Users group from the security filtering so we can limit the scope to group members.

    Friday, June 17, 2016 10:15 AM
  • >      Write-Debug "Get permission for the `"Domain Computers`" group."
    >      $DomainComputersPermission = $Gpo | Get-GPPermissions -TargetName 'Domain Computers' -TargetType Group -ErrorAction SilentlyContinue
     
    Not everybody has a en-us active directory :-))
     
    -TargetName (Get-ADGroup "$((Get-ADDomain).DomainSID)-515").Name
     
    And ahead of asking: I don't know why, but "Authenticated users" seems
    to work in every language.
     
    --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Friday, June 17, 2016 11:51 AM
  • > defaultSecurityDescriptor attribute on the gpContainer class. This
    > article describes it generally:
     
    And this article - although german, maybe google can translate - tells
    you what Default SD you need:
     
     
    --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Friday, June 17, 2016 11:52 AM
  • We have the same problem on different Server versions at different customers.

    My analysis is exactly like yours. Disabling UNC Hardening for Sysvol or uninstalling the Update fixes access from the Domain-DFS share to Sysvol.

    Having the update installed AND UNC path hardening active prevents access via DFS Domain share.

    Friday, June 17, 2016 12:42 PM
  • Also, 'gpupdate/target:user' no longer seems to work. You have to run 'gpupdate' without switches to get the user policies applied.
    Friday, June 17, 2016 3:10 PM
  • I blogged this (in English) as well:

    https://sdmsoftware.com/group-policy-blog/tips-tricks/modifying-default-gpo-permissions-creation-time/

    As did fellow GP MVP Jeremy Moskowitz:

    http://www.gpanswers.com/never-a-dull-moment-with-group-policy-or-what-to-do-about-ms16-072/

    Darren


    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"

    Friday, June 17, 2016 6:33 PM
  • Microsoft issued KB3163622 to address the problem but adding the recommended permissions not only FAILS to resolve the issue but we're getting weird results as well!

    On domain computers that ran the update prior to the permissions being added to GPO's with security filtering, the policies are still failing. Forcing GPUPDATE does nothing.

    On domain computers that did NOT run the update prior to the permissions change, things are still working BUT I do NOT expect this to last!

    My reasoning?

    When I run the Group Policy Results Wizard for users on various computers, ALL policies with security filtering are still showing DENIED! Has anyone even looked at that?

    This means WE CAN NO LONGER USE SECURITY FILTERING on Group Policy Objects! Isn't that wonderful?

    Now I have to figure out another way to map departmental printers and drives for specific departments. Thanks for ruining my Friday, Microsoft.

    I have worked on this ALL DAY LONG and can only conclude that the MS16-072 updates must be removed! Now I'm working this weekend. Thanks, Microsoft.

    Keywords: KB3163622 KB3159398 KB3163016 KB3163017 KB3163018

    Friday, June 17, 2016 9:05 PM
  • Totally disagree! Authenticated Users are automatically removed upon the very act of changing Security Filtering to any other group!

    This is why I do NOT understand the reason someone at Microsoft wrote KB3163622 as though Authenticated Users should always appear in Delegation! It is simply not true!

    Friday, June 17, 2016 9:36 PM
  • OK I've run the powershell script from here to determine what GP's needed modifying.

    Then added Domain Computers with Read Permissions to each affected GPO.

    Luckily the patches only went to a small number of PC's in my Config Manager Software Updates test group.

    This blog was a great help,

    http://www.gpanswers.com/never-a-dull-moment-with-group-policy-or-what-to-do-about-ms16-072/

    Cheers

    Damon

    Friday, June 17, 2016 11:57 PM
  • Actualy there is a another issue for policy revision id. After the kb3159398 all policy sysvol revisionid's looks like a 65535. Did someone see this change?

    Saturday, June 18, 2016 8:56 AM
  • Hi

    I am wondering if maybe you can help me with an issue that I am having after the patch update

    I have added the authenticated users to the gpo's and most of them are working now on windows 7 & 10 pc's

    But on win 8.1 pc's I am having problems.

    On win 7 & 10 pc's I am having problems only with adding sites to the compatibility mode in explorer

    The policy shows as applied but no effect in internet explorer

    I am using: user configuration -> administrative templates -> windows components -> internet explorer -> compatibility view -> use policy list of internet explorer 7 sites

    On win 8.1 pc's I am having problems with adding sites to the compatibility mode in explorer & setting logon script by gpo

    I am using: user configuration -> policies -> windows settings -> scripts -> logon

    Before the installation of the latest updates all the configuration was working.

    Please advise 

    Sunday, June 19, 2016 9:34 AM
  • same problem here, but the suggested workaround (adding "authenticated users"/domaincomputers to the gpo delegation) does not work at all.
    we do not use securityfiltering, there is just the standard "authenticated users" entry.
    but we do use item-level-targeting of the group policy preferences to map network-drives. these seem to have weird effects with the KB installed.
    we deinstalled kb3159398 on some machines and the problems were gone.

    at the moment we are taking back the update via wsus for all machines.

    Monday, June 20, 2016 8:44 AM
  • > Actualy there is a another issue for policy revision id. After the
    > kb3159398 all policy sysvol revisionid's looks like a 65535. Did someone
    > see this change?
     
    This is a long lasting bug in the reporting engine :-) Nothing worth
    hassling with.
     --
    Greetings/Grüße, Martin -
    Mal ein gutes Buch über GPOs lesen? -
    Good or bad GPOs? My blog - http://evilgpo.blogspot.com
    And if IT bothers me? Coke bottle design refreshment -
     
    Monday, June 20, 2016 10:51 AM
  • Hi to all,

    the same issue on XenApp Servers with 2012 R2 OS.

    Removed the KB3159398, all is back working!!

    Thank You!!!!

    Monday, June 20, 2016 11:15 AM
  • Hi all,

    If you add the "Authenticated Users" group or "Domain Computers" group with a read permission on the delegation tab of the GPO the problem will be fixed.

    Please refer to the following article:

    https://support.microsoft.com/en-us/kb/3159398

    Regards,

    vbosh

    Monday, June 20, 2016 1:16 PM
  • Hello,

    Please use the Group Policy Management Console (GPMC.MSC) and add the ‘Authenticated Users’ group with Read Permissions on the Group Policy Object (GPO) and \ or if you are using security filtering, add the ‘Domain Computers’ group with read permission.

    Monday, June 20, 2016 1:31 PM
  • That doesn't work or it applies the policy that is supposed to be filtered to a particular group

    to everyone.

    Monday, June 20, 2016 4:13 PM
  • This update doesn’t change the default permissions of a gpo so that it adds “authenticated users” with a separate “read” permission. If this update did what it was designed to do, it is obviously a horrible design. Before becoming aware that this update caused an issue, I tried restoring all permissions to default and then removed “authenticated users” from the scope and re-added the user groups I wanted in the scope. This did not resolve the issue and it should have. This update should update the “default permissions” button so it adds a read permission for “authenticated users”, and a separate “apply” permission for “authenticated users” that is removed when you remove “authenticated users” from the scope. Or… changing the scope to only selected user groups should update the “delegated permissions” appropriately so the scope works correctly. I really hope Microsoft is seeing the failure in this release.
    Monday, June 20, 2016 10:47 PM
  • Problems with KB3159398: no shared printers and folder redirections not working. Removing the KB not worked but giving read access to Autheticated Users in GPO yes. TY.
    Tuesday, June 21, 2016 7:49 AM
  • This is not working for a long duration. We've added the Authenticated Users in the delegation tab. -> Then it works for a while. After maybe 15 Min (maybe 30 Mins) "Authenticated Users" disapeared again in the delegation tab.

    On SBS Servers the problems exist with the build in SBS Client / User policies. Drive mappings, shared printers etc... not working.

    Please fix this issue.. our customers won't pay for such errors !


    • Edited by BrunoK11 Tuesday, June 21, 2016 11:53 AM
    Tuesday, June 21, 2016 11:50 AM
  • Hi,
     
    Am 21.06.2016 um 13:50 schrieb BrunoK11:
    > [...] After maybe
    > 15 Min (maybe 30 Mins) "Authenticated Users" disapeared again in the
    > delegation tab.
     
    I am scared. I have never seen a AD, where permissions are gone by
    magic. Probably the SBS original owned GPOs are generated by a special
    permission set, but I can not believe, that there is a service running
    in background resetting the settings.
     
    Ideas:
    a) use your own GP Ruleset
    b) add DomainComputers "read" instead
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Tuesday, June 21, 2016 12:13 PM
  • we can reproduce that behavior with 2 different client (customers) installations.

    I've read your article (thanks for that). But it is not very clear (in part of following)

    You write

    Lösungen für die Zukunft:
    a) Änderung der ....

    b) Veränderung des defaultSecurityDiscriptors....

    is your solution implementing a) AND b) or only a) OR b)

    -> hoffe, Du weisst was ich meine, ich habe es so aufgefasst, dass es zwei Lösungsvarianten sind also a. oder b. ;-)

    and another question we've looking to find out at the moment

    Does this happen to the clients when:

    a) Only the Domain Controller has this patch

    b) only the Client Computer has this patch

    c) both Computers have this patch

    We have several installations but different results (the problem is, we cannot reboot the servers during the day, for prooving the situation..)

    thanks

    Bruno


    • Edited by BrunoK11 Tuesday, June 21, 2016 12:42 PM
    Tuesday, June 21, 2016 12:39 PM
  • Am 21.06.2016 um 14:39 schrieb BrunoK11:
    > [...] is your solution implementing a)*AND* b)
     
    YES!
     
    Add DomainComputers to all GPOs! Change the SD for future GPOs.
     
    Why adding DomCpoms to all?
    a) to have all default permissions on every GPO the same.
    b) if you only add them to "broken" GPOs, think what will happen if
    someone remove the Auth.Users in the future from a GP Object.
    Having DomComps inside, the users policies will always work.
     
    > and another question we've looking to find out at the moment
    > Does this happen to the clients when:
    > a) Only the Domain Controller has this patch
     
    the DC acts like a client himself. But users logging on to a DomCon will
    still get user policy. The DomainControllers are integrated with READ on
    every GPO, otherwise the GPO could not be replicated.
     
    > b) only the Client Computer has this patch
     
    All Computers having this patch change their behavior of GP processing.
    All Clients, Servers and DCs.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Tuesday, June 21, 2016 1:01 PM
  • We had the same issue with Win Vista, 7, 10. Stopped all security filtered GPOs from working such as icons etc, biggest of all was Folder Redirection. The issue only surfaced when the 2012 DCs applied the patch.

    I had to add Domain Computers the right to read the policy for those policies that are filtered to user security groups.

    Regards,


    • Edited by zxxzxx Tuesday, June 21, 2016 7:03 PM
    Tuesday, June 21, 2016 7:00 PM
  • Is Microsoft going to release a fix, or we have to do on our own?

    Wednesday, June 22, 2016 4:17 PM
  • Hi to all,

    I am lucky enough to have a security team that always pushes WSUS updates to test groups for a month, before rolling to production.  I am reading a lot of different responses here to what is working and what is not working, but according to the official MS article below, that everyone is referring to, I would think I just run the Powershell command "Set-GPPermission -All -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead" and then not have any issues when this patch is applied?

    My concern is that sometimes Group Policy does contain sensitive information.  A few years ago, people were changing passwds through GPP before Microsoft admitted that was a huge security concern and removed that feature.  We still have issues where we will push certificates to a specific set of computers, etc., but it is getting rare.  Doesn't giving everyone read access to the policies let them go through Sysvol and look through everything, when they previously would have been denied access for that specific policy? Does it also let them load RSAT and GroupPolicy on their computers and then be able to read all GPOs so they can see how everything is setup and getting applied?  I know a lot of times authenticated users is in there anyway, but just trying to see if there are any other security concerns from this.

    Thanks,


    Dave

    https://support.microsoft.com/en-us/kb/3159398












    • Edited by DaveBryan37 Wednesday, June 22, 2016 9:22 PM
    Wednesday, June 22, 2016 5:47 PM
  • Earth to Microsoft, are you going to correct this error you have made?

    Wednesday, June 22, 2016 7:12 PM
  • Try adding Domain Computers with read permissions to delegation tab.   I had the same issue where authenticated users was disappearing - but Domain Computers has held its settings
    Wednesday, June 22, 2016 9:56 PM
  • Just thinking, is anyone opened a MS ticket to premier support? I believe that every second AD enviroment in the world has this issue, so I personally expect that MS would supersed this KB and come with another solution. In our company, there is 10 customer enviroments per 1 specialist, to this is a real headache to IT service provider!
    Thursday, June 23, 2016 3:01 PM
  • Thank u very much! this helped me a lot!

    Vusal M. Dadashzadeh

    Thursday, June 23, 2016 9:32 PM
  • So MS, please can you answer a couple of questions about this.

    • Where was the advanced notification of this change so that we can adequately plan modifying our GPOs for this behavioral change? There should be widespread and significant advance publication of these behavioral changes prior to release.
    • When will GPMC be updated because currently GP modelling does not reflect the changes in behavior.

    I'm glad this has only affected me and not my 2500 users yet. I'm our guinea pig and am one of the few in our organisation to automatically get updates as they are released.


    Friday, June 24, 2016 6:35 AM
  • I'm very disappointed.

    I found a lot of client where folder redirection policy stopped working  fine:

    I've DESKTOP and DOCUMENTS folders redirected to a network Share

    I've fixed delegation GPO security,but some clients stop Redirecting to DOCUMENTS folder... others stopped redirecting DESKTOP , others are working fine!

    Friday, June 24, 2016 8:19 AM
  • I've also been having some issues.

    Although I do not have this update, an update of sorts has stopped GPO user folder preferences, file associations working for image file types.

    I have a premiere support case open for nearly 2 weeks now and they cannot work it out!

    Friday, June 24, 2016 3:48 PM
  • Hi,

    the info in this thread has been great but I am left in the dark a bit and would like some comments from others, I like many was left dumfounded by this 'patch' and have struggled to understand what is going on.  I have managed to get Windows 8.x clients back to almost normal but for Windows 10 users, they only process a GPO if it is attached to an OU that is also covered by the PC they are using.  All of our policies that are linked to USER OU's have stopped working for Windows 10.

    Is this what others are seeing?  have tried all sorts of combinations of permissions on a policy to get it to process but not a peep from any on a user OU, anyone else had any luck with Win10 and User OU policies?

    Regards,

    Peter from down under.


    • Edited by ITadmin73 Monday, June 27, 2016 5:18 AM
    Monday, June 27, 2016 5:17 AM
  • > a user OU, anyone else had any luck with Win10 and User OU policies?
     
    In W10 MS16-072 was not a standalone patch but included in the
    cumulative update.
     
    Monday, June 27, 2016 10:50 AM
  • @JRV529088

    Did you manage to confirm this? I have one customer experiencing this symptom. ie. The issue only kicks in when they apply the patch to both clients and DCs. There is no issue if they apply the patch to clients only. It doesn't really make sense and I'm not in a position to debug it for them. But you're the only one that's made a similar link.

    Cheers,

    Jeremy


    Jeremy Saunders


    Monday, June 27, 2016 4:24 PM
  • Just synced my SCCM/WSUS, the KB is still active, not expired.
    Tuesday, June 28, 2016 2:27 PM
  • > Just synced my SCCM/WSUS, the KB is still active, not expired.
     
    Yes, and this will remain. The design change is permanent and intended.
     
    Tuesday, June 28, 2016 3:06 PM
  • > a user OU, anyone else had any luck with Win10 and User OU policies?
     
    In W10 MS16-072 was not a standalone patch but included in the
    cumulative update.
     

    Hello Martin,

     your reply is puzzling, I did not ask about the status of the patch, I wanted to know if others were able to apply a GPO on an OU that only contained users and did it then work for them.  We have a number of GPO's that are applied to OU's that have no computer objects and on Windows XP, 7 & 8.x they work well but are now broken under Windows 10.

    Is the future path to only have GPO's against computer OU's or top level OU's that have both under them.?

    Peter.

    Wednesday, June 29, 2016 12:00 AM
  • >   your reply is puzzling, I did not ask about the status of the patch, I
    > wanted to know if others were able to apply a GPO on an OU that only
     
    What I meant to say is that in W10, you cannot uninstall MS16-072 on its
    own, so you MUST grant your domain computers read access to your user GPOs.
     
    > contained users and did it then work for them.  We have a number of
    > GPO's that are applied to OU's that have no computer objects and on
    > Windows XP, 7 & 8.x they work well but are now broken under Windows 10.
     
    So what's their exact state in RSoP? In my testing environment, W10 is
    not broken.
     
    > Is the future path to only have GPO's against computer OU's or top level
    > OU's that have both under them.?
     
    Definitely not.
     
    Wednesday, June 29, 2016 11:40 AM
  • I wrote two scripts to deal with this very easily:

    Script to report on and remediate the Group Policy security change in MS16-072: http://www.jhouseconsulting.com/2016/06/22/script-to-report-on-and-remediate-the-group-policy-security-change-in-ms16-072-1627

    Script to modify the defaultSecurityDescriptor attribute on the Group-Policy-Container schema class object: http://www.jhouseconsulting.com/2016/06/29/script-to-modify-the-defaultsecuritydescriptor-attribute-on-the-group-policy-container-schema-class-object-1668

    I hope that helps.

    Cheers,

    Jeremy


    Jeremy Saunders

    Wednesday, June 29, 2016 4:23 PM
  • Am 29.06.2016 um 18:23 schrieb Jeremy Saunders:
    > I wrote two scripts to deal with this very easily:
     
    Wow, a lot of work you did, but let me ask why are you doing such an
    effort to change ACE?
     
    Simply add Domain Computers = Read to ALL GPOs and you are done.
    Thats a powershell oneliner.
     
    - I do not need to get a report, about what should be broken, because I
    directly fixed it, before its get broken
    - a get a consistent Security ACE on every Group Policy Container
    - If you already have read access to a GPO, because AuthUser have read,
    there is nothing wrong to add Domain Computers aswell.
    - what if, an old GPO that does not need to be repaired is edited in
    future an someone removes the AuthUsers? Thats why I would always add
    DomComp to all, without any kind of "if"
     
    Don´t get me wrong, I just wonder.
     
    Adding SD by Script is cool! when managing different customers and
    domain, thanks! ;-)
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Wednesday, June 29, 2016 6:52 PM
  • Mark Heitbrink [MVP] it's because professional IT involves ITIL and Change Management. You can't just run a one-liner PowerShell Script to make the problem go away without doing due diligence!

    From what I've seen in forums and posts there's been too much of a "Cowboy" approach towards remediating this without thought and process.

    After all, how many people are blindly applying these hotfixes, pretty much as soon as they are released, without reading and understanding the KB articles and security bulletins?

    Once again, the script gives you the option of changing ALL GPOs or just the GPOs with user settings. How you apply that is up to you.

    The output of the script may also drive conversation around group policy consolidation/remediation/re-design. People may look at the output and say "Hey, I didn't know we were applying that many GPOs filtered on security groups. Let's fix that!".

    As a consultant I tend to look at things in a different way and provide the right information and guidance to help everyone understand.

    Cheers,

    Jeremy


    Jeremy Saunders

    Wednesday, June 29, 2016 11:41 PM
  • Hi,
     
    Am 30.06.2016 um 01:41 schrieb Jeremy Saunders:
    > it's because professional IT involves ITIL and Change Management. You
    > can't just run a one-liner PowerShell Script to make the problem go
    > away without doing due diligence!
     
    Sure, you can. Because we know, that the change to GP process is
    permanent and not just a fix for a specific timeframe. So changing all
    in once is much more reliable for the future und it fits all your needs
    of being ITIL and report to change management.
     
    Repairing only user settings GPOs or only the broken once, will lead in
    a permanent fixing situtation, when things change.
     
    In future, probably in Server 2016 the SD of GPO will always contain
    DomainComputers additionally.
     
    I think it is a mistake to only fix a little and hope that older things
    will never get broken.
     
    Running the PS Oneliner is not a fix. It´s a concession/acceptance of
    the new GP Process.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 5:50 AM
  • >  > it's because professional IT involves ITIL and Change Management. You
    >  > can't just run a one-liner PowerShell Script to make the problem go
    >  > away without doing due diligence!
     
    > Sure, you can.
     
    Agree with Jeremy - you can NOT "just do it" in a managed environment
    that is subject to ITIL and change management.
     
    Thursday, June 30, 2016 7:25 AM
  • Am 30.06.2016 um 09:25 schrieb Martin Binder [MVP]:
    > Agree with Jeremy - you can NOT "just do it" in a managed environment
    > that is subject to ITIL and change management.
     
    I never said "just do it". I said: Do it once for all.
     
    There is no need to create a change request for every single GPO, that
    will be changed. It´s not a change and manipulation of the single GPO
    that needs to be documentated, it is a complete change in Architecture,
    that causes a Infrastructure change. All objects are efected. The
    GPC/GPT does not care whats inside, it can contain everything. Because
    of that, every GPO can be possibly broken. (Even if you have workflows
    and permissions, that should avoid that ...)
     
    Come on guys, if you update your AD Schema, you only report and document
    the Update itself, but you do not report every single object, thats gets
    new AD Attributes.
     
    Request/Create a change, explain why, run once for all. Done.
     
    Mark
     
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 9:11 AM
  • Thanks Martin Binder [MVP]. I bet even the Nike IS department don't "just do it".

    Mark Heitbrink [MVP]you've been awarded an MVP, so you should show industry leadership and not preach bad practices.

    If you're going to be community focused, hence the MVP award, you need to give correct and professional advice that other IT Pros and Sys Admins will learn from. There's no point posting one-liner PowerShell script (or giving the idea that this is acceptable) into forum posts that are going to make a significant environment change. Those that don't understand what they are doing will copy and paste it, and before you know it have made a major change to a production environment without first recording the current state so that they have a backout plan.

    Cheers,
    Jeremy



    Jeremy Saunders

    Thursday, June 30, 2016 9:17 AM
  • Am 30.06.2016 um 11:17 schrieb Jeremy Saunders:
    > [...] you've
    > been awarded an MVP, so you should show industry leadership and not
    > preach bad practices.
     
    I never said "do what ever you want without changerequest or
    documentation".  The difference is: Despite of yours, my solutionn is
    future-proof, complete and the problem will not happen again.
     
    I am talking about technic, not workflows or processes. People should
    know themselves about their internal workflows. Thats not part of
    interest in this issue.
     
    Sorry, I think you do not get the technical problem.
    It is NOT a single GPO problem for a specific GPO. It is a GP Process
    Infrastructure Problem. It is a general problem, that should be solved
    by a single task with avoiding problems in future.
     
    It is not a "I have 20 broken GPO, I need to fix them"-Problem.
    Where is the benefit of knowing that there a 20,25, 140 or only 3 broken
    GPOs? Fixing only the needed ones is wrong.
     
    You will never know how many actually GPOs will get broken in future.
    You need to fix them all to be prepared for future changes and avoid
    changing/fixing "x" GPOs all with the same problem for the next years.
     
    The only recommandation I can give to a customer is:
    Fix them all.
     
    There is a very good reason, why Enterprise Domain Controllers are
    always in every GPO with read permissions. Now you have a very good
    reason to have Domain Computers inside aswell, per Default.
     
    You create the script to change the SD for New GPOS, with the argument
    to avoid problems in future, but you make changing all existing GPOs
    optional? Thats a little bit schizophrenic. It is not optional, it is
    ogligatory.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 9:47 AM
  • Am 30.06.2016 um 11:47 schrieb Mark Heitbrink [MVP]:
    > The only recommandation I can give to a customer is:
    > Fix them all.
     
    Yes, Martin I hear you. But Microsoft themself do not prepare the AD for
    Multi Tennnat by Default, thats your job. ;-)
    Thats a complete different story. An admin of such a kind of network
    should get the differences himself, otherwise he is the wrong person on
    the wrong place
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 10:54 AM
  • Mark Heitbrink [MVP] you've completely missed the point. This has NOTHING to do with future proofing. The script will cover that. Maybe the "customer" wants to put through two changes?

    No one ever stated putting through a change for each GPO. That would be rediculous.

    It's NOT my job to provide advice on people's Active Directory environments I have not reviewed and am not familiar with. I create a script with options and they apply them using the options they choose based on decisions from reading Microsoft bulletins, forum posts, blogs, etc.

    If I create a script that I publish knowing that someone may run it without parameter(s), I want it to do the LEAST amount of change possible by default. Hence why I have the -Action and -All switches. They can then decide if they want to use the -All and change all GPOs. That's not my decision to make on their behalf. I just provide the vehicle.

    It is also extremely important from a Change Management point of view that there is a "before snapshot" of what GPOs need remediation to continue to work after applying MS16-072. Hence the reason why there is output. How can you represent a change in CAB without that data? Your change may still state that you're going to use the -All switch, and you provide the reason why.

    Your response shows that you lack business process focus, which I find quite unprofessional.

    Cheers,

    Jeremy


    Jeremy Saunders


    Thursday, June 30, 2016 2:42 PM
  • Am 30.06.2016 um 16:42 schrieb Jeremy Saunders:
    > you've completely missed the point.
     
    So did you.
     
    > It is also extremely important from a Change Management point of
    > view that there is a "before snapshot" of what GPOs need remediation
    > to continue to work after applying MS16-072.
     
    Thats a completly different pair of shoes.
    I totally agree, that there needs to be backup and a process annd
    workflow and documentation, but that is not the point of the discussion
    and I do not take care about /their/ processes, thats not a part of a
    forums solution.
     
    There is no benefit in knowing which GPOs is broken, this report has no
    value. Even from a change management point of view you only need to know
    that there is change in GP Infrastructure and thats why you need to
    change all GPOs.
     
    If you correct file server permissions, you do not report every single
    file, you only report the "top level folder".
     
    My entry point to this change/problem/solution is Group Policy Objects,
    not the Group Policy Object like you do.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 3:58 PM
  • > If you correct file server permissions, you do not report every single file, you only report the "top level folder".

    Not every file, but you do need to report on every single sub-folder, especially if you have different groups/departments accessing them.

    The same applies to Group Policy. The GPO being the sub-folder of the top level change you talk about.

    You clearly don't work in Enterprise environments.

    > I do not take care about /their/ processes, thats not a part of a forums solution

    Wow...how can you even make that statement?

    Rather than sitting back and learning from others, you seem to have a gung-ho approach. There is no place for this in IT.

    You show here that you do not deserve to be an MVP because you don't respect the community.

    Cheers,

    Jeremy


    Jeremy Saunders

    Friday, July 01, 2016 12:34 AM
  • Am 01.07.2016 um 02:34 schrieb Jeremy Saunders:
    > Not every file, but you do need to report on every single
    > sub-folder, especially if you have different groups/departments
    > accessing them.
     
    You still think MS16-072 is a single GP Object problem, that you need to
    take care of. It is not. It is GP Infrastructure.
     
    >> I do not take care about /their/ processes, thats not a part of
    > a forums solution Wow...how can you even make that statement?
     
    Every Admin knows how to work in its own environment.
    The only relevant thing here in forum is the solution. Not the process.
     
    > You show here that you do not deserve to be an MVP because you don't
    > respect the community.
     
    Oh, now we are talking about respect? Thats the thing your are missing
    the whole thread to my person. I guess your next post will start with: I
    work since blablabla in blablabla and my **** is bigger than yours ...
    but this is not the point.
     
    You do not understand the technic and impact of the solution. You are
    scared, because of this. You think reporting senseless data can help you
    to get out of the responsibility.
     
    Your homework:
    Create a breakdown scenario where you need to use your backup, report
    whatever, or you are in trouble, when adding "Domain Computer - Read" to
    every GPO.
    (Admins in Multi Tennant would know to use %mycustomer-secgroup% for
    MyCustomer-GPOs, companies with special privacy rules, know on daily
    base, not to use Authusers or Dom*).
     
    Again, again and again:
    You fix the Infrastructure and thats why you only report this part and
    not the single object, efected by this fix.
     
    The only reason, why we have this dispute is that I take a different
    angle to this problem. Back to the files, folder, subfolder example, I
    am one step above your entry point, no matter if we see folders and
    files, of folder and sub-folders or whatever.
    The child is not the target that needs to be reported.
     
    By the way:
    We are not fixing problems after installing MS16-072. GPOs are not broken.
    We adjust the infrastructure to the new processing. There will be no
    step back. Another reason, why your change does not need to report the
    single GPO. Revert the change is not a solution, when it still comes to
    problems (wrong secgroup, computer needs reboot etc)
     
    Mark
    P.S.: I am missing a "popcorn" answer from someone else.
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, July 01, 2016 7:28 AM
  • Mark Heitbrink [MVP] you totally lack respect and understanding.

    Where have I ever said that it's a single GPO problem? You're the one that continually makes that reference just because I believe you MUST report on the current status on each GPO.

    I provide a tool and people can make decisions on how to run it within their environment based on their requirements.

    It's not my job to provide a one-liner PowerShell script to fix everyone's GP infrastructure, because that would be rather irresponsible of me.

    I'm not dictating anything to anyone, unlike yourself, who just tells everyone in forums to run a one-liner PowerShelll script and be done with it! The sad thing is that the younger and less experienced people will take your one-liner attitude and get themselves into trouble because your one-liner script may not function in their environment the way you expected. You're teaching very bad habits. You seem to think that's not your concern. So what value do you provide if you don't teach people process, risk management, etc, regardless of the tech issue?

    Of course you need a roll back plan. That's part of ITIL and Change Management. You MUST be able to report on what you've done so that you know what needs to be fixed if something breaks. Why would you tell people that's not important? Reverting a change may well be a solution in some environments so that they can re-assess, re-test and submit a new change.

    You're just making yourself look like a fool and a cowboy of IT and you disrespect the MVP award you've been given.

    Cheers,
    Jeremy


    Jeremy Saunders


    Friday, July 01, 2016 8:57 PM
  • Am 01.07.2016 um 22:57 schrieb Jeremy Saunders:
    > [...] You're the one that continually makes that reference just
    > because I believe you MUST report on the current status on each GPO.
     
    No, here is why:
    - you already have the state. All enterprise have change management
    (should ...) You report this on creation time or after a change. So, the
    actual state is already know. Why report a secound time?
    - The information about the state is old and the object can not be
    reverted to this state, because of the infrastructure change.
    - Using your backup/Information after applying MS16-072 will break the
    system.
     
    > get themselves into trouble because your one-liner script may not
    > function in their environment the way you expected.
     
    ... thats why I assume, you did not get the impact of this script.
    the oneliner does the same like your "-all", but without report.
    The impact is none, despite of privacy. It´s "read", it is NOT(!) apply.
     
    > You seem to think that's not your concern. So what value do you
    > provide if you don't teach people process, risk management, etc,
    > regardless of the tech issue?
     
    This forum is called: .winserverGP = Technic
    It is not: .itil, .workflowandmanagement or .GPWorkshop or something
    like this. I do this here for free, for the fun of it and because I love
    threads like these.
     
    > Of course you need a roll back plan.
     
    I have: Remove "DomComp Read from all". Done. Impact? None. I removed,
    what I addded before. As I wrote above: Your backup data will not work
    in this special case.
     
    We will not come to the same idea, because I am fixing a different place
    :EOT
     
    Have nice weekend.
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Saturday, July 02, 2016 8:58 AM
  • Hello Martin and others,

     when  I do a GPresult for that user (one of our student test accounts), any of my policies that are only linked to the USER level OU, they are not shown as applied or rejected.  Each of these policies at the user level have no Security filtering, I have added Domain computers to the delegation permissions in desperation but it made no difference.  If I link at the Site OU level then they come to life but that makes filtering to the appropriate users quite complex.  When I go to a Win 8.1 PC (in same computer OU as the Win 10 PC) with the same user and to a gpresult, each of the expected policies is applied and shows up in a GPresult.

    Our topology is like this;

    - Site A OU

       -- User OU

              --- Staff OU

              --- Student OU

       -- Group OU

       -- Computer OU

    - Site B OU

    etc.      Living in hope of some one spotting my obvious mistake : -)

    Regards,

    Peter from down under


    • Edited by ITadmin73 Monday, July 04, 2016 4:07 AM
    Monday, July 04, 2016 1:44 AM
  • Okay,

     after a long of day of looking, it would appear that one of our legacy group policies has some thing in it that conflicts with the recent Window 10 view of the world.  Created a clean top level OU and made sure all computer polices were blocked, moved the computer object to here and now my User OU linked policies fire into life like there was nothing ever wrong.

    Slowly applying the old policies to the new OU to find the culprit and then I can do a scourched earth attack on the offending policy.

    Peter.

    Monday, July 04, 2016 6:37 AM
  • Mark Heitbrink [MVP] For goodness sake. In professional Enterprise IT environments you CANNOT present the change unless you have a report that shows current state. The technicalities of it are IRRELEVANT. You've obviously never worked in an enterprise environment, like a University, or global Oil/Gas/Mining company. You are simply teaching BAD habits to people in forums.

    You're telling people to "trust me; run my one-liner PowerShell script". Are you serious? Of course they need to know their current state, so that if they do the wrong thing or something stops working and they panic, as least they have output to refer back to.

    The path you take to the end state is irrelevant. It's the process that counts. You MUST teach others good practice in forums like this, as I do when I post scripts to my web site. I produce lots of output and heavily comment my scripts to teach others.

    Cheers,

    Jeremy


    Jeremy Saunders

    Monday, July 04, 2016 12:23 PM
  • Am 04.07.2016 um 14:23 schrieb Jeremy Saunders:
    > For goodness sake. [...]
     
    I need to brake my EOT, SCNR:
    ... here it comes, the PS Oneliner. Microsoft "Just do it".
     
    Who broke my user GPOs? Ask Premier Field Engineering (PFE) Platforms
     Probably it´s because they have completly no clue how to work in
    Enterprise, because Microsoft never did ... ? ;-)
     
    I hold on to your process and completly agreed with you the whole time,
    but collecting wrong data is still collecting wrong data. You should not
    ignore technic. Process is not enough for recovery, technic is the much
    more important part.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Wednesday, July 06, 2016 6:32 AM
  • I also have same issue to Win7 clients. I changed my GPO security group to Authenticated Users and problem fixed. But no more security group filtering function works. I was totally frustrated to find the problem at that time.

    Thursday, July 07, 2016 7:53 AM
  • Mark Heitbrink [MVP] you are wrong again! The article lists option 1 and 3 as tongue-in-cheek. Option 2 is what they are guiding users towards. He demonstrates all options but he is never stating that customers should "just do it"! You are misinterpreting his context.

    Have a look at my comment on that article. It aligns with everyone else in the industry accept for you!

    As I have said to you before, you cannot use your method in a professional IT environment. And it's shameful that this is what you teach people via your forum responses.

    Cheers,

    Jeremy


    Jeremy Saunders

    Thursday, July 07, 2016 12:05 PM
  • If you are trying to run this script on a Server 2008 (R2) server, modify the Get-GPPermission and Set-GPPermission to Get-GPPermissions and Set-GPPermissions respectively.  Should work fine.
    Thursday, July 07, 2016 12:48 PM
  • Am 07.07.2016 um 14:05 schrieb Jeremy Saunders:
    > you are wrong again!
     
    Blog and Forum are only about technic. Not process.
    You will never get that point ...
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, July 08, 2016 6:22 AM
  • Am 07.07.2016 um 09:53 schrieb Chan Nyein:
    > I also have same issue to Win7 clients. I changed my GPO security group
    > to Authenticated Users and problem fixed. But no more security group
    > filtering function works.
     
    Because you did it wrong. All articles tell you to add AuthUser or
    Domain Computers "READ"(!!!) permissions. Not APPLY!.
     
    Use the DELEGATION tab, not the security filtering.
     
    If you allow apply to everyone, there can not be a filter for a specific
    secgroup.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, July 08, 2016 6:22 AM
  • Mark Heitbrink [MVP] NO. The technique involves Change Management and doing it the right way. Industry cowboys like you don't get that and will never change your ways. What a shame you misrepresent the good of the industry that attempts to teach and mentor others.

    Cheers,

    Jeremy


    Jeremy Saunders

    Friday, July 08, 2016 8:09 PM
  • Am 08.07.2016 um 22:09 schrieb Jeremy Saunders:
    > The technique involves Change Management and doing it the right way.
     
    Yes, and you should accept that Change management is individual and in
    responce of the customer. Thats the simple reason, why it is not part of
    the solution in technic orientated forum, technet, knowledgebase or
    similar platforms.
    Technic is the lowest common denominator, it stays the same.
    Implementation can not part of the solution, because of individuality.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Sunday, July 10, 2016 9:13 AM
  • KB3159398 completely disrupted all my Windows 7 VM users this morning, by killing Group Policy.  Removed and things are working normally.   What was Microsoft thinking (or testing) to put this out?

    Monday, July 18, 2016 2:57 PM
  • You can run a command to uninstall a Windows update.

    wusa.exe /uninstall /kb:3159398 /quiet /norestart

    Tuesday, July 19, 2016 4:10 PM
  • We have the same problem. However, we use Advanced Group Policy management and you CANNOT add Domain Computers = Read to user Filtered policies OR Authenticated Users = Read. The minute you check them in and deploy them, the security disappears.


    This is a Huge issue.


    lforbes

    Thursday, July 21, 2016 8:05 PM
  • Am 21.07.2016 um 22:05 schrieb lforbes:
    > We have the same problem. However, we use Advanced Group Policy
    > management and you CANNOT add Domain Computers = Read to user Filtered
    > policies OR Authenticated Users = Read. The minute you check them in and
    > deploy them, the security disappears.
     
    Sure you can. You edit GPOs withou change control, so you need to import
    them from production again, like any other time a users works without
    the AGPM plugin.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, July 21, 2016 10:11 PM
  • Am 22.07.2016 um 00:11 schrieb Mark Heitbrink [MVP]:
    > import them from production again,
     
    ... and some steps more :-) See end of article.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, July 21, 2016 10:15 PM
  • Interesting... I was working with my DirectAccess server today, reconfiguring it, and DA solution has a GPO for clients and for servers as part of it. These GPOs are generated by DA wizard configurtion, and during that you specify a Computer Group for DA use. The mechanizm for this inheritance is the same old well known, auth users are removed and custom AD group is used as scope. This is how the DA wizard does it. I let it be as is, and found out that GPO are inherited correctly. And I know that my AD is installed with this patch. So I guess this problem is random?

    As understand, to override this problem, you need to re-add auth users to scope and control inheritance permissions with security delegations, right? Well, at least in DA case I didn´t have to do that.


    • Edited by yannara Sunday, July 24, 2016 4:21 PM
    Sunday, July 24, 2016 4:15 PM
  • > These GPOs are generated by DA wizard configurtion, and during that you
    > specify a Computer Group for DA use
     
    For computer groups in sec filtering, it works as it worked in the past.
    It only is broken for user groups.
     
    Monday, July 25, 2016 10:20 AM
  • Just wanted to say thank you for this thread - was going out of my mind trying to figure out what happened to my build image for it to suddenly reject half the GPOs I use. At least I know whats wrong and there are many helpful advice here that I can use. That'll teach me not to read what the hotfix was for! Its quite a big change for Microsoft to "sneak" out there. 


    Thursday, July 28, 2016 3:52 PM
  • If anyone's interested, I wrote a quick PowerShell script that "fixes" GPO permissions in cases where Authn Users or Domain Computers doesn't exist. Wrote it up here: https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/

    I have no idea if this is considered a bug, or, as the article notes, "by design" and therefore the way things are in the future, but hopefully this script helps folks out there who are urgently trying to fix this.

    Darren


    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"


    Hi All,

    So Do I just execute that PowerShell script:

    From Any AD domain controllers with PS 4.0 ?
    Before applying the KB3159398 or after ?


    /* Server Support Specialist */

    Sunday, July 31, 2016 10:27 PM
  • What a friggin nightmare this is ----------------- Thanks A LOT Microsoft as if we have nothing else to do here.
    Tuesday, August 02, 2016 3:47 PM
  • Hi,

    This problem only occurs on filtered GPOs. I solved the problem by adding read permisions to the authenticated users group in the security filtering. Only read permissions, don't add apply GPO to Authenticated users.

    More info at: https://blogs.technet.microsoft.com/askds/2016/06/22/deploying-group-policy-security-update-ms16-072-kb3163622/

    Kind Regards.


    Tuesday, August 30, 2016 11:17 AM
  • Am 07.07.2016 um 09:53 schrieb Chan Nyein:
    > I also have same issue to Win7 clients. I changed my GPO security group
    > to Authenticated Users and problem fixed. But no more security group
    > filtering function works.
     
    Because you did it wrong. All articles tell you to add AuthUser or
    Domain Computers "READ"(!!!) permissions. Not APPLY!.
     
    Use the DELEGATION tab, not the security filtering.
     
    If you allow apply to everyone, there can not be a filter for a specific
    secgroup.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     

    https://technet.microsoft.com/en-us/library/cc752992(v=ws.11).aspx

    This article said I can remove Authenticated Users from Security Filtering and add the users that I want to apply the policy. But in the reality the policy result said that inaccessible even those users are in the delegation tab. And turned out I have to add back Authenticated Users in the delegation tab with Read permission. Thanks to Carlos Bueno who points out about this.

    Friday, May 26, 2017 2:25 AM