Is it possible to map a drive over 3389 using 2003 TS + remote desktop ?

[scott]

Hi,

Im trying to figure out if its possible to map a drive from a XP workstation
running Remote Desktop connecting to a 2003 terminal server over the net to
port 3389 ?

I understand you can share the workstation "DRIVES" within Remote Desktop
which makes them available under My Computer on the Terminal Server
Desktop - but I need to actually MAP these drive i.e NET USE L:
\\clinet\cdrive so I can run a scheduled batch file.

The batch file will not run unless the drive is mapped as it cant find the
host when the clinet c drive is shared using the Remote Desktop option. When
using Remote Desktop share option the C drive is available on the TS desktop
as an "OTHER" drive.

As Im connecting over 3389 then WINS will not work hence I cant find the
path to \\clinet\share.

Can someone please verify whether this is correct ?

Thanks for your time
Scott.

 

[Robin Walker]

Im trying to figure out if its possible to map a drive from a XP
workstation running Remote Desktop connecting to a 2003 terminal
server over the net to port 3389 ?

I understand you can share the workstation "DRIVES" within Remote
Desktop which makes them available under My Computer on the Terminal
Server Desktop - but I need to actually MAP these drive i.e
NET USE L: \\clinet\cdrive so I can run a scheduled batch file.

On which computer is the batch file to run: the server or the client?

The batch file will not run unless the drive is mapped as it cant
find the host when the clinet c drive is shared using the Remote
Desktop option. When using Remote Desktop share option the C drive is
available on the TS desktop as an "OTHER" drive.

You are confusing Remote Desktop with File Sharing. No, you cannot map
server resources onto a client drive with Remote Desktop. The client
computer is quite unaware of the Remote Desktop session, which is contained
totally within the RDP client application.

[Apart from anything else, this is one of the strengths of Remote Desktop:
no matter what malware is running in the client, that malware cannot access
server resources in the RDP session: it needs to be a server-based
application that performs any data transfer between the two file systems].

If you want to do file-sharing or copying between remote PCs, then you need
to set up a VPN between them. The VPN arrangements will be quite indepedent
of Remote Desktop arrangements. You can set up a scheduled job which will
connect the VPN, run a copy command, and then disconnect the VPN again.

Alternatively, you might arrange for a start-up process in the RDP sessions
on the server to run a timed transfer of data between the local server
disks, and the client file-system mounted as remote drives, so that while
users are logged on via RDP, the transfers take place as timed activities
within their server sessions.

By the way, although your example of a NET USE command above is only an
example, it is bad practice in terms of security to share the root of the C
drive over a network: it exposes very many vulnerabilities, especially if
the share is writable. You should share only the directory you need to
share, and that directory should not be part of the C:\WINDOWS hierarchy, or
include it.

 

[scott]

Thanks for reply.

- On which computer is the batch file to run: the server or the client?

Was initially thinking of the batch file running on the server - looking for
file on client to copy. I guess the client could run batch file and copy to
a server share. But same problem exists over RDP that you cant really use
batch file to copy to a share as shares (map drives) dont work over RDP.

- You are confusing Remote Desktop with File Sharing. No, you cannot map
server resources onto a client drive with Remote Desktop. The client
computer is quite unaware of the Remote Desktop session, which is contained
totally within the RDP client application.

Was thinking of doing it the other way around i.e the TERMINAL SERVER
SESSION finds a path to the clinet share and creates a map drive.

- If you want to do file-sharing or copying between remote PCs, then you
need
to set up a VPN between them. The VPN arrangements will be quite indepedent
of Remote Desktop arrangements. You can set up a scheduled job which will
connect the VPN, run a copy command, and then disconnect the VPN again.

I have setup many VPNs but this customer already has 2003 + Remote desktop
in place so was trying to think of a way around it.

- Alternatively, you might arrange for a start-up process in the RDP
sessions
on the server to run a timed transfer of data between the local server
disks, and the client file-system mounted as remote drives, so that while
users are logged on via RDP, the transfers take place as timed activities
within their server sessions.

This sounds interesting. How would i set this up for a file to be trasfered
from the clinet to the server ?

- By the way, although your example of a NET USE command above is only an
example, it is bad practice in terms of security to share the root of the C
drive over a network: it exposes very many vulnerabilities, especially if
the share is writable. You should share only the directory you need to
share, and that directory should not be part of the C:\WINDOWS hierarchy, or
include it.

