I've a little Windows Server (Windows Web Server 2008) on which I need to monitor the desktop. I've placed a little application on it which takes screenshots now and then and uploads them to a FTP - but as soon as I disconnect (not logout) via RDP the Screenshot is not refreshed (but uploaded). Is there any setting I have to change so the RDP session will keep taking up to date screens?
I think that when you`ve disconnected users session automatically logsout. So may be you should run app on the under loged in user account. And also may be screen "freezes" and do not updating, so when you capturing it there is the same screen as before
Related
When a user interacts with an app that is delivered via a Citrix - what does the user see? Is it a full app with real Windows, or just an image like in RDP?
Thanks!
It's rendered similar to RDP but over the HDX (formerly ICA) protocol (vs the RDP protocol). Communication occurs on port 2598 by default (if using the Session Reliability feature) or 1494 (if that feature is disabled). The user is seeing a real app, but that app is running server side.
We have a remote support tool that allows us to connect to machines behind a NAT firewall. Once connected, we can choose to either connect to the console session or to any active RDP session from a list. We cannot connect to inactive/disconencted RDP sessions, and the tool has no way to create new loopback/redirected RDP sessions. What we would like to do is find a way to spawn these RDP sessions via a script or a small application so that the support tool can detect them and allow us to connect. The motivation to get this working is to be able to have multiple techs access the same server simultaneously (up to one active console session and two active RDP sessions, all at the same time, for a total of three techs).
If we log on to the console session of the target servers and then RDP to the loopback, we see the new RDP session in our support tool, which we can then select and connect to. The problem is that this RDP session creation depends on the console session. It also gives the console session access to the RDP session, and if the RDP window is minimized then the output/input for that session in our support tool is frozen. I was able to use the PS script Connect-Mstsc (mostly just a wrapper for mstsc.exe but with support for adding creds) to create RDP sessions from another random server on the remote internal network to the target server we want to create a new RDP session on. This works well from an automation standpoint but we have the same limitation described above - it only works if run interactively. If you run this from a SYSTEM shell remotely, the RDP session never appears in our support tool.
The remote support tool in question is ScreenConnect and our servers are all Windows, mostly 2012 R2, all AD environments. I think the core challenges to this solution are getting the RDP sessions created and active in a non-interactive fashion, and then preventing RDP from freezing the session input/output.
I run a windows-app on a remote desktop. It actually has an IE browser inside and I call the Screenshots api sometimes.
When a session is connected to the remote desktop, screenshots are successful and a picture is captured about what is really in the browser. But when no session is connected, a picture with black color is captured. I guess rendering is stopped at this time.
Is there any way to let it render even though no session is connected?
Workround: use tscon to move disconnected RDP session to local console. This enables rendering again.
As I understand, when we start windows it starts Session 0 which does not connect to any GUI, etc. and runs all windows services. So my task is, after windows was started, emulate windows input for selecting user and login to is session. I know that for sending input from service I should run desktop app and through it send input, show GUI, so on, but how can I do it before any user session was start? (for example I see that TeamViewer can do it)
WTSGetActiveConsoleSessionId() will tell you which session is attached to the physical console.
You can then duplicate your security token with DuplicateTokenEx(), change the new token's session with SetTokenInformation() and the TokenSessionId option, and launch a process with CreateProcessAsUser().
The new process should then be running in the right session, but it may also need to attach itself to the right desktop before it can interact with the logon interface. You can use EnumDesktops() to list the available desktops, and trial and error to determine which one the logon interface runs in. (Note that this may be different in different versions of Windows.)
i'm using a Windows 2003 Server.
I have a session with my username on it and i have a windows application (not service) opened on it. I want this application to always be running.
The problem is, when Security updates force Windows to reboot, my session is closed and i need to reconnect to the session to get my application working again ..
How can i do to automaticaly force the opening of my user's session upon server's reboot ? (application launch is in the startup of my session)
Thanks
If you want to have the program running consistently, I would highly recommend making it into a Windows service (see also this page). Then you can set the username that the service logs on with (this is particularly important if the app needs to access networked resources), and even set the stability values to have the service restart itself if the EXE crashes for some reason.
Otherwise, if you really want the computer to login as your user and run the program, you could set the autologon parameters to your username and password, and put the shortcut to your program in the user's Start Menu Startup folder. (But this does not provide you any of the stability benefits that a service would.)
Add a startup script, http://technet.microsoft.com/en-us/library/cc779329(WS.10).aspx