ProHoster > Blog > Administration > Windows: find out who is logged in where

Windows: find out who is logged in where

Windows: find out who is logged in where
- Oh, nothing works for me, help!
Don't worry, we'll fix it now. Name your computer...
(a classic of the genre from technical support calls)

It's good if you have a tool a la BgInfo or your users know about the Windows+Pause/Break shortcut and know how to press it. There are even rare specimens that managed to learn the name of their car. But often the caller, in addition to his main problem, has a second one: to find out the name / IP address of the computer. And often it takes much more time to solve this second problem than the first one (and you just had to change the wallpaper or return the missing label :).
But it's much nicer to hear something like:
- Tatyana Sergeevna, don't worry, I'm already connecting ...


And it doesn't take much to do that.
The technical support specialist only needs to memorize the names of the machines and remember who works for what.
Before describing the solution we are currently using, I will briefly look at other options in order to criticize them to the nines and explain my choice.

  1. BgInfo, desktop info and the like. If there is a lot of money, there are also paid ones. The bottom line is that technical information is displayed on the desktop: machine name, IP address, login, etc. In Desktop Info, you can even cut performance graphs to half the screen.
    It does not suit that for the same Bginfo, for example, the user needs to minimize windows in order to see the necessary data. More than once, my colleagues and I observed at BgInfo characteristic artifactwhen the new text is displayed on top of the old one.
    Some users are annoyed by the fact that admins draw a frightening 192.168.0.123 on the face of a cat stretched out on the desktop, spoiling the aesthetics of the background image, and, of course, this is terribly demotivating and completely kills the working mood.
  2. Label a la "Who am I" (don't try to add a question mark to it at the end :). A classic shortcut on the desktop, behind which is hidden a neat or not very script that displays the necessary information in the form of a dialog box. Sometimes, instead of a shortcut, the script itself is placed on the desktop, which IMHO is bad manners.
    The disadvantage is that to launch the shortcut, as in the first case, you need to minimize all open windows (we don’t take into account the minions of fate, who have a single solitaire window open on their working machine). By the way, do your users know where to click to minimize all windows? That's right, a finger in the admin's eye.

The cap also suggests that both methods described above have the main drawback that the user is involved in obtaining information, which can be blind, stupid, and generally lie.
I won’t consider the option of improving computer literacy, when everyone knows where to look in Windows for the name of their machine: it’s a noble thing, but very difficult. And if the company has a staff turnover, then it’s completely disastrous. What can I say, in most cases they don’t even remember their login.

I poured out my soul, and now to the point.
The idea of ​​a Khabrovchanin was taken as a basis medium of this article.
The essence of the idea is that when a user logs into Windows, the logon script enters the necessary information (time and machine name) into a certain attribute of the user account. And when you exit the system, it executes a similar logoff script.

I liked the idea itself, but something did not suit me in the implementation.

  1. Group policy, which defines logon and logoff scripts for users, applies to the entire domain, so the scripts will run on any machine that users log in to. If you use terminal solutions along with workstations (for example, Microsoft RDS or Citrix products), this approach will be inconvenient.
  2. The data is entered in the Department attribute of the user account, to which the standard user has read-only access. In addition to the user account attribute, the script also modifies the computer account's Department attribute, which users can't change by default either. Therefore, in order for the solution to work, the author suggests changing the default security settings for AD objects.
  3. The date format depends on the localization settings on the target machine, so we can get November 10, 2018 14:53 from one machine, and 11/10/18 2:53 pm from the other

To eliminate these shortcomings, the following was done.

  1. GPO is linked not to a domain, but to an OU with machines (I separate users and machines into different OUs and advise others). At the same time, for loopback policy processing mode mode is set go.
  2. The script will only write data to the user account in the attribute Info, which the user can change independently for his account.
  3. Changed a piece of code that generates an attribute value

Now the scripts look like this:
SaveLogonInfoToAdUserAttrib.vbs

On Error Resume Next
Set wshShell = CreateObject("WScript.Shell")
strComputerName = wshShell.ExpandEnvironmentStrings("%COMPUTERNAME%")
Set adsinfo = CreateObject("ADSystemInfo")
Set oUser = GetObject("LDAP://" & adsinfo.UserName)
strMonth = Month(Now())
If Len(strMonth) < 2 then
  strMonth = "0" & strMonth
End If
strDay = Day(Now())
If Len(strDay) < 2 then
  strDay = "0" & strDay
End If
strTime = FormatDateTime(Now(),vbLongTime)
If Len(strTime) < 8 then
  strTime = "0" & strTime
End If
strTimeStamp = Year(Now()) & "/" & strMonth & "/" & strDay & " " & strTime
oUser.put "info", strTimeStamp & " <logon>" & " @ " & strComputerName
oUser.Setinfo

SaveLogoffInfoToAdUserAttrib.vbs

On Error Resume Next
Set wshShell = CreateObject("WScript.Shell")
strComputerName = wshShell.ExpandEnvironmentStrings("%COMPUTERNAME%")
Set adsinfo = CreateObject("ADSystemInfo")
Set oUser = GetObject("LDAP://" & adsinfo.UserName)
strMonth = Month(Now())
If Len(strMonth) < 2 then
  strMonth = "0" & strMonth
End If
strDay = Day(Now())
If Len(strDay) < 2 then
  strDay = "0" & strDay
End If
strTime = FormatDateTime(Now(),vbLongTime)
If Len(strTime) < 8 then
  strTime = "0" & strTime
End If
strTimeStamp = Year(Now()) & "/" & strMonth & "/" & strDay & " " & strTime
oUser.put "info", strTimeStamp & " <logoff>" & " @ " & strComputerName
oUser.Setinfo

Whoever finds all the differences between the logon- and logoff-script first will get a plus in karma. 🙂
Also, to obtain visual information, such a small PS-script was created:
Get-UsersByPCsInfo.ps1

$OU = "OU=MyUsers,DC=mydomain,DC=com"
Get-ADUser -SearchBase $OU -Properties * -Filter * | Select-Object DisplayName, SamAccountName, info | Sort DisplayName | Out-GridView -Title "Информация по логонам" -Wait

In total, everything is configured for one-two-three:

  1. create a GPO with the necessary settings and link it to the department with user workstations:
    Windows: find out who is logged in where
  2. let's go drink tea (if AD is with a large number of users, then you need a lot of tea 🙂
  3. run the PS script and get the result:
    Windows: find out who is logged in where
    At the top of the window there is a convenient filter in which you can select data by the values ​​of one or more fields. Clicking on the columns of the table sorts the records by the values ​​of the corresponding fields.

We can beautifully “package” our solution.
Windows: find out who is logged in where
To do this, let's add a shortcut to run the script for technical support specialists, who will have something like this in the "object" field:
powershell.exe -NoLogo -ExecutionPolicy Bypass -File "servershareScriptsGet-UsersByPCsInfo.ps1"

If there are a lot of technical support employees, then you can distribute a label using GPP.

A few last remarks.

  • The machine from which the PS script is run must have the Active Directory module for PowerShell installed (for this, it is enough to add the AD administration tools in the Windows components).
  • By default, the user cannot edit most of the attributes of his account. Keep this in mind if you decide to use an attribute other than Info.
  • Inform all involved colleagues about which attribute you will be using. For example, the same Info is used to interactively add notes to the user's mailbox in the Exchange Server admin panel and someone can easily overwrite it, or be sad when your script overwrites the information they added.
  • If you have multiple Active Directory sites, then allow for replication delays. For example, if you want to get up-to-date information about users from AD site A, and you run the script from a machine from AD site B, then you can do this:
    Get-ADUser -Server DCfromSiteA -SearchBase $OU -Properties * -Filter * | Select-Object DisplayName, SamAccountName, info | Sort DisplayName | Out-GridView -Title "Информация по логонам" -Wait

    DCfromSiteA - domain controller name of site A (by default, the Get-AdUser cmdlet connects to the nearest domain controller)

Windows: find out who is logged in where

Image source

I would appreciate it if you could complete the short survey below.

Only registered users can participate in the survey. Sign in, you are welcome.

What do you use?

  • bginfo, Desktop info etc. (free software)

  • paid analogues of bginfo

  • I will do as in the article

  • not relevant, because I use VDI/RDS etc.

  • I haven't used anything yet, but I'm thinking

  • I do not need to collect such data

  • other (share in the comments)

112 users voted. 39 users abstained.

Source: habr.com

Add a comment