Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a terminal server environment exclusively with Windows Server 2008.
My problem is that I need to "map" a drive letter to each users Temp folder. This is due to a legacy app that requries a separate Temp folder for each user but which does not understand %temp%.

So, just add "subst t: %temp%" to the logon script, right?
The problem is that, even though the command runs, the subst doesn't "stick" and the user doesn't get a T: drive.
Here is what I have tried;

The simplest version:

'Mapping a temp drive  
Set WinShell = WScript.CreateObject("WScript.Shell")  
WinShell.Run "subst T: %temp%", 2, True

That didn't work, so tried this for more debug information:

'Mapping a temp drive
Set WinShell = WScript.CreateObject("WScript.Shell")
Set procEnv = WinShell.Environment("Process")
wscript.echo(procEnv("TEMP"))
tempDir = procEnv("TEMP")
WinShell.Run "subst T: " & tempDir, 3, True

This shows me the correct temp path when the user logs in - but still no T: Drive. Decided to resort to brute force and put this in my login script:

'Mapping a temp drive
Set WinShell = WScript.CreateObject("WScript.Shell")
WinShell.Run "\\domain\sysvol\esl.hosted\scripts\tempdir.cmd", 3, True

where \domain\sysvol\esl.hosted\scripts\tempdir.cmd has this content:

echo on
subst t: %temp%
pause

When I log in with the above then the command window opens up and I can see the subst command being executed correctly, with the correct path. But still no T: drive.

I have tried running all of the above scripts outside of a login script and they always work perfectly - this problem only occurs when doing it from inside a login script.

I found a passing reference on an MSFN forum about a similar problem when the user is already logged on to another machine - but I have this problem even without being logged on to another machine.

Any suggestion on how to overcome this will be much appreciated.

share|improve this question

5 Answers 5

If you create a share for the drive where the user profiles are located (typically C:\Users). Assuming the share is PROFILE$, you can then use a script such as:

@echo off
echo.                 TEMP Drive Mapping


:TEMPDRIVE
  echo.                   Mapping Temp Drive...
  if exist T:\  echo Y | subst T: /d 
  if exist T:\  echo Y | net use T: /D
  if exist T:\ goto :TEMPDRIVE_ERROR

  if not exist %temp% MD %temp%
  NET USE T: \\localhost\profiles$\%temp:~9% /P:N  > nul: 2>&1
  if not exist T:\ goto :TEMPDRIVE_ERROR

  goto :TEMPDRIVE_COMPLETE 
:TEMPDRIVE_ERROR
  echo.                  ERROR: Unable to MAP Temp Drive!
:TEMPDRIVE_COMPLETE

:END
:EXIT

GOTO :EOF

Usually %TEMP% is prefixed with C:\Users\ on Windows Server 2008, which is why %temp:~9% is used, to remove that prefix. If using Windows Server 2003, it would be %temp:~12%

share|improve this answer

I'm going to guess that your users have "Administrator" rights and User Account Control is enabled on the Terminal Server.

If that's the case then what you're seeing is a "by design" behavior.

I strongly suspect that your script is running fine. Because User Account Control is enabled the users' filtered token, under which Explorer runs, doesn't have access to the "drives" that were "SUBST" when the logon script ran.

If you're not going to use Group Policy Preferences then you have two choices:

share|improve this answer
    
Thanks for this Evan. Alas, the users are actually standard users. The problem has since changed in that it seems a bit random when it works and when it doesn't, so I now run this in the login script and also from the group policy, meaning that for most users, they end up with a mapping most of the time. It still fails occasionally. Odd, but I can live with it... –  Frans Jan 26 '11 at 23:39
    
@Frans: It was a good try. >smile< –  Evan Anderson Jan 27 '11 at 0:46
    
This resolved my issue with the subst command. I had to use it with both my Admin and User tokens - which was a bit of a hassle... –  Zarepheth 2 days ago

First thing I would try is to map the T drive to something else (like a fileshare you KNOW works) just to eliminate any drive letter restrictions on your system.

Then, if that works, I would try and run the script interactively, that is, upen up a cmd prompt as the actual user and enter the script command/path.

If that also works, we can be pretty sure the script itself works, but script execution at logon might not. Do you have another script you could test with? Also check your GPO settings for asynchronous script execution.

As always, in finding the needle in the haystack: Try and eliminate / isolate all the variables in your environment that might cause this (this is what we did above), f.instance by disabling all GPOs and test again. If it works then, enable one and one GPO in your environment and test again for each change you do.

Sorry I can't be more specific, but the "Isolate and Test" approach is often the quickest way to solve problems such as these.

share|improve this answer
    
Good point - it's just that it does work if I do it any other way than in the logon script. –  Frans Oct 6 '09 at 6:17
    
see edit above. –  Trondh Oct 6 '09 at 13:11
    
Yep, that's the point - if I run any of this interactively it does work. –  Frans Oct 6 '09 at 14:54

VBS with the followign script

'Mapping a temp drive  
Set WinShell = WScript.CreateObject("WScript.Shell")  
WinShell.Run "subst T: %temp%", 2, False

works pretty good on my Windows Server 2008/2008 R2

share|improve this answer
    
Yeah, that's what I tried but it just didn't "stick". Mind you, it's a long time ago. –  Frans Jan 8 '13 at 1:01

Tried mapping it with plain old "net use"?

share|improve this answer
1  
Good idea. How would I do that to %temp%? –  Frans Oct 6 '09 at 6:18
1  
"net use" does not work for mapping a drive letter to a local path. –  ThatGraemeGuy Oct 6 '09 at 15:13
    
Although net use does not work for mapping local paths, if one were to share out a local path, net use could map to the local machine's share. –  Zarepheth 2 days ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.