NBF
asked on
Logon script will not run properly, can't access home drive and delay won't work for 2012 R2 RDS farm
We use GPO to run a logon script that copies outlook signatures from the user's home drive signatures backup folder to the correct location on the RDS server in the user's profile using robocopy. The script is unable to access the user's home drive. I have piped it out to a log file to see what is going on. It appears that Robocopy cannot access the user's H:\ drive during logon. The script works perfectly if the user runs it manually and when the user checks explorer the H:\ is mapped properly. Here is the log when the it is run as part of user logon script:
Started : Wednesday, August 26, 2015 3:05:12 PM
2015/08/26 15:05:12 ERROR 3 (0x00000003) Getting File System Type of Source H:\SIGNATURES BACKUP\
The system cannot find the path specified.
I have tried adjusting the GPO to put in a delay when processing logon scripts but that setting doesn't appear to be working at all. The script always applies immediately when logging in.
Configure Logon Script Delay Enabled
minute: 1
How do I get logon scripts to work properly on windows 2012 R2 RDS? This same process worked perfectly in 2008 R2. Many have complained about the delay in processing logon scripts but I am having the exact opposite problem and can't get the delay to work thinking it might help with access user home drive.
It almost appears to me that the user logon script is running under the computer context and can't access the drive mapping. I am using the user logon script in the GPO so I don't know how that can be.
Started : Wednesday, August 26, 2015 3:05:12 PM
2015/08/26 15:05:12 ERROR 3 (0x00000003) Getting File System Type of Source H:\SIGNATURES BACKUP\
The system cannot find the path specified.
I have tried adjusting the GPO to put in a delay when processing logon scripts but that setting doesn't appear to be working at all. The script always applies immediately when logging in.
Configure Logon Script Delay Enabled
minute: 1
How do I get logon scripts to work properly on windows 2012 R2 RDS? This same process worked perfectly in 2008 R2. Many have complained about the delay in processing logon scripts but I am having the exact opposite problem and can't get the delay to work thinking it might help with access user home drive.
It almost appears to me that the user logon script is running under the computer context and can't access the drive mapping. I am using the user logon script in the GPO so I don't know how that can be.
In the precious comment it should say the GPO is processing the script to copy the files before the drive mappings occur logically.
On the RDS server you can run gpresult /v and get the order the policies are processing.
On the RDS server you can run gpresult /v and get the order the policies are processing.
ASKER
I had tried a lot of this already.
The problem is that the user's home drives are in different locations around the country and I need the script to apply universally. %homedrive% goes to the mapped drive and has the same error message. I can't map the drive manually before the copy because the drive could be mapped to multiple locations which is why I need it to just be H:\
The home drive is mapped via the AD account not a script. This worked perfectly in 2008 R2 with the same GPOs. In 2012 R2 I get the error accessing H:\ during logons script. I've also tried moving it to logoff script and get the same error which doesn't make sense since the drive mapping is visible in the user session.
The problem is that the user's home drives are in different locations around the country and I need the script to apply universally. %homedrive% goes to the mapped drive and has the same error message. I can't map the drive manually before the copy because the drive could be mapped to multiple locations which is why I need it to just be H:\
The home drive is mapped via the AD account not a script. This worked perfectly in 2008 R2 with the same GPOs. In 2012 R2 I get the error accessing H:\ during logons script. I've also tried moving it to logoff script and get the same error which doesn't make sense since the drive mapping is visible in the user session.
Again, not a preferred workaround, but instead of putting the script in a GPO, what about just putting it under the All Users Startup as a batch file. Not necessarily the preferred method, but this at least might be a temp workaround until the other can be sorted out. By doing this, the user session is up and ready and should allow the drive to be mapped correctly.
I don't have a way to recreate your problem here, so it is a bit hard to try to diagnose the cause. See if the above works and then maybe we can work backwards from there.
I don't have a way to recreate your problem here, so it is a bit hard to try to diagnose the cause. See if the above works and then maybe we can work backwards from there.
ASKER
That is so old school I don't even know how to accomplish that on windows 2012 R2. Is there even an all users startup folder on windows 2012 R2? I did a quick search and could not find one.
Also I have managed to get the 2012 R2 logon script delay to work. So now the logon script runs 2 minutes after logon well after the home drive is mapped. I confirmed this by making the script write out to a log and checked the timestamp. 2 minutes after sitting at the desktop the script ran and had the same error which indicates access denied. I am totally stumped now..... Why would robocopy running on a user logon scrip not have access to a drive mapped in the user's session????? Looks like this is not a timing issue with the drive mapping and script but something else.
Also I have managed to get the 2012 R2 logon script delay to work. So now the logon script runs 2 minutes after logon well after the home drive is mapped. I confirmed this by making the script write out to a log and checked the timestamp. 2 minutes after sitting at the desktop the script ran and had the same error which indicates access denied. I am totally stumped now..... Why would robocopy running on a user logon scrip not have access to a drive mapped in the user's session????? Looks like this is not a timing issue with the drive mapping and script but something else.
I think it is in a hidden folder here (All users startup):
C:\ProgramData\Microsoft\W
Wait - access denied. This is probably because the GPO is running as SYSTEM or another users that doesn't have permissions to access the drive? That seems logical to me. I would have to dig to be sure. Maybe the above helps in the meantime.
C:\ProgramData\Microsoft\W
Wait - access denied. This is probably because the GPO is running as SYSTEM or another users that doesn't have permissions to access the drive? That seems logical to me. I would have to dig to be sure. Maybe the above helps in the meantime.
ASKER
That is what I am saying! It seems like logon scripts don't have access to the user context even though they are user logon scripts in the user part of the GPO. The user(me) definately has access to my own home drive and I can run the same command manually from within the RDP session and it works just fine. If it is run as part of the user logon script GPO even if run 1 minute after logon I get that stupid Error 3 which indicated an access problem.
Is the GPO running under the Computer or under the User in the GPO?
Ha! Found it:
Scripts - Startup/Shutdown. You use this extension, located under the Computer Configuration node, to specify scripts that are to run at computer startup or shutdown. These scripts run as Local System.
Scripts - Logon/Logoff. You use this extension, located under the User Configuration node, to specify scripts that are to run when the user logs on or off the computer. These scripts are run as User, not Administrator.
Scripts - Startup/Shutdown. You use this extension, located under the Computer Configuration node, to specify scripts that are to run at computer startup or shutdown. These scripts run as Local System.
Scripts - Logon/Logoff. You use this extension, located under the User Configuration node, to specify scripts that are to run when the user logs on or off the computer. These scripts are run as User, not Administrator.
Scripts - Startup/Shutdown.
--------------------------
You use this extension, located under the Computer Configuration node, to specify scripts that are to run at computer startup or shutdown. These scripts run as Local System.
Scripts - Logon/Logoff.
--------------------------
You use this extension, located under the User Configuration node, to specify scripts that are to run when the user logs on or off the computer. These scripts are run as User, not Administrator.
Better formatted!
--------------------------
You use this extension, located under the Computer Configuration node, to specify scripts that are to run at computer startup or shutdown. These scripts run as Local System.
Scripts - Logon/Logoff.
--------------------------
You use this extension, located under the User Configuration node, to specify scripts that are to run when the user logs on or off the computer. These scripts are run as User, not Administrator.
Better formatted!
ASKER
I have been creating GPOs for years so I have a clear understanding of this. It is a difference in behavior from 2008 R2 and 2012 R2. Same GPOs, different OU, new RDS farm.
The logon scripts are called out in the User side of the GPO under Scripts - Logon/Logoff
The logon scripts are called out in the User side of the GPO under Scripts - Logon/Logoff
Didn't meant to imply you didn't know, but I try not to ever assume :). Anyway found this which seems similar, but I wouldn't think your users would be Local Admins on the RDS boxes, but perhaps it starts to lead towards part of the problem / solution.
Found here: http://itknowledgeexchange
Another very interesting read here: https://rcmtech.wordpress.
The delay is confirmed here: http://blogs.technet.com/b
Now this doesn't explain it running and not having permissions, but certainly does confirm things have changed in how 2012 R2 processes things. It really seems like it has to be security context within which the script is running.
Steps I would try next:
--------------------------
1. As part of the script you are running in the script itself map the drive to a share on a server that is static which as the same permissions as the user home folder and copy a file from that share to the local server, then delete the share (or leave it temporarily if you like) and see if the file works and permissions are OK. If that works, then we can at least know the Login Script is indeed running under the user's context. This would point to the drive mappings not being available in the user's security context until some time after the login finishes. Doesn't make sense to me why this would be, but never know.
2. Create a new user so a new profile is created just to be sure it isn't something related there. Don't think it would be, but never know.
3. Turn on auditing for a user's home share and capture failure events relating to accessing that folder. Then you can at least confirm what ID is trying to access it when it fails.
There are probably more I can think of but that is where I would start.
Found here: http://itknowledgeexchange
Another issue with login scripts that map drives is that if a user is a local administrator of the system login scripts happen prior to the administrator token stripping in Windows Vista/7. This means that the user does not see and cannot access their mapped drives. Conversely, drives mapped under the stripped token cannot be seen by elevated processes. There is a reg hack to allow drives mapped to be seen elevated and non-elevated.
Another very interesting read here: https://rcmtech.wordpress.
Another genius bit of fiddling by Microsoft means that on Server 2012 R2 and Windows 8.1, logon scripts no longer run as part of the logon process. This had me totally foxed for hours. I have my logon script configured via Group Policy.
I believe that it is only GPO configured scripts that are affected, if you’re using the oldskool Active Directory user account configuration then it seems like the scripts keep running as expected whilst the logon process runs through.
If they’re configured via GPO, the new default setting is to run them five minutes after logon. This makes the logon process nice and speedy – shame it leaves your environment potentially unusable for the user…
The delay is confirmed here: http://blogs.technet.com/b
Now this doesn't explain it running and not having permissions, but certainly does confirm things have changed in how 2012 R2 processes things. It really seems like it has to be security context within which the script is running.
Steps I would try next:
--------------------------
1. As part of the script you are running in the script itself map the drive to a share on a server that is static which as the same permissions as the user home folder and copy a file from that share to the local server, then delete the share (or leave it temporarily if you like) and see if the file works and permissions are OK. If that works, then we can at least know the Login Script is indeed running under the user's context. This would point to the drive mappings not being available in the user's security context until some time after the login finishes. Doesn't make sense to me why this would be, but never know.
2. Create a new user so a new profile is created just to be sure it isn't something related there. Don't think it would be, but never know.
3. Turn on auditing for a user's home share and capture failure events relating to accessing that folder. Then you can at least confirm what ID is trying to access it when it fails.
There are probably more I can think of but that is where I would start.
ASKER
Home drive mappings are handled in Active Directory user object. Any system I log on to always has an H:\ to my home drive.
I have tested the delay setting new to 2012 R2/8. I can get the script to run according to that setting(Even 5 minutes later) from the logs. The drive mapping is long mapped by then and it still fails with error 3 running robocopy.
I saw the UAC thing too and switched to testing with a non admin account. Same behavior.
It's not my profile or permissions because all my test accounts are affected by this on the 2012 R2 farm yet continue to run these scripts just fine using the exact same GPO on a 2008 R2 RDS farm.
I have opened a web based incident with microsoft. I just don't understand this and we can't deploy 2012 R2 RDS without logon/logoff script functionality.
I have tested the delay setting new to 2012 R2/8. I can get the script to run according to that setting(Even 5 minutes later) from the logs. The drive mapping is long mapped by then and it still fails with error 3 running robocopy.
I saw the UAC thing too and switched to testing with a non admin account. Same behavior.
It's not my profile or permissions because all my test accounts are affected by this on the 2012 R2 farm yet continue to run these scripts just fine using the exact same GPO on a 2008 R2 RDS farm.
I have opened a web based incident with microsoft. I just don't understand this and we can't deploy 2012 R2 RDS without logon/logoff script functionality.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I thought that was going to be a workaround! I did not know you could use a /home switch! However it doesn't work. I put >>c:\temp\log.txt after the net use h: /home and nothing showed up in the log. It skipped or failed that command and went on to the robocopy. uggggghhhhh
So now I am truly perplexed. Ok - let's go really old school. Copy your batch file to the netlogon folder on your AD controller and set it to run as a login script from the AD profile. At least that confirms it all runs OK on the 2012 server and can be rolled out more easily than perhaps other workarounds.
I will keep pondering on what else it could be. As a side note, it seems that running that commend with redirecting the output does not capture the errors. Dd the same thing on my Windows 8.1 workstation, although the command does work.
I will keep pondering on what else it could be. As a side note, it seems that running that commend with redirecting the output does not capture the errors. Dd the same thing on my Windows 8.1 workstation, although the command does work.
ASKER
I was able to figure this out by starting over with a new GPO. I also found that one of my testing accounts had no home drive set in ADUC so that was hampering my testing.
ASKER
Marking as solution because this allowed me to find my mistake.
Let me know if that gets you to where you need to go.