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.
Related
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.
I'm troubleshooting an issue having to do with Think N Do and Windows 7. I set the DCOM settings up as the manufacturer said they need to be. However, computers aren't connecting to each other. I have the computers set to automatically log on to an account at boot. This account is never logged out of.
What I'm finding is when I open a RDP to the computers they suddenly start to communicate with each other. As if it's finally seeing an interactive user. From my understanding of things by having an account automatically log on at boot that account is then the interactive user. Leaving RDP open at all times is not an option. Sometimes the customer forgets and closes out of the RDP session by Xing out of it, they don't log off so the program is still running in the background.
Does anyone have any idea what this could be? It's an issue at a couple customer locations for me.
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.
I would greatly appreciate some help on this one! It may be a tricky one. :)
Problem
I have an VB6 application which is set up as scheduled task. It starts every time, but when executing CreateObject() it fails if a user is not logged on to computer.
I am looking for information on what could cause this. My primary suspicion is that some Windows API fails.
Key points
Behaviour confirmed on Windows 2000, 2003, 2008 and Vista.
The application executes as user X at scheduled time, executed by Windows Task Scheduler.
It executes every time. Application does start!
If user X is logged on via RDP it runs perfectly. (Note that user doesn't need to be connected, only logged on)
If user X is not logged on to computer the application fails.
Failure point
Application fails when using CreateObject() to instantiate a DCOM object which is also part of the application.
The DCOM objects declare .dll-references at startup (globally/on top of .bas-file) and run a small startup function. Failure must be during startup, possibly in one of the .dll-declarations.
Thoughts
After some Googling my initial suspicion was directed at MAPI. From what I could see MAPI required user to be logged on. The application has MAPI references. But even with all MAPI references removed it still does not work.
What is the difference if an user is logged on? Registry mapping? Environment? Explorer.exe is running.
Isn't the user logged on when application executes as the user?
What info would help?
A definitive answer would be truly great.
Any information regarding any VB6 feature/Windows API that could act differently depending on whether user is logged on or not would definitively help.
Similar experiences may lead me in the right direction.
Tips on debugging this.
The VB application possibly needs to get hold on to running services that are only running when a user is logged on.
What is the "Identity" setting of the DCOM component.
C:\WINDOWS\system32\Com\comexp.msc
C:\WINDOWS\system32\Com\comexp.msc
Component Services
My Computer
DCOM Config
The DCOM Object, right click properties
Identity tab
Set it to "This User" and set a user with the required permissions, and then run the app as your self to see if the DCOM component can still work, then try again from the scheduler.
We never found out what caused this.
Instead I made a RDP client which I put in Scheduled Tasks. It logged on a user which had the required app in startup. After some time the RDP client forcefully logged out the user (to prevent runaway apps hanging the system).
Not the perfect solution, but a solution nevertheless.
has your VB6 forms?
because when you run scheduled, it run "as a service", so it can't have forms, or if it have forms an enviroment where to show them.
I don't remember what I have used, but exists generic "run as a service" converter exe to run windowed VB6 projects.
Also perhaps you can easy convert your code to run as a VBScript, and schedule it.
We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.
Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.
It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.
To see this issue in action, do the following steps:
Run cmd.exe with no UAC
Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
Run cmd.exe as Administrator
Type "w:", and see the error message
At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.
Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?
This is by design.
Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.
Check out this link: Regedit Link
They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.
EDIT:
The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:
If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1
Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
I will be posting more information on this soon.