Aware of the risks, was just an example as the default file ends up on the c
drive.

Thank for advice.
Scott

 

[Robin Walker]

I have setup many VPNs but this customer already has 2003 + Remote
desktop in place so was trying to think of a way around it.

I assume then you are really talking about 2003 Terminal Services, rather
than Remote Desktop as such.

This sounds interesting. How would i set this up for a file to be
trasfered from the clinet to the server ?

This looks as if it is turning into a Terminal Server configuration
question, and might be better answered by someone else. But on the server,
you can write to files on the client's C drive by referring to UNCs of the
form:

\\tsclient\C\path\filename.ext

provided the client had checked the option "Disk drives" under "Connect
automatically to these local devices when logged on to the remote computer"
on tab "Local Resources" of "Options" before logging in. (normally, an
administrator would save a .RDP file with all these options preset on the
client PC, so that double-clicking it will initiate a TS login with these
options pre-configured.

All you have to do is configure a startup-item for each Terminal Services
session which initiates a process which does a timed copy from a server file
to a UNC of the form quoted above.

 

[scott]

"This looks as if it is turning into a Terminal Server configuration
question, and might be better answered by someone else. But on the server,
you can write to files on the client's C drive by referring to UNCs of the
form:

\\tsclient\C\path\filename.ext

provided the client had checked the option "Disk drives" under "Connect
automatically to these local devices when logged on to the remote computer"
on tab "Local Resources" of "Options" before logging in. (normally, an
administrator would save a .RDP file with all these options preset on the
client PC, so that double-clicking it will initiate a TS login with these
options pre-configured.

All you have to do is configure a startup-item for each Terminal Services
session which initiates a process which does a timed copy from a server file
to a UNC of the form quoted above."


Thanks agian for reply.

Will look around for more information on setup of "UNC" as I have not heard
of this.

Assuming the C DRIVE of the client is available on the TS desktop (via the
method suggested above using Remote Desktop Local Resources), could the UNC
function be designed to copy C:\test.txt from the clinet to the C drive to
TS C drive ?

Thanks
Scott

 

[Robin Walker]

Will look around for more information on setup of "UNC" as I have not
heard of this.

UNC is a syntax for referring to files on a network. Google "Universal
Naming Convention" for more information.

Assuming the C DRIVE of the client is available on the TS desktop
(via the method suggested above using Remote Desktop Local
Resources), could the UNC function be designed to copy C:\test.txt
from the clinet to the C drive to TS C drive ?

The syntax of a suitable copy command would be:

To copy from the server's file system to the client's:

copy c:\test.txt \\tsclient\C\test.txt

To copy from the client's file system to the server's:

copy \\tsclient\C\test.txt c:\test.txt

but (a) I would not recommend using the root directory of C for any of these
transfers, and (b) whether they work or not would depend upon the user's
file access privileges, and a Terminal Services client might not be able to
write or read random places on the Terminal Server.

 

[scott]

RE: copy \\tsclient\C\test.txt c:\test.txt

This will not work because how can the TS find the path to the clinet over
3389 ?

i.e how does it know where to look for \\clinet let alone the \share (no
mater if the share is C or a DIR). Im pretty sure WINS + NETBIOS will not
work over RDP.

CLIENT - running XP pro + remote desktop
|
|
net
|
|
3389
2003 terminal server

Thanks again.
Scott

 

[Robin Walker]

RE: copy \\tsclient\C\test.txt c:\test.txt

This will not work because how can the TS find the path to the clinet
over 3389 ?

It does work. The literal string "tsclient" means the file-systems (all of
them) of the connected client, wherever it is. The next component is the
drive-letter on the client, then the path and filename.

i.e how does it know where to look for \\clinet let alone the \share (no
mater if the share is C or a DIR). Im pretty sure WINS + NETBIOS
will not work over RDP.

This has nothing to do with either NetBIOS or WINS. It is a Terminal
Service feature. It is not implemented using NetBIOS, CIFS, or SMB. It all
happens down the pipe for the terminal session.

 

[scott]

got it......did not reliease you literally menat \\tsclient\c ..... I
thought this meant the client + share name.

thanks for your patience.
Scott