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.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

It is probably a simple matter of the mappings not occurring logically in the script until after the attempt to copy the signatures.  The very simple fix is to simply script a command to map the drive, copy the files, and the delete the drive.  Allternatively you shoild be able to just copy the files using the UNC path if you had to.  I think you can substitue %USERNAME% or %HOME% (I am not near a pc to look them up as I am doing this on a phone).

Let me know if that gets you to where you need to go.
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.
NBFAuthor Commented:
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.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

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.
NBFAuthor Commented:
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.
I think it is in a hidden folder here (All users startup):

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

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.
NBFAuthor Commented:
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.

Better formatted!
NBFAuthor Commented:
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
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.techtarget.com/itanswers/logonlogoff-script-setup-as-group-policy-not-running-server-2008/

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.com/2014/01/24/logon-scripts-do-not-run-at-logon-server-2012-r2/

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/platformspfe/archive/2014/03/08/windows-8-1-logon-script-delay-group-policy-setting.aspx

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.
NBFAuthor Commented:
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.
Wait - your drive mapping is set in AD, and the system will pull it, however for some reason I think we had a similar problem before and we corrected it by mapping the drive in the script.  If the H: drive is set in AD, for the login process to see it (at least in our case) we had to map it in our script -OR- maybe it will work in group preferences.

So I see the problem.  

Try using the following in your batch file prior to copying the file:
net use H: /home

This will read the home directory from AD and map the drive letter H: to it.  I have had to use it in a few places myself.  I cannot give you the technical reason for it not to work the way you have it, but I know I have run across this before.

Almost the same issue here:https://social.technet.microsoft.com/Forums/windowsserver/en-US/1ae5b9a1-9be5-4b36-bfa7-ef9b1bbd3a59/gpo-ad-home-folder?forum=winserverGP

It is something to do with the way the script is interacting with the mapping from AD.  If you force the mapping in your script you can ensure the H: drive is mapped the /home folder prior to doing your file copy and them you can net use H: /delete to remove it when it is done, although it won't hurt to leave it since it will be mapped anyway.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
NBFAuthor Commented:
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.
NBFAuthor Commented:
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.
NBFAuthor Commented:
Marking as solution because this allowed me to find my mistake.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.