Unable to use GPO to place SomeFilename.RDP onto user Desktops

[Cerulean]

Greetings,

In our fully VDI and ESXi vSphere environment, user profiles are pulled from \\server-persona1.domain.local\Profiles\%username%\ (stores the Documents, Music, Pictures, Desktop, Favorites) and \\server-persona1.domain.local\AppData\%username%\AppData when they login to their VDI through VMware View Client.

What I am trying to do is having a GPO put a file "Legacy Applications.RDP" on to their desktop. When I do %userprofile% in CMD it returns "C:\Users\username". When I want to save a file and click on "Desktop" in the left pane of the Save As window, it takes me to \\server-persona1.domain.local\Profiles\username\Desktop\.

I have tried putting my "Legacy Applications.RDP" file at \\domain.local\NETLOGON and \\domain.local\SYSVOL\domain.local\ and using the following (right click on GPO --> Edit --> User Configuration --> Preferences --> Windows Settings --> Files):

Doesn't work. I have checked, and the Effective Access that Authenticated Users have is the standard Read + List folder contents + Read & execute

 

[XOR != OR]

First, I'd recommend you put a shortcut to the file on the netlogon share.

Second, use the %DesktopDir% variable, instead of spelling out the network location.

However, if you are insistent on getting this to work, check the event log. It should at least give you an error ( albeit not that helpful sometimes ) about what's going on.

 

[calvinj]

Used GP to create the shortcut..

mstsc /v legacy application

Name the shortcut

 

[Cerulean]

Used GP to create the shortcut..

mstsc /v legacy application

Name the shortcut

We would like the login username and some RDP properties pre-defined though. mstsc doesn't have a /user parameter

EDIT: Neither work and there are no related entries in eventvwr. When I do gpupdate /force, it says it has updated some things and asks if I would like to log off.

 

[XOR != OR]

Your shortcut isn't right. The target should be the full pathname to the RDP file you want. ie: "\\domain.local\netlogon\Legacy Applications.rdp"

Still, there should be something in the event log on the client. Have you given the policy enough time to propagate to the site in question? Do the AD and sysvol versions agree with each other? If so, on the client, run gpresult /h results.html, open results.html and find out what is and is not applying to the local workstation/user

 

[Cerulean]

Your shortcut isn't right. The target should be the full pathname to the RDP file you want. ie: "\\domain.local\netlogon\Legacy Applications.rdp"

Still, there should be something in the event log on the client. Have you given the policy enough time to propagate to the site in question? Do the AD and sysvol versions agree with each other? If so, on the client, run gpresult /h results.html, open results.html and find out what is and is not applying to the local workstation/user

Doesn't make sense. X_x I will need to lookup a Microsoft webpage that identifies what each field is for. Right now I'm totally shot, brain running at 1 MHz (very tired and exhausted; overworked)

 

[XOR != OR]

I'm ignoring the file copy part, just looking at the shortcut.

Target Path in your second pic should be "\\domain.local\netlogon\Legacy Applications.rdp". This will run the RDP file directly, no need to invoke mstsc /v.

 

[k1pp3r]

Are all your VDI's windows7 or do you have XP ones out there?

 

[Cerulean]

Are all your VDI's windows7 or do you have XP ones out there?

We only have Windows 8 VDIs. Almost all our virtual servers are Windows Server 2012 Enterprise/Datacenter. We have a couple or few Windows Server 2008 R2 Enterprise/Database ones.

 

[Cerulean]

I'm ignoring the file copy part, just looking at the shortcut.

Target Path in your second pic should be "\\domain.local\netlogon\Legacy Applications.rdp". This will run the RDP file directly, no need to invoke mstsc /v.

Did I do it right this time? It still isn't working -- I must have done something wrong

This time I utilized http://technet.microsoft.com/en-us/library/cc753580.aspx for additional clarification on fields for creating a Shortcut Item.

