Hello all,
I’m a bit of a powershell newbie, but I was hoping someone can help. I’ve searched the forum for anything similar but so far to no avail.
our Eniviroment
Powershell 2.0
legacy domain (X1) with NAS stores for users homedrives
WMI-object and PS remote session are block by firewall and this will not change for our legacy domain.
At present we can view and edit manage homedrives shares via a runas cmd (using a legacy domain account) and rmtshare.
I’m looking to automate some of our basic tasks but to do so I require to have the full UNC path of our homedrive for a specific user
Thanks Goldy for your reply,
Sadly for the purpose of this script and the clients who will use it, the NAS are irrelevant and I wouldn’t want to be invoking any directly against them (the script will never be persmission to do so). The aim is to check the UNC location of the user who has left the firm, confirm the homedrive UNC path is correct, delete the share (stop sharing).
Another part of the script will rename the user folder to olduseraccount using rename-item.
The part that is failing for me is the invoking of rmtshare.exe under another account and loading that data into a variable.
To confirm that rmtshare works fine and as designed under a runas CMD, I just want to do the same in powershell for the purpose of automating. I also do not want to invoke the powershell session under another user, due to other changes this script will be performing and for auditing.
Hello Daniel
firstly thanks you for the reply
The mapping of the drive is redundant as these are homedrive the user limit is set to 1, also mapping a drive would be raised as a red flag and beyond what we require from the script.
I require a process that works via a cmd line and transfer it over to powershell.
I was wondering if it’s possible for powershell to invoke another session of powershell under another account, run the rmtshare.exe, load that data to a variable and have that information passed back to the first session?
The point it appears to be failing is the prompt for password is been treated as a ‘start-job’ hence the receive-job is returning:
“Enter the password for :”