Windows GPO seems to misinterpret thevalue of %temp% in Terminal Services

Hi,

I am attempting to create a directory at login via GPO on a Citrix machines under each users temp location. This location shoud be c:\temp\n where n = the session id for the logged on user.  Using the folder creation GPO (user policy)  and specifying the file to be created as %temp%\filename creates a file in C:\temp NOT c:\temp\n !! Interestingly when you query what the variable %temp% is as the logged in user it is correct, i.e. C:\Temp\n so there is a separate temp location for every user. So it is like at GPO time the system has the wrong value for the %temp% variable and is not taking into account Terminal Services.

Any ideas anyone??
LaV8Asked:
Who is Participating?

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

x
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.

Brian CTXSupportCitrix ConsultantCommented:
Can you check and see if the GPO setting "Do not use temporary folders per session" has been configured?

Policy path:
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Temporary folders
Scope:
Machine
Supported on:
At least Windows Server 2003
Registry settings:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services!PerSessionTempDir
Filename:
TerminalServer.admx

https://technet.microsoft.com/en-us/library/cc732258%28v=ws.10%29.aspx

https://technet.microsoft.com/en-us/library/cc755098.aspx
LaV8Author Commented:
Thanks for your comments Brian,

I'm aware of that setting, but the problem is, we actually require separate TEMP folders per session.  The application in question is custom third-party integration code, which writes temporary XML files to a subfolder of %temp% (the folder name is hard-coded), and having the same effective location for 15-20 users would break this functionality.  I know it uses %temp%, because the same app successfully writes to C:\TEMP in our single-user desktop environment.

Initially, I thought that the Folder Creation User Preference GPO was being applied before Terminal Services was able to change the TEMP variable to point to C:\TEMP\[sessionID].  But, if I log in, then wait a few minutes, then do a GPUDATE (with or without /force), you still get the same behaviour - the folder creation GPO still creates the folder under C:\TEMP, instead of C:\TEMP\[sessionID] (the actual value of %temp%.  This behaviour occurs whether or not the "Run in user's context" option is enabled for the Folder Create GPO.

If you create the folder manually, everything works fine.  But, since our server farm consists of XenApp servers booting from a PVS image, we can't just pre-create the folders, they have to be made on the fly.

Today I'm going to try to sort out a workaround by setting up a login script along the lines of:

IF NOT EXIST %temp%\FOLDERNAME MKDIR %temp%\FOLDERNAME

It's a bit of a kludge, but this is for a new SOE, and we're on a deadline so "if it ain't broke don't fix it" is the rule, and I don't think I have much chance of fixing the GPO behaviour in the next week or so :-)

Any other suggestions or ideas welcome.

Cheers,

-Ben.

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
LaV8Author Commented:
Quick update, the above login script is a successful workaround.  I will continue looking into the aberrant GPO behaviour when I have the luxury of time, and comment back here if I find any root cause, but for now we have our subfolders being created per used session, and the application works.

Thanks again for your input Brian.
LaV8Author Commented:
Workaround that provides the desired result, does not actually explain the GPO behaviour, however.
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
Citrix

From novice to tech pro — start learning today.