• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 302
  • Last Modified:

Server logon accounts are mapping drives now that we switched to group policy site policies to map drives. How do we avoid this?

I just changed the way users map drives, by running the login script through group policy based on the site the user is in instead of the profile tab in active directory.  This now allows our users to move between offices and map the correct set of drives based on their location.  The downside I have just come accros is, now my service accounts for servers now run the login script and map drives.  Is there any way to avoid this?  What are my other options?
0
ohmErnie
Asked:
ohmErnie
  • 5
  • 4
  • 3
  • +1
2 Solutions
 
Network_Data_SupportCommented:
if you had done it on an OU you could move the accounts to a different OU
0
 
ohmErnieAuthor Commented:
The problem with doing it by OU is we would have to move the user to a different OU when they go to a different office.
0
 
Network_Data_SupportCommented:
how many clients you got that swap to different locations
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
MSE-dwellsCommented:
When you say 'service accounts', do you mean these accounts are used _exclusively_ by services running under their context (and never used by regular users)?  If so, place all service accounts in a security group so they can be referred to collectively deny the group access to the necessary policies.

There are too many ways to mention to achieve your requirement, the one I've posted covers most bases I hope.
0
 
ohmErnieAuthor Commented:
what I mean by service accounts is really administrative accounts for logoning onto the servers and running some services.  So you would you are saying create a Security Group in AD and make them all members, then under the policy deny the Group just created?
0
 
MSE-dwellsCommented:
Nod, precisely.
0
 
Network_Data_SupportCommented:
that do it
0
 
itquestionsCommented:
In the GPMC under the delegation tab, you can add computers or groups to that list.  From there, you can select advanced and deny read/apply access for those systems.
0
 
ohmErnieAuthor Commented:
Is there anyway to deny the policy by AD container?

So say my Member Servers would run the policy.  Where it is going to get tricky is with the domain controllers.  I cannot deny them..
0
 
itquestionsCommented:
You could add the computers by name.  This could become cumbersome if you have many systems, but it will work.

You cannot deny by AD container, those are just organizational hierarchies.  You would have to add the servers to a group and then you could deny apply access to that group.
0
 
ohmErnieAuthor Commented:
Or...what if I created a new AD Site just for servers?  Right now I have sites just setup as different physical locations.  I would not need a site policy on the server site and thus no logon script would run.
0
 
itquestionsCommented:
Per M$ best practices on AD, you should have two top level containers for Servers.  One for Domain Controllers and one for Member Servers.  Inside the members servers, you could break them down by function (exchange, terminal server, web, etc.).

Depending on how many gpo's you have, be careful about nested groups.  Too many nested groups may cause some policies not to be applied.
0
 
ohmErnieAuthor Commented:
I tried creating a computers only group and added the computer accounts, then denied them in GPMC, but the scripts still ran.
0
 
itquestionsCommented:
By default, windows creates an AD container called 'computers'.  Try a different name.  If the gpo is top level to the domain (meaning that the newly created container(s) will inherit the gpo), then go into that gpo's delegation tab, add the computer(s) or group, then click advanced in the bottom corner on the delegation tab and deny apply/read access to that gpo.

Remember that you if you want to test whether it is being applied, you have to run gpupdate /force from the command prompt, or wait 60 minutes for the computers to refresh themselves.

Then you can run gpresult to see what applied.  The gpresult will say under the computer configuration that the policy was denied.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 5
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now