- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Every administrator knows these situations. You need to reboot a server, but you are not sure whether someone is using it. Or there is a user account getting locked, but the user claims they are not logged on anywhere. PsLoggedOn allows you to get this information quickly with a single command, at least for the first part.
Get logged on users on a local computer
When you run PsLoggedOn without any command line options, it reports information about the local computer. It is available in both 32-bit and 64-bit versions. The tool will show you two types of logon information: users who are logged on locally and users who are logged on through resource (network) shares. It also shows the time at which the session started. Locally, administrative permissions are not required.
A local logon means a user whose profile is loaded into the registry. In that case, the user's security identifier (SID) is present as a subkey in the HKEY_USERS registry hive. PsLoggedOn will use the last-write time stamp from a subkey of that SID and report it as the user's logon time. Therefore, the time might not be 100% accurate.
A resource (network) share logon means that a user is accessing the computer over SMB file shares, RemoteRegistry service, and so on. The output is similar to the net session command. PsLoggedOn uses the NetSessionEnum API to query such information.
To show only local logons, use the -l (lower L) option. To hide the timestamp information, use the -x option.
Get logged on users from remote systems
All the PsTools utilities support remote operations using a syntax that is consistent across the entire suite. Not all the utilities perform the operation the same way; there might be different requirements. PsLoggedOn requires RemoteRegistry service on remote systems.
PsLoggedOn does not support the options -u and -p to specify alternate credentials. Therefore, you need to run the tool under an account that has administrative permissions on the remote computer.
As mentioned earlier, PsLoggedOn uses the RemoteRegistry service to query the information from a remote system. Because of this, it will always be shown in the resource shares logon (in my case, LAB\Administrator).
Get a particular user's information
The Sysinternals website says that PsLoggedOn can search computers in the network neighborhood and tell you if a particular user is logged on to them. Unfortunately, this no longer seems to work. All my attempts failed to get any information at all. I tried in three different environments. The first one was a production customer domain, where I got an error message: "Error browing network: The list of servers for this workgroup is not currently available." Note that the "browing" instead of "browsing" is not my typo—it really is shown by the tool.
The second attempt was made in a lab environment with two Windows Server 2022 machines and a clean domain installation. The error message was the same as before.
When I saw that message, I thought that it was caused by disabled network discovery in advanced network settings. I enabled the network discovery and disabled the Windows firewall, but the result was still the same. The last test attempt was made on a workgroup Windows 10 machine, where the error message was still the same.
It's a little sad that this feature does not work in a domain environment where the tool could easily query computers from the domain controller.
Subscribe to 4sysops newsletter!
In this post, you have learned what user logon information can and cannot be acquired by PsLoggedOn. Unfortunately, as with many other Sysinternals tools, PsLoggedOn was last updated in 2016. Hopefully, the team will update the tools in the near future, so they are usable in today's high security environment.
Want to write for 4sysops? We are looking for new authors.
In GNU/Linux that would be `w`.
Get locally logged-on users:
PS > Get-CimInstance Win32_UserAccount | Where-Object SID -In (Get-CimInstance Win32_UserProfile -Filter “Loaded = $true”).SID
That command doesnt really show reliable information. I have 2 users logged on a server and 5 users returned with the command.. 🙂
What type of users were the other three? Maybe the command can be tweaked.
Dont think so. The query simply shown invalid data. After a server reboot I have logged on with my user (just me there) and the query returns 5 accounts (local/domain). Basically everyone who was ever logged to the server…
Everyone who was ever logged to the server minus your account, should be filtered out by:
Get-CimInstance Win32_UserProfile -Filter “Loaded = $true”
Running that command alone should only return your account and the built-in service accounts
Sorry, but have you even tried it?
Get-CimInstance Win32_UserProfile -Filter “Loaded = $true”
Returns 8 records, while just 1 user is logged on the server… I removed the usernames obviously…
I just tried it on a DC and got the same result as you have. The command works as expected on Win11 standalone and Win10 domain joined. Investigating further I ran this command on the DC:
reg load HKU\SomeUser C:\Users\SomeUser\NTUSER.DAT
SomeUser wasn’t logged in, obviously. Response was:
ERROR: The process cannot access the file because it is being used by another process.
Not sure why.
Lets say the behavior is super weird. When I restart one of my servers I can then see in HKU key total 5 user profiles loaded right after the reboot, even they are for sure not logged locally, via network or RPD. There the WMI and also PsLoggedOn shows me all the names of the users.
Then I have another LAB server and there the behavior is OK. When 2 users are logged on via RDP, I see 2 names via WMI and PsLoggedOn. When 1 user logs off, I see just 1 in the result query… Rly strange.
On a side note – the WMI command can only show user logged locally or via RPD, not via SMB share or so.
Thanks for the comments.