I had an interesting challange presented to me this morning - and thought I would share. There might be a more efficient method - but it appears to be working well.
We have a situation where users on the clinical floors are complaining that there are not enough clinical workstations available to them during the day for patient charting, etc. We have numerous workstations on the floor - but we are being told that they are constantly in use and there is not enough to go around. I was tasked with trying to determine in Big Fix if there was a way to track if indeed this issue is true. I figured the first step was to monitor how much time the workstations are really sitting in idle mode.
Our image uses a particular .scr screensaver - which is initiated at 20 minutes of idle time. I wasn’t sure it would accept a .scr file - but I went ahead and setup an Application Usage monitor to track the .scr file upon launch. I always thought of Application Usage as a way to track full applications - and never as a tool for those tricky situations such as finding idle time on a workstation. And guess what - it works great!
The only trick is that to get a more accurate count of idle time - you have to take the time that the screen saver was running and add the minutes that are set in the screensaver config (in my case - 20 minutes). I looked for a .wmi call that might give full idle time - but found nothing close enough. The Application Usage gets us enough data though.
So now we have a great method for getting a good picture on if our workstations are really getting full usage and/or which ones are spending the most time idle. Perhaps it is the placement of workstations - and instead of purchasing additional units - they just need to be placed in more accesible areas. We shall see.
That sounds very cool… good work figuring out how to use the application usage summary inspectors… Do you mind posting the relevance you are using to do the calculations? I bet we can adjust it to add the 20 minutes automatically…
Also, if we additionally track the total uptime of the computer (using application usage summaries tracking the BESClient.exe process), we probably can tell you the complete percent of idle time on the system.
Actually besides the Application Usage Summary - I haven’t created anything else yet. How would you combine the usage summary with relevance? Would you then create an analysis based on the data?
Would you mind sharing the relevance you use? or the Application Usage Summary - whatever you created.
I am trying to figure out a way to run an action only when a user is inactive, and just using the value “CurrentlyIdle” of key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\PowerManagement” of registry as string = “1” isn’t doing it for me.
Under the Application Usage Information Dashboard - I specified a new application to track based on the screen saver name that we used on our image. I know longer have this in place - however, I tracked the application as “screensaver.scr” (replace “screensaver” with real name). I then just took the usage data and did some additional calculations to get the idle time. The Power Management Module also gives some Idle Tracking and Control resources.
Note that in 8.0 power management, we actually check if the system is “idle” (no one has touched the keyboard or mouse for a while)… You can use the power management data for a computer to solve this problem too…
Ben - can you tell us if the new BigFix 8 idle calculation is used by DSS SAM when it calculates application usage time? Or is DSS SAM simply calculating the time the process was running (Is there any detail on how DSS SAM figures this out - my appologies if this is published, I do not see it out there anywhere)?
DSS SAM doesn’t incorporate into its usage calculations the user idle time tracked in Power Management.
SAM tracks the time a process is running, rather than when the window is active or a user is idle. BigFix has an application usage inspector that SAM leverages, and this inspector will track items such as how many times a process is launched, how long it’s run when it’s launched, etc.