0

I am taking over our entire Microsoft based management, this includes our AD servers, GPOs, etc.

So with that being said, I don't know everything about how this setup is configured. However, I have noticed that we seem to be having a lot of permissions based issues with GPO's, or with users that can't change their own attributes on their account. I believe the issue stems from SYSVOL being inaccessible according to Group Policy Management tool, but not sure. SYSVOL itself is available according to "net share".

I don't know of a sure fire way to go through and automatically check "basic" permissions on accounts, to verify that they have access, however I have double checked that the "Authenticated Users" group has at least read permissions on all GPOs. I have run dcdiag and repadmin. The results of dcdiag which can be found here:

Datacenter Master Domain Controller
Office DC

repadmin results show that everything was completed successfully. There are no errors on any of the servers.

When a user applies does a "gpupdate.exe /force" and the computer reboots (as we do software installs) and when I go to look at "gpresult.exe /z" under their own account, I always see the only applied policy as "Default Domain Policy" there is nothing else.

For instance, I have created a "Allow non-administrators to install Printers" GPO that is applied to "domain.net/user/test" OU which is currently set to linked and enforced. I then run "gpupdate.exe /force" followed by "gpresult.exe /z" it doesn't respond. If I then duplicate our "Default Domain Policy" and modify the settings to represent what I had in the "Allow non-administrators to install Printers" GPO, and call it "Non-admin installation of printers" it is successfully applied. Below are the photos of said GPO:

(apparently I can't post any more links to the photos)

Anyways, hopefully you get my point at this time.

  • I have noticed that we seem to be having a lot of permissions based issues with GPO's, or with users that can't change their own attributes on their account. I believe the issue stems from SYSVOL being inaccessible according to Group Policy Management tool - These two things aren't really related to each other. Is your problem with the application of Group Policy or with users modifying attributes of their user accounts? Did you move a user account to the OU where you linked your new GPO? – joeqwerty Apr 19 '16 at 0:29
  • @joeqwerty - Unfortunately both. We have a problem with one user modifying their user attributes on their own account. We also have a secondary problem of application of group policies. Yes, users and computers are in the appropriate OU where the group policy is applied. – Andrew Apr 20 '16 at 17:49
0

Regarding the GPO issue, you say that Authenticated users are set to Read on all GPOs, have they also been given the Apply permission? both will need to set before the GPO applies. Make sure the users / computers are in the OU where you link the GPO or that you link the GPO to the domain level.

SYSVOL is important for GPOS, it is where the Group Policy Templates live and are replicated from there t other DC's, this problem sounds more like a permissions problem or a problem of where the policy is linked.

  • Hey @Michael Brown. Thanks for the response. I just checked the permissions for "Authenticated Users" group on all of the group policy objects, and they do indeed have "Apply Group Policy" checked for "Allow". As far as the SYSVOL directory, I am not sure I understand what you mean by where the policy is located. They are all located in the SYSVOL directory, and on top of that, if I go into the proper directory it appears as the new GPOs themselves are still being placed in the SYSVOL folder on different DCs even though it says inaccessible. – Andrew Apr 21 '16 at 21:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.