(File Item documentation can be found at http://technet.microsoft.com/en-us/library/cc772536.aspx)

 

[XOR != OR]

Um, you're getting there. Look here:

In yours, put the data you have in "Name:" in "Target Path". Change the drop down box "Location" to "Desktop" ( do this first, as it wipes out the data in "Name" ). Then give your shortcut a name ( Legacy Applications? ), no file extension.

That should do it, barring some other oddity. Remember that policies need some time to propagate before they are applied, so give it about 5 minutes ( assuming the DC you are modifying GPOs on is in the same site as your client ).

 

[Cerulean]

I tried this, with a gpupdate /force several hours later, into a fresh VDI login:

It didn't work. I am able to access \\domain.local\NETLOGON\ and see and be able to run the file "Legacy Applications.rdp" just fine from the VDI under my test user.

 

[XOR != OR]

That looks correct. Now we run gpresult /h test.html on the client. Open the resultant test.html file, make sure the GPP is either being applied or erroring out. If erroring out, post the error code here.

Quick question; this policy is attached somewhere above the user account that you are trying to apply this to, right? In the domain hierarchy? If not, do you have loop back processing turned on?

 

[Cerulean]

That looks correct. Now we run gpresult /h test.html on the client. Open the resultant test.html file, make sure the GPP is either being applied or erroring out. If erroring out, post the error code here.

Quick question; this policy is attached somewhere above the user account that you are trying to apply this to, right? In the domain hierarchy? If not, do you have loop back processing turned on?

I do not know what loop back processing is, but somebody has a GPO for that:

Here is the test.html file: http://www.hlrse.net/Qwerty/ad2008-12_GPO_FilesPush7.html

In the GPO's security filtering ("RDP to old censored for legacyapps") I have it linking to a security group called DIVISION_app_dummyTest in which I and an account 'dummy2' (what I have been using to test with) is a member of. 'dummy2' is not a Domain Admin (unlike I). I haven't had success on my own name either.

 

[jtr8178]

Make sure everyone on your domain has READ permission on the file you want to copy over ... I had the problem where it wouldn't copy a file over, and I had to go reset all the file permissions on it.

 

[XOR != OR]

I do not know what loop back processing is, but somebody has a GPO for that:

Here is the test.html file: http://www.hlrse.net/Qwerty/ad2008-12_GPO_FilesPush7.html

In the GPO's security filtering ("RDP to old censored for legacyapps") I have it linking to a security group called DIVISION_app_dummyTest in which I and an account 'dummy2' (what I have been using to test with) is a member of. 'dummy2' is not a Domain Admin (unlike I). I haven't had success on my own name either.

Your link indicates that this policy isn't being applied to your dummy2 account. It's not listed under the Applied GPOs for the user ( the two denied GPOs, while not named, don't appear to contain any settings anyway, so I'm guessing neither one is the policy in question ).

So that's your next step; figure out why dummy2 doesn't see this policy as being applied to them. Remember your policy precedence: http://technet.microsoft.com/en-us/library/cc785665(v=ws.10).aspx . You need the GPO to be linked somewhere above the user for it to apply ( ou(s), domain, site ).

For now, let's ignore loopback processing.

 

[Cerulean]

I don't know how to do that or where to look; this is to the point where it is beyond my understanding.

EDIT: Ha, I think I got it! I needed to link it to an OU, so I linked it to our OU that identifies our division

 

[XOR != OR]

I don't know how to do that or where to look; this is to the point where it is beyond my understanding.

EDIT: Ha, I think I got it! I needed to link it to an OU, so I linked it to our OU that identifies our division

There you go. Link it somewhere in the hierarchy, and it should apply.

 

[cyr0n_k0r]

Attempt to remove spaces in the target path. Change the RDP file to

LegacyApplications.rdp
instead of
Legacy Applications.rdp

and see if that works.

 

[Cerulean]

There you go. Link it somewhere in the hierarchy, and it should apply.

As the screenshots are, it places the "Legacy Applications.rdp" file on Desktop. Great!

However, it isn't mapping a Z:\ drive to \\172.15.30.35\AppDocs. According to gpresult, it maps it successfully but then deletes it (not sure why).

EDIT: I got it to where it doesn't do that.. it says it successfully maps it... but it doesnt.

 

[Cerulean]

okai, I give up. The GPOs for this network are jacked. It takes 2-3 GPOs just to get the G:\ drive mapped apparently

 

[XOR != OR]

okai, I give up. The GPOs for this network are jacked. It takes 2-3 GPOs just to get the G:\ drive mapped apparently

Well, be honest; you don't exactly know what you're doing, do you?

Let's not blame the tools here.

 

[Cerulean]

Well, be honest; you don't exactly know what you're doing, do you?

Let's not blame the tools here.

True, not at deeper levels. By no means would I consider myself an expert or certified professional with GPOs of AD. Your help in this thread has alone increased my knowledge significantly, and I am extremely grateful for your help. It is a blessing that someone like you has taken the time to offer your expertise and guidance through this whole thread; this is priceless and invaluable.

I and no one in my department created any GPOs with the exception of the one I am presenting in this thread. Without criticizing anyone for incompetency (knowing that I am no better), what is definitely clear to me is that there are some GPOs that apply the same thing (twice in the end). When I disable that other GPO for the G:\ drive, the policy for Default Domain Policy on mapping the G:\ drive suddenly doesn't work. As for my Z:\ drive, at one point in my troubleshooting the gpresult was showing that it was getting deleted right after a successful mapping. I got to a point where it stopped showing that in gpresult, said that it successfully applied action on creating (actually "replace"'ing) the Z:\, but was nowhere to be found under Computer.

