Copy to Local user's downloads folder from within a remove server RDP session 1

[Rajesh Karunakaran]

Dear all,

I am connecting to a remote server using RDP.
In RDP connection, I have selected the local user C drive to be used from within the server.
If I use GETDIR() from server, I can see the user's local pc C drive.

Now, is there any way to know the local logged in username from within the remote server?

Basically, I want the application in the server to copy a file to the local PC user's 'Downloads' folder.

If I can determine the current local user, then I can construct a destination folder something like '\\tsclient\c\users\rajesh\downloads\\'. Here, as we know, 'rajesh' is the logged in user in the local pc where as the user used to log into the remote server may be different, say, 'UserOne'.

Any thoughts?

Thank you in advance,
Rajesh

 

[Chris Miller]

What about the values of GETENV("UserProfile"), ID() or GETENV("UserName")?

Chriss

 

[GriffMG]

You can determine the user name on the remote machine - is that what you are asking?

? getenv("username")

will give you the local user name on the TS server

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Chris Miller]

Griff,

glad that you pointed this out:

local user name on the TS server

That's the TS username. But in a usual situation of a terminal server used within a corporation for LAN or WAN users, this should be identical to the username of the client logged in. And therefore this name is valid for the client side, too.

If you absolutely want to make sure you catch the right local user profile in cases something off standard is configured, you could also map a drive to the userprofile locally on the client, for example:

SUBST U: %USERPROFILE%

before starting the remote session, share the drive U: and have access to the user profile with \\tsclient\U
Chriss

 

[Rajesh Karunakaran]

Chriss, Griff,

I think, I have not explained it properly.

The user connects to the server through RDP and launches the application present in RDP.
Everything runs in the remote server. Now, GETENV("UserName") will give the user name of the server which the user used in the RDP connection.

Basically, the remote application generates a report in PDF and saves it in a server folder. But, I want to copy the file onto the user's local machine also as the user wants the file in his local pc for further actions on it.

Rajesh

EDIT: I had not seen Chriss post with reference to USERPROFILE while posting this.

 

[Rajesh Karunakaran]

Chriss,

SUBST U: %USERPROFILE%
before starting the remote session, share the drive U: and have access to the user profile with \\tsclient\U

Good idea. I also was thinking that way.
However, it requires some setups in user pc and we wouldn't know if the driver letter (eg U) we assume would be available always. So, I am thinking of, from within my application, asking the user his local username and trying to create a destination folder path as

\\TSCLIENT\C\USERS\<the username given by user>\Downloads\

(Yes, I will have to include C drive in the RDP connection Local Resources selection)

Maybe, I can save the above path in a table/textfile for reuse.

Rajesh

 

[Chris Miller]

I wonder a bit why you wouldn't let users run with their own account on the terminal server, but maybe your scenario is totally different from what I am used to and think about.

Given the TS username is different but you share C:\, why not consider getting a list of accounts from:

ADIR(laUserDirectories,"\\TSCLIENT\C\USERS\*.*","D")

Another idea would be using WMI to query the client.

Chriss

 

[Rajesh Karunakaran]

Chriss,

When the user generates a report or other output files from the application, it gets generated in a common folder. Optionally, this file (say PDF of an invoice) needs to be copied to the user's local machine. For this, the most appropriate folder will be his user account "Downloads" folder, I think.

Given the TS username is different but you share C:\, why not consider getting a list of accounts from:
ADIR(laUserDirectories,"\\TSCLIENT\C\USERS\*.*","D")

As you suggested here, I think, we can show a list of user folders available and ask user to choose his useraccount and then construct the folder path starting with \\TSCLIENT\.... If the user selects a wrong username or another existing username, when I checked, windows doesn't allow access to such a folder. So, I can alert the user before attempting to copy the file to it.

Does this makes sense? Any drawback of this approach?

Rajesh

 

[Chris Miller]

I'm confused now.

If the user session within the Terminal server hasn't administrative privileges (as domain admin, not just local admin on the TS) you won't be able to write into a userprofile folder of any user on the client.

That's also a reason I said it's usually the same user that connects to a ts that runs the TS session and not a separate TS session user. You did say this was not the case, didn't you? Well, then whatever TS user is used commonly within the TS has to have the necessary rights, of course. How else do you even expect to be able to write anywhere?

That means, if the client user isn't even in your domain, I wonder if you even could write into the public user profile. Which in older OSes wasn't even simply PUblic as username but AllUsers. In the end you would need to revert to mailing them the PDF, wouldn't you?

Chriss

 

[Chris Miller]

I can only tell from experience about TS solutions where corporate users used their own domain account to use a corporate software they normally use in office also from homme. To be logged into TS as their own account they established a software creating a VPN tunnel so as first step they could log into their own corporate account from their own home PC not in the domain.

You always end up with such demands, if it would be allowed to write into a user profile from anywhere as anyone that wouldn't be safe, would it?

I think you either need some component still running local to be able to communicate with that in any way and let it do any necessary local filesystem work or you also need to establish a VPN connection to allow the users to use their own corporate domain account within the terminal server session. They then could also write into that terminal server sessions roaming part of their profile.

Chriss