none
"Add the Administrators security group to roaming user profiles" not working

    Question

  • I'm doing some testing of roaming profiles and have them working. However as an Administrator, I cannot access each user's individual profile folder. I have enabled the GP setting "Add the administrators security group to roaming user profiles" and done a GPupdate on the client PC that I'm using as the first logon device for the user profile creation. GPresult shows that the GPO is being applied, but it still doesn't grant me access.

    I am aware that the policy doesn't apply retroactively and that only folders created AFTER the GPO is applied will grant me access. But I'm testing this by creating the folder multiple times after I've already created the GPO. So that argument doesn't apply.

    After some digging, I found an old thread that stated that the policy must be configured on the client PC that the user is logging onto for the time in order for it to work. So I tried doing that and I was granted access after the profile directory was created.

    But this doesn't seem like the right answer. Yes, it solves the problem. But if you have 500 computers in an organisation, wouldn't it mean you'd have to enable this setting on each and every one of them? No way would an admin want to do that.

    Can anyone shed some light on this?

    Thursday, April 06, 2017 6:12 AM

Answers

  • > Thanks Martin. Just so I understand correctly, you're saying to link the GPO to the OU where the client PCs are contained?
     
    Yes.
     
    > If so, I can't do that due to them being in the "Computers" container in AD. I understand I can move the PCs to the OU I want, but how will this affect any existing GPOs I've set up?
     
    That's one of the reasons why the "computers" container should not be used in a production environment... Anyway - you can link your setting to the domain as well.
     
    Friday, April 07, 2017 1:11 PM
  • OK, I have it working now.

    I didn't want to assign the policy as a Default Domain Policy because I like to avoid that where possible. It allows me to keep track of my policies better. But if I had done it that way, it still may not have worked right away. Here's what I had to do:

    1. I moved all domain computers out of the default Computers container and into their own OU. THis has so far had no impact on any of my policies. Fingers crossed it stays that way.

    2. By following the Technet guide for deploying Roaming Profiles on this page (Step 4), they advise to remove Authenticated Users from the security scope and replace it with a group created earlier in the guide. They then say to add Authenticated Users to the delegation tab so that domain computers will correctly grab the policy (since update MS16-072, domain computers are now included as authenticated users).

    Here's the part they don't tell you: By default, the computer objects in my domain were not trusted for delegation. This effectively makes adding Authenticated Users to the delegation tab of the GPO pointless. So I had to go into the properties of each computer object in AD (thankfully there aren't many), click the Delegation tab and select "Trust this computer for delegation to any service (Kerberos only)".

    3. I logged in as a test user on the client PC and the corresponding roaming profile directory was created. I then was able to instantly access that directory as the domain admin without any issues.

    Maybe allowing the trust for delegation setting is common knowledge among sysadmins, but I'm still learning the ropes and hopefully this will help others in my situation.

    The only strange thing is that even though the GPO is now working, it still doesn't show up as being applied in GPresult. But at this point I don't care.

    • Marked as answer by Oodlemeister Wednesday, April 12, 2017 4:28 AM
    Wednesday, April 12, 2017 4:28 AM

All replies

  • > After some digging, I found an old thread that stated that the policy must be configured on the client PC that the user is logging onto for the time in order for it to work. So I tried doing that and I was granted access after the profile directory was created.
     
    Correct.
     
    > But this doesn't seem like the right answer. Yes, it solves the problem. But if you have 500 computers in an organisation, wouldn't it mean you'd have to enable this setting on each and every one of them? No way would an admin want to do that.
     
    Ever heard about "Group Policy" within a domain? Set it in a GPO linked to the OU where your clients reside and you're done.
     
    Thursday, April 06, 2017 10:34 AM
  • Thanks Martin. Just so I understand correctly, you're saying to link the GPO to the OU where the client PCs are contained?

    If so, I can't do that due to them being in the "Computers" container in AD. I understand I can move the PCs to the OU I want, but how will this affect any existing GPOs I've set up?

    Thursday, April 06, 2017 11:12 PM
  • > Thanks Martin. Just so I understand correctly, you're saying to link the GPO to the OU where the client PCs are contained?
     
    Yes.
     
    > If so, I can't do that due to them being in the "Computers" container in AD. I understand I can move the PCs to the OU I want, but how will this affect any existing GPOs I've set up?
     
    That's one of the reasons why the "computers" container should not be used in a production environment... Anyway - you can link your setting to the domain as well.
     
    Friday, April 07, 2017 1:11 PM
  • Hi,

    I am checking how the issue is going, if you still have any questions, please feel free to contact us.

    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.

    Appreciate for your feedback.

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, April 10, 2017 1:48 PM
    Moderator
  • OK, I have it working now.

    I didn't want to assign the policy as a Default Domain Policy because I like to avoid that where possible. It allows me to keep track of my policies better. But if I had done it that way, it still may not have worked right away. Here's what I had to do:

    1. I moved all domain computers out of the default Computers container and into their own OU. THis has so far had no impact on any of my policies. Fingers crossed it stays that way.

    2. By following the Technet guide for deploying Roaming Profiles on this page (Step 4), they advise to remove Authenticated Users from the security scope and replace it with a group created earlier in the guide. They then say to add Authenticated Users to the delegation tab so that domain computers will correctly grab the policy (since update MS16-072, domain computers are now included as authenticated users).

    Here's the part they don't tell you: By default, the computer objects in my domain were not trusted for delegation. This effectively makes adding Authenticated Users to the delegation tab of the GPO pointless. So I had to go into the properties of each computer object in AD (thankfully there aren't many), click the Delegation tab and select "Trust this computer for delegation to any service (Kerberos only)".

    3. I logged in as a test user on the client PC and the corresponding roaming profile directory was created. I then was able to instantly access that directory as the domain admin without any issues.

    Maybe allowing the trust for delegation setting is common knowledge among sysadmins, but I'm still learning the ropes and hopefully this will help others in my situation.

    The only strange thing is that even though the GPO is now working, it still doesn't show up as being applied in GPresult. But at this point I don't care.

    • Marked as answer by Oodlemeister Wednesday, April 12, 2017 4:28 AM
    Wednesday, April 12, 2017 4:28 AM