I am also slowly realizing that as far as the VDIs go, apparently nothing under Computer Configuration is passing through (i.e. if I tried to have scripts be run or whatever).. but I haven't fully confirmed that.

My co-worker said that this is normal of AD to have problems mapping network drives, and I only partially believe him because I am aware of this, but want to refuse to believe it, especially for AD 2012. I would more easily accept this if it were AD 2003. I believe that there is a valid reason as to why these problems happen -- there has to be -- things don't exactly just happen by chance (well technically there is some randomness, but it isn't very common -- more visible in applications where extreme precision and accuracy are a must).

EDIT: I also like to think that perhaps there may be people on the internet that would find this thread very resourceful, useful, and perhaps solve their problem or answer some of their questions.

 

[/usr/home]

I recommend leaving the default policies alone and creating new ones and then linking them to the proper OUs.

I've also never had issues napping drives with GP.

I'd recommend writing down a list of what you want to accomplish with GP and then deleting all the policies/ setting them to default and start with one policy. Also, too many policies can mess up the loading of the policies. We also use multiple policies. We have one for mapping printers, one for software installation, one for installing specific one off software, etc. it makes it easier to manage. AD groups are your friends. Use them.

GP can be a real bitch sometimes and I'm not even a super expert of it.

 

[XOR != OR]

I recommend leaving the default policies alone and creating new ones and then linking them to the proper OUs.

I've also never had issues napping drives with GP.

I'd recommend writing down a list of what you want to accomplish with GP and then deleting all the policies/ setting them to default and start with one policy. Also, too many policies can mess up the loading of the policies. We also use multiple policies. We have one for mapping printers, one for software installation, one for installing specific one off software, etc. it makes it easier to manage. AD groups are your friends. Use them.

GP can be a real bitch sometimes and I'm not even a super expert of it.

You make a good point about planning ahead, that's critical. I have also broken my policies down in the same way you do. I have one for shortcuts, one for registry settings, one for drive maps, ect...While I'm sure applying 10 policies at login/startup slows things down a tad, the ease of administration is worth the tradeoff ( and there are ways to mitigate these policy application times ).

And Cerulean, my comment sounded snarky after I reread it. Sorry about that. There's really nothing wrong with ignorance, as long as you are working to correct it, as you are. Feel free to ask any questions you may have, and understand that we've all been through that frustration of trying to get things working that aren't.