BRI-Consulting
asked on
Server 2008 Terminal Server in 2003 domain not mapping network drives for Domain Admins
I have a new 2008 R2 Terminal server running in a 2003 domain with a group policy assigned to map network drives at Log-on via a VBScript. The Policy is applied to my test OU and works flawlessly when my test account is a domain user. If I make the test account a member of the domain admins - the policy is processed (confirmed via GPResult), but the drives are not mapped at log-in. If once logged, in I manually run the VBScript, the drives are mapped successfully. I found another Experts Exchange member who had a similar issue and the case was closed with his response of "Admins get different profiles than Users".
*Domain Admins is currently a requirement for accounts accessing this terminal server, removal is not an option.
*Domain Admins is currently a requirement for accounts accessing this terminal server, removal is not an option.
Darius Ghassem
When you are running Domain Admins accounts GPOs are not applied sometimes. What you can do is go to the Permissions of the GPO then add Domain Admins and select Apply Group Policy
Best practice would say that a) Domain admins should never need to log on to a server as a "USER" and therfore have the GPO's of a standard user apply AND b) That if they DO Need to log in then they should run any scripts MANUALLY, like you have to now, so that you do not bring your network to its knees when you make any mistake in a GPO.
Imagine making a mistake in a GPO that prevents users from logging into a server. Your GPO gets applied to your addministrators..... The server is your ONLY DC? OOOPS!
Very bad practice to have standard GPO's apply against domain admins!
Imagine making a mistake in a GPO that prevents users from logging into a server. Your GPO gets applied to your addministrators..... The server is your ONLY DC? OOOPS!
Very bad practice to have standard GPO's apply against domain admins!
P.S.
Your domain administrator account, there should be 2 and only 2 (One as a backup incase of lockout) Should be used ONLY for what it says on the tin. Administering the Domain.
If John Smith is your domain admin then he should have 2 AD Accounts. John.Smith (A user) and John.Smith_DA the Domain admin.
Your domain administrator account, there should be 2 and only 2 (One as a backup incase of lockout) Should be used ONLY for what it says on the tin. Administering the Domain.
If John Smith is your domain admin then he should have 2 AD Accounts. John.Smith (A user) and John.Smith_DA the Domain admin.
ASKER
Thank you Neilsr, believe me, I'm working on the issue with the 3d party software that has my hands tied. Thank goodness that the GPO is not applied at the domain level, only at the OU, and it only maps drives.
Dariusq, I'm testing your solution now. Indeed Domain Admins did not have Read or Apply Policy enabled. I've check the boxes and checking it out now.
Dariusq, I'm testing your solution now. Indeed Domain Admins did not have Read or Apply Policy enabled. I've check the boxes and checking it out now.
There *should* be no difference between users and admins of whatever kind at all.
Use rsop.msc at the server to make sure your script really gets applied.
Use rsop.msc at the server to make sure your script really gets applied.
ASKER
McKnife:
I did indeed check that out prior to posting: Last executed is today and time is last log-on.
dariusq:
Added read and apply policy, refreshed, logged off, logged on - No drives showing.
I did indeed check that out prior to posting: Last executed is today and time is last log-on.
dariusq:
Added read and apply policy, refreshed, logged off, logged on - No drives showing.
Post Gpresults;
Don't think they will apply to Domain Admins should only be Domain Users.
Don't think they will apply to Domain Admins should only be Domain Users.
ASKER
Attached is privacy edited GPResults. GPResult---Domain-Admin-not-mapp.txt
@darius
> Don't think they will apply to Domain Admins should only be Domain Users
So your domain admins are no members of domain users/authenticated users? That's not the default.
@BRICons.
Did rsop tell you the script got executed? You confuse me: where would rsop tell you "last executed on..."?
If yes, use auditing on the script file itself to see if admins do indeed touch it.
> Don't think they will apply to Domain Admins should only be Domain Users
So your domain admins are no members of domain users/authenticated users? That's not the default.
@BRICons.
Did rsop tell you the script got executed? You confuse me: where would rsop tell you "last executed on..."?
If yes, use auditing on the script file itself to see if admins do indeed touch it.
Well you are running logon scripts states that they run and apply
GPO: Map Network Drives
Name: map officer network drives.vbs
Parameters:
LastExecuted: 7:26:31 PM
Certain GPOs will not apply to Domain Admins but logon scripts should apply. Since you added the Apply Permissions then you should see the network drives. Plus if you look in the GPresults you can see the login script being executed
GPO: Map Network Drives
Name: map officer network drives.vbs
Parameters:
LastExecuted: 7:26:31 PM
Certain GPOs will not apply to Domain Admins but logon scripts should apply. Since you added the Apply Permissions then you should see the network drives. Plus if you look in the GPresults you can see the login script being executed
You say that the policy is applied at the OU level? As the drive maps are in the USER section of your OU I assume that this OU contains all of your domain users? Including Domain admins ?
ASKER
I have a test OU with my test account in the OU (test account is a member of Domain Admins security group). Once I get the network drives to display, I'll move the policy to the general population.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
May I clarify something:
The key http://support.microsoft.com/kb/937624 mentions has nothing to do with mapping network drives. It has to do with UAC not creating linked tokens. So as long as your login script does not trigger UAC (login scripts should NEVER do this, otherwise they are not compatible with standard users), this regkey should have (no, "will have") no effect on your script.
Does your script elevate any actions, i.e. make use of administrative privileges?
The key http://support.microsoft.com/kb/937624 mentions has nothing to do with mapping network drives. It has to do with UAC not creating linked tokens. So as long as your login script does not trigger UAC (login scripts should NEVER do this, otherwise they are not compatible with standard users), this regkey should have (no, "will have") no effect on your script.
Does your script elevate any actions, i.e. make use of administrative privileges?
ASKER
McKnife:
Its a standard VBScript to map drives. Nothing special. Worked perfectly for domain users, but failed for domain admins security group.
I'd draw your attention to the last paragraph;
"When network shares are mapped, they are linked to the current logon session for the current process access token. This means that, if a user uses the command prompt (Cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token. "
I made the registry entry, rebooted, and without making any other changes in-between, I now see my mapped drives when logging in with my test account as a member of the domain admins security group.
Its a standard VBScript to map drives. Nothing special. Worked perfectly for domain users, but failed for domain admins security group.
I'd draw your attention to the last paragraph;
"When network shares are mapped, they are linked to the current logon session for the current process access token. This means that, if a user uses the command prompt (Cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token. "
I made the registry entry, rebooted, and without making any other changes in-between, I now see my mapped drives when logging in with my test account as a member of the domain admins security group.
That was the same paragraph I was clarifying.
> the network share is not mapped for processes that run with the full administrator access token
...and that's not the case here. So if it works indeed, it's merely a bug but not working as designed. The admin does not use the aforementioned token unless he elevates. net use does not need elevation.
> the network share is not mapped for processes that run with the full administrator access token
...and that's not the case here. So if it works indeed, it's merely a bug but not working as designed. The admin does not use the aforementioned token unless he elevates. net use does not need elevation.
ASKER
Located resolution on Microsoft support site, KB 937624. Tested resolution and drives are displaying at this time.