For a really specific use, i need to connect to an existing session which have a opened desktop (with gui). To maintain the gui, we opened the session with rdp and already use a powershell script which transform the rdp session into a console session (without exiting gui since the session technicaly stay open).
Before, I used psexec with the -i parameter set (I got the session's Id by the username) but now, I'm trying to do the same with pure powershell.
Any thought?
Related
I have a long running powershell script. It kicks off at login via GPO, connects to Exchange with the user's current credentials then goes back to sleep. It does this every half hour or so and continues until the user logs out.
The issue occurs if the user changes their password during this time. The next time the script attempts to connect to Exchange it fails. I assume this is because the credentials stored within the powershell session are no longer valid.
Is there a way to refresh/update the scripts's credentials from the O/S?
The only other way I thought to work around this was to restart the script in a new powershell instance, hence grabbing a new set of credentials. This sounds problematic as I believe the context will be passed on to the new session if it's initiated from the running script. Triggering a scheduled task that calls the script may work though I haven't tried it and it seems overly convoluted.
Any thoughts? I don't want to use Get-Credential as that requires a prompt. I also don't want to store a password in a file.
[System.Security.Principal.WindowsIdentity] may provide a way? Not quite sure where to start.
Update:
I'm using EWS as per: https://devblogs.microsoft.com/scripting/learn-to-use-the-exchange-web-services-with-powershell/
You can use the credentials stored in the current powershell session as per:
$exchService.UseDefaultCredentials = $true
So I didn't work out how to update the stored credentials in a running powershell session... surely it's possible... anyway, here is what I did.
Script runs, connects to Exchange successfully, sleeps
User changes Windows password
Script wakes up, connection to Exchange fails
Trap error via try/catch, create Scheduled task to Run in 5 seconds from now with Schedule.Service COMObject
Quit script
Task fires and relaunches powershell script with the updated credentials. Connection to Exchange succeeds. Script sleeps
Task autodeletes itself via Settings.deleteExpiredTaskAfter = 'PT0S' - which is immediately. You also need to set the .EndBoundary on the trigger
Works fairly neatly but it's a bit of a hack. Love to see a more elegant solution from someone.
I want to create a powershell script. One of our supporting companies needs to connect to our server from time to time to make their work and I need to connect their RDP session to watch them if their doing is OK.
Server: MS Server 2012 R2 x64
The case is I want to create a script which;
1- Checks the server's current sessions
2- Finds the specific session ID come from the username (the which I will give them to connect) currently logged in as RDP
3- When I pull the correct session ID from the username (and that means he is currently online and connected), I want to shadow his/her session without prompting/requesting their approvals.
Yes, I can do these separately but looking a powershell script or something like that to these. In one attempt, I want to shadow rdp to correct session and if he/she is not online, I want the system return an information message to me that the username is not currently online.
Is it possible?
Thanks&Regards
Melih
If memory serves PoSh does not natively supports querying RDP sessions (unless using the RDS broker, but I could be wrong here) but you can easily do that via query session
I cannot test it right now but something like this should do the trick:
C:\>query session
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console Administrator1 0 active wdcon
rdp-tcp#1 User1 1 active wdtshare
rdp-tcp 2 listen wdtshare
You can even call it with the username directly if that is known to you.
Shadowing the session would be easily accomplished with something like
mstsc /v:"$srv" /shadow:"$id" /control /noconsentprompt
I did not test this so maybe it needs some tweaking but a possible starting point could be
$userSessions = query session user01 /SERVER:server01 | Select-Object -skip 1 | ForEach-Object{$_.Split(' ',[System.StringSplitOptions]::RemoveEmptyEntries)}
$sessionId = $userSessions[2]
mstsc /v:"$srv" /shadow:"$sessionId" /control /noconsentprompt
Of course if running from the local server you can omit the /SERVER:XXX argument.
Hope this can help getting you started.
I'm trying to get some remote logging working, the current strategy is to kick off the remote session as a job and then while waiting for that job to finish, continually remote in and pull from a log file (and display it locally).
The problem I'm running into is that apparently PSSessions don't multiplex, so I get an error about it being busy. However, in the past I've found that New-PSSession will return an existing PSSession instead of creating a second session to the same computer.
So my question is twofold.
How do I create multiple PSSessions to the same computer from the same powershell session, and
How can I simply open the above second session with nothing as input but a PSSession.
I can work around 2, although for convenience it'd be nice if I didn't have to.
I get that there's an info stream in powershell 5, but unfortunately I'm not able to use that and it seems as if every attempt I've made at resolving this issue has run into some limitation of Powershell or Windows that prevents it, very aggravating.
I've got a batch file dmx2vlc which will play a random video file through VLC-Player when called.
It works well locally but I need this to happen on another machine on the network (will be adhoc) and the result (VLC-Player playing the video) must be visible on the remote screen.
I've tried SSH, Powershell and PsExec, but both seem to run the batch file and the player in the session of the command line, even when applying a patch to allow multiple logins.
So IF I get to run the batch file it is never visible on screen.
Using Teamviewer and the like is no option as I need to be able to call all this programmatically from my dmx program.
I'm not bound to being able to call the batch directly, it would be sufficient for me if I could somehow trigger it to run.
Sadly latency is a problem here as we are talking about a lighting (thus dmx) environment.
Any hints would be greatly appreciated!
You can use PSexec if the remote system is XP with the interactive parameter if you state the session to interact with, 0 would probably be the console (person physically in front of the machine).
This has issues with Windows Vista and newer as it pops up a prompt to ask the user to change their display mode first.
From memory, you could create a scheduled task on the remote system pretty easily though and as long as it's interactive the user should see it.
Good luck.
Try using web interface. It is rather easy: VLC is running http server, and accessing particular URL from remote machine will give full control over VLC. Documentation can be found here
How can I prevent a user from killing powershell process which ends the action of the script. and how can I restart powershell by a piece of code to resume its action?
If the script is being run under the users account, you can't stop them from being able to kill the process.
To get around this, you could have the script run as another user (as a service, or invoking as another user) which will launch the Powershell session under their credentials, in which case only admins will be able to kill the process.
Speaking from experience here:
In our environment we run SCCM, we have several powershell scripts that open a verbose window to let the user know that something is running. This script is running as SYSTEM. The user can still close the window even if they're not a member of the administrators group.
To get around crucial scripts that can't be closed I would suggest running the script silently, so that way it runs without the user even knowing. Or, if you indeed need a GUI, use VB.NET / C# to create a form and use the form closing event to prevent the user from closing it until you're well and ready.