Logged In User using FNMS Agent

[john_kobayashi]

After a long protracted email conversation with Flexera Support, I am confused about Flexera's position regarding the FNMS Agent's ability to gather the logged in User information.

The conversation with support initially started when our customer filed a case indicating that the logged in User Information was not showing up in FNMS.  The customer is using the agent version 12.4 on Windows 10.     Flexera Support indicated logged in user information was NOT gathered by the agent which contradicts my understanding.   At one point, the support agent even cited some text about User Scheduling saying it was deprecated which to me appeared as a non-sequitur 

After a lot of investigation, it turns out that FNMS Agent 12.4 does NOT (for whatever reason) get logged on user for Windows 10 but does so for Windows 7.   However, FNMS Agent 12.4.1 and 13.2 are able to accurately gather logged in user information on Windows 10.  This leads me to believe there is a bug in FNMS Agent 12.4 where it does not properly gather logged in User information which can be resolved by upgrading.

Unfortunately, I am dazed and confused regarding this functionality.   Has anyone else in the community heard that the logged in user functionality in the FNMS agent is deprecated?   To me it still appears to work (at least in version 13.2 which I know is not the latest as of this writing).  

[MurrayPeters]

Hi John,

I’d be staggered to find out that the concept of LastLoggedOnUser was being deprecated – it’s core to the majority of compliance measurements/reharvesting scenarios etc.

I haven’t tested the individual versions that you list, but on my local environment here the agent is 13.4 and it definitely records LastLoggedOnUser details.  

For reference, where FNMS agents are the source the windows agent will use WMI to query the class “Win32_ComputerSystem” and the LastLoggedOnUser is taken from the UserName attribute of that class.    

What I can say is that I have run into scenarios where the LastLoggedOnUser doesn’t get captured.   Prime examples that can recall are (off the top of my head here, so take with a grain of salt):

• if the agent  inventory task is run when no-one is logged on then the Win32_ComputerSystem/UserName will be empty.
• If a user is connecting to session remotely (via RDC, VDI) then similarly the Win32_ComputerSystem/UserName will be empty.

I think your question is a great one though & I hope you get other responses that contribute and help clarify. 

It would be great if Flexera could compile a list of known factors and publish that in documentation too – as I mentioned earlier it really is core functionality that drives value realization from the product, so I hope there is a consistent reply that can be made available for all.

- Murray

[john_kobayashi]

Murray,

Thanks for the response. 

I was aware the agent uses the WMI query to get the logged in user information.  What is strange is when I found the discrepancy with the 12.4 agent on Windows 10 vs Windows 7, I created a powershell script that ran the WMI call as system using a scheduled task.   I found it worked on both Windows 10 and 7 so I can only surmise there is some problem with the agent - especially because it works in 12.4.1.

As an aside -  as you know, the inventory record gets placed in the importedcomputer table of the compliance database and there is a last logged in user record column in that table.   I have found that there are cases were the importedcomputer table has a valid logged in user value but will not get propagated into  FNMS because of the logic in the compliance reader/writer for ManageSoft inventory data source.  Specifically in the computer writer logic, you can see it attempts to join the imported computer records with domain and user information.  So if there is any missing data or gaps in the domain or user records, the resulting logged in user information gets nulled out in the process.     

[ChrisG]

The conclusion that a particular version on the agent does not gather logged on user information on a particular version of Windows sounds highly unlikely to me. In my experience this is highly stable functionality in both the agent and Windows. More likely is that the exact conditions causing this have not been fully qualified: as already discussed in this thread, there are more things to consider in the data flow and processing of logged on user information than just whether WMI provides and the agent gathers a non-blank value.

[john_kobayashi]

Don't take my word for it.   Let the agent convince you.   The Agent version is 12.4 (not 12.4.1) on Windows 10.  I too thought had my doubts and spent many hours setting up environments trying to understand the problem.   I can only share my evidence and conclusions based on evidence.   

Oh by the way, the agent has to be running as SYSTEM to reproduce this problem.  If you just run ndtrack as a user, the problem will not appear.  So the two ways to reproduce it is to let it run as scheduled or to run it from the scheduler window by right clicking on the gathering inventory -> run

[ChrisG]

Well how about that! I stand corrected: I've just tried the 12.4 agent version myself, and it indeed does not gather the logged on user when the inventory gathering process runs with SYSTEM credentials on Windows 10. I also tried the 13.2 agent version, which gathered the user details just fine.

[john_kobayashi]

Chris, thanks for the confirmation.   However, the original post was to confirm that the logged in user functionality is not currently deprecated but expected to function as we all understand it should.   In other words, the problem seen with 12.4 on windows 10 is just an anomaly.   That is what I would like to ultimately confirm.  

[ChrisG]

Yes, the problem observed with the 12.4 agent version on Windows 10 sounds like an anomaly to me.

[kclausen]

The idea that the capture of Logon User Name by our Agent has been deprecated is not correct.  That is a core feature of our Windows Agent.

Kirk