Not sure if this is more suited to SO or Server Fault.
During unittesting ran across what appears to be a limitation of "Fast User Switching" on windows 10. Had the following two line batch file.
C:\Windows\System32\timeout.exe 30
C:\Windows\System32\shutdown.exe /L
Open a CMD.exe and run the bat file. 'Fast Switch' (ie logon) to another account. The timeout completes as scheduled, but the logoff statement has no effect...user is still logged on. When you return, you can see the shutdown.exe is on the screen, but the session is still active.
If you run the script and stay logged in to the account, after 30-seconds, the logoff command works as expected.
Also discovered the same limitation if instead of fast-switching, you invoke the screensaver (ie: Lock the account). After 30-seconds, the first command finishes but the session is still active.
I've scoured MSDN and Google, but there is scant documentation on Fast-user switching and the Lock functionality and how they might limit what a user can do while switched or locked.
You can definitely end a session while it is locked, but you can't do it with the normal ExitWindows API call that shutdown.exe is using. See the notes in MSDN:
EWX_LOGOFFShuts down all processes running in the logon session of the process that called the ExitWindowsEx function. Then it logs the user off.
This flag can be used only by processes running in an interactive user's logon session.
For a solution using only batch files, logoff and related terminal server tools allow you to end the locked session. Example using PowerShell which works when tested on Windows 10 1903:
sleep 30
logoff ([System.Diagnostics.Process]::GetCurrentProcess().SessionId)
As for documentation, multi-session support of windows is documented most strongly for Remote Desktop Services. All of the advice and API's used for RDS apply for Fast User Switching. See About Remote Desktop Services.
Related
I'm currently working on a screensaver application for Windows that needs to check if a user is idle so it knows when to turn on. Sometimes a user may have a certain app (like a video player) running that requires no user input and idles the system even though the system isn't truly idle.
The powercfg -requests command displays if any application has requested the display to stay active, but requires administrator privileges to run. I looked at the official powercfg documentation and played with a few commands in Power Shell and cound'lt find anything that worked. Is there a way to get this same information somehow without the application requiring administrator privileges?
I am using psexec to run a remote script which does some UI operations on the print objects present in the remote system. To be specific , the API used is SHInvokePrinterCommand() to invoke printer properties of a printer object.
The entire thing works fine when executed with a user logged in(and thus a visible desktop) on windows 7. But when no user is logged in , the procedure is failing to work, the API(SHInvokePrinterCommand) returns successfully but it doesn't seem to do any work. WINDOWS XP under the similar conditions, WORKS FINE.
The observation made me believe that it has something to do with the session and "Window station" architecture that varies within these operating systems.
With some coding in the remote process , I was able to establish that the remote process is started in a non-zero session (session 2) by psexec and the only window station it is attached to is "WinSta0".(I used EnumWindowStations() for that). WinSta0 is the only windows station which receives input from KeyBoard , mouse etc.
With this much observation , I fail to understand what makes the entire thing not work in case of windows 7, with no on logged in. Basically the properties page of printer is not actually getting invoked in this case.
Does the session , that psexec forms , for executing the remote process ,in some way not a "complete" session? Any way to fix this problem?
Any ideas or suggestion are most welcome.
Several things come to mind, mostly related to increased security in Windows Vista & above.
SHInvokePrinterCommand is deprecated in Vista & above.
PSExec runs the script in a service, which in Vista & above no longer have desktop access.
When there's no logged in user, HKEY_CURRENT_USER doesn't exist, and any attempts to read from it will fail.
My company has about 50 - 60 machines that we need to manage remotely.
They are set to automatically login but I'd like to perform the following activities:
Capture screenshot (for diagnostic purposes, if something isn't working)
Start/stop/kill processes
Start/stop/kill services
Reboot machine
This seems simple enough but I'd like to get information on the best approach for doing this. My biggest problem is capturing a screenshot "no matter what is going on". For example, if I write a Windows Service, it can't capture the desktop session screen or the login screen.
EDIT: I've prefer to make this a Windows Service so it can run even if the user isn't logged in (i.e. if a problem occurs with the auto-login) but that doesn't seem possible. Furthermore, I'd also like to capture a screen if somebody RDPs in the machine. Basically, I want to know exactly what is going on with each machine and monitor it remotely.
Remote Capture Screen Shots
Boxcutter will do this (I dont know about the login screen though, however in theory if you run it with PSExec below it should)
Start/stop/kill processes & Start/stop/kill services
PSExec, PSList, PSKill, PSService all part of SysInternals will work here
Reboot machine
run shutdown command via PSExec or run shutdown command with -m flag and the PC name you want to shutdown.
PSTools and remote shutdown do require / prefer the machines be on the same Domain as your PC and you must have admin rights to the PC's in question
If I enumerate sessions using LsaEnumerateLogonSessions() to give me a list of session LUIDs then LsaGetLogonSessionData() to get details of each session (as described on MSDN) then on Windows XP it behaves exactly as I would expect, showing one logged-on session for me plus some logons for services.
Running the same program on Windows 7 shows two logon sessions for me, plus the service sessions. The two sessions for me show up as the same user and the same logon time.
I was running some elevated processes so I thought that might be it, but the second session is still there when I close those down and even after a reboot. So does anyone know why there is a second session for each real logged-on user? How can you tell which is the "real" one?
Thanks
Tim
Some quick googling seems to indicate that Windows 7 (and probably Vista before it) creates two logon sessions for administrative users when UAC is enabled - one elevated and one not.
A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.