Hi people, firstly I have little knowledge about powershell. Used some times but on specific generic cases.
I’m trying to help my co-workers to automate this task:
Backgrounding:
RDS running on windows 2K22 std from head to toe.
RDS is sharing executables ergo not sharing Desktop.
In theory, for a bunch of users (aprox 40) we need to map \tsclient\c to v: to allow them upload files to the application. After several tries, our consultant told us that we need to
log those users via RDP (we have to temporarily join them on the local administrators group), make the mapping, logging off and then allow using RDS in order to accomplish that. But have to do it on every session host of our RDS (8 servers). That means a lot of manual work (320 times).
So I’m humbly asking if this whole task can be automated… of course I’m not asking to write me the script… just tell me which primitives can be used and I will make the scripting.
At least I will try to run the script on each server, since I don’t know how much complex can be setup the powershell environment to allow run one script from one server to modify settings remotely.
I’m not sure I’m understanding the specific requirements here, but a couple pieces are problematic.
First, you say that you need to temporarily put the user in the local Administrators group. I’m not familiar with the circumstances but if you’re saying they need admin rights within their RDP session to map a drive then you’d likely have to use Task Scheduler to run as SYSTEM in order to handle this manipulation.
Scoping the “trigger” on the scheduled task sounds like a real pain though, and then you still can’t use that same execution to map the drive because that has to run as the logged in user.
How you handle that with Powershell I’m not sure.
It sounds like would be an incredible amount of “scaffolding” with Powershell to get a solution which always makes me think “maybe Powershell isn’t the answer for this”.
Maybe Group Policy? Maybe a symlink instead of a mapped drive? Maybe the vendor can do an engineering hotfix for their software to allow for UNC paths?
Hi @grey0ut I really appreciate your input.
I tried to explain the goal and the actual procedure suggested by the consultant.
In theory
a- have to map the user to the local administrator
b- enter to the server via RDP
c- make the map of \tsclient\c as letter v:
d- logged off
e- remove the user from local administrator group.
-----After this procedure the user can log via RDS and them when look up on the app and show v: letter which is mapped to the \tsclient\c
We have already tried via GPO and local GPO; that didn’t work since we are sharing the executable from RDS not the whole desktop.
Thanks @Olaf, tried different ways to propagate the gpo o local policy… they didn’t work… at least that map works fine on RDP but as soon you logged in via RDS there is no map via GPO/localpolicy.
You should spell out the process a little more IMO. Before I try to help, I too am struggling a bit to understand.
First the language here. When you refer to RDS, are you referring to launching a RemoteApp? (Control Panel → RemoteApp)? In other words, walk us through the user experience and don’t assume we know anything about what tech stack you are using etc. .
Then the desire in the application is when they can upload files from their local system which uses File Explorer, and thus, the need for the map?
Also could you elaborate on the RDP part and why the administrative part is a requirement? That seems strange to me at first glance. Also, who is your ‘consultant’?
Hi people, sorry by my delayed response . As we have the launch date; our team is struggling with test and adjustments to servers either on Windows RDS or linux/backends.
Yes @dotnVo; I have issues to describe fully the environment, there are details that can’t be told and questions that can’t be answered as “who is your consultant’s name”. Believe me nobody on my team is happy about this situation with RDS and now we have to many things to worry.
About the RDS;
On the other hand, as I have to dive deep with this requirement, have found that isn’t totally viable on sole scripting. There is no CLI RDP client that allow from CLI to make the map of \tsclient\c as a letter.
To make things worse, the app is written on visual basic 32bits.
But I want to thank everybody how took their time to read and put mind to understand and help.
Not sure I totally agree with this. But then again, I dont totally understand what you are trying to do. However, I did play around. This works just fine from a NON admin shell. I connected an RDP session from a Windows server to a windows client, then did the following in a command shell.
net use v: \\tsclient\c
I then had no issues access v:. Am I missing something here?
Hi @tonyd; yep.
I was looking to a scriptable solution since as we have been told. Every user must have mapped \tnsclient\c as v: on every session hosts. We will have more than 600 users and 6 session hosts. That means 3600 times;
put the username under local admin or Remote Desktop Users group (at least)
take the rdp client logging as the user make the mapping
and then remove the user from the local group in order to let use RDS instead RDP.
-----GPO don’t work (I don’t know why (take in mind I’m a Solaris/Linux guy) and my teammates can do a lot of stuff on the AD, but they didn’t find why GPO map don’t works.
------We try a psexec command from (sysinternals) but besides the mapping was done (successfully execute) ; when the user logged in by RDP there is no mapped v:. The same if user logged in via RDS.
That mapping must be done on RDP since the user really uses a custom-made app that is shared through the RDS sfw. They don’t load a fully working desktop.
The app is written on visual basic 32bits and has a lot of time lived on citrix.
Maybe now u can see why I ask for some guidance to find out if a PowerShell script could accomplish the task.
We give up with these approach and went to DFS replication group; where every single session hosts have a local v: disk replicated between all servers against a central server.
So every user just have to point to central share to upload/download files when use their local PC. And when they use the app just load/drop the files to the session server v: on whatever session hosts were assigned to work by the rds connection broker.
Personally, I think this is much better than throwing users “temporarily” into a privileged group. I could envision the “removal” part failing at some point and not worth the risk.
Thanks a lot to everyone who read and participate in this post.
Not just that @tonyd ; load 600 users to a group and unload them; via script isn’t hard. But the rest of the tasks is really cumbersome. And need to take the normal movement of people on a company. That a lot of manual work ergo prone to error and too slow.
We think that DFS replication is a better approach to both needs… still have to deal with some nuances of the app… but as we have ideas to cope issues; we will be fine.
.