Is K1000 able to detect when a monitor is pluged in or out of physical VGA port on desktop PC ? If it is, can that information be extracted from asset or inventory management for reporting purpose?


Answer Summary:
2 Comments   [ - ] Hide Comments


  • It does pickup that there is a monitor there, but in our case it just shows up as "Generic Monitor". I would assume that if the monitor was unplugged while the agent was checking in it would not show a monitor.
  • Yes, it does pickup Generic Monitor, but when I unpluged the monitor and forced inventory, it didn't show that monitor is missing... it was showing like nothing happend.
Please log in to comment

Answer this question or Comment on this question for clarity



If you want monitor information like Model, Serial Number, and Max Resolution, the free program MonitorInfoView works really well. I deploy the executable via Kace Scripting to the target machine, then run this command on a schedule: monitorinfoview.exe /HideInactiveMonitors 1 /stext C:\ProgramData\Dell\Kace\mon.mon

This dumps a file called mon.mon into C:\ProgramData\Dell\Kace directory then when the machine checks in a custom inventory rule runs to pull the fields I want from that file. Only active (currently plugged in) monitors are shown. In my experience, the script must run in the user context otherwise it would not work.

Custom Inventory Rule

ShellCommandTextReturn(cmd /c findstr "Monitor Name";"Serial Number ";"Manufacture Week ";"Maximum Resolution  ";"Last Update Time" C:\ProgramData\Dell\Kace\mon.mon)

(The trailing spaces in some of the strings were required for me)

Custom Inventory Field

You can then report on this custom inventory field.

Answered 03/12/2014 by: SDNBTP
Third Degree Blue Belt

  • Thank you for your answer, I'll try it tomorrow.
    I was wondering if it is possible to solve it through Custom Inventory Rule...
    Can KACE catch registry settings about monitor or maybe somehow driver setting/description about currently attached monitor, so when I disconnect Monitor A and connect monitor B, K1000 will show me under Hardware category that newly connected monitor B and not just "Generic Monitor"...
    • Using Custom Inventory Rules you can pull anything out of the registry. However pulling information about monitors from the registry may be limited/cryptic, the area where the information is stored may vary between OSes, and it may be difficult to differentiate which is the active monitor. Using other means would most likely run into the same limitations. The information is also only accurate at checkin. If someone changes monitors and the machine doesn't check in again to return the new information, it would be outdated until next check-in. Any method using Custom Inventory Rules will not update real time, only at next check-in.

      The 'Generic Monitor' entry matches whatever is in Device Manager. You are infact using a generic monitor driver. Unless you are installing actual monitor drivers on all your machines (not graphics drivers) this would be expected. Most people don't install monitor drivers.

      MonitorInfoView information is extracted from EDID ("Extended display identification data") records stored on your computer. The /HideInactiveMonitors parameter shows you all monitors that are connected at the time of the script running. I've explored a few different avenues for pulling monitor information... Using this utility was the easiest and made the most sense to me. It works really well.
      • Here is another post that may help, I used some of this to create my install.
      • I understand. Thank you for the effort and explanation. I'll try to manage it like you said.
      • No problem. Good luck!
      • I'm not getting returns using this custom inventory rule: ShellCommandTextReturn(findstr "Monitor Name";"Serial Number" c:\windows\system32\monitor.txt)
        Did you use that one? The file is generated by the managed install but I can't get anything from the CIR
      • You need to add cmd /c to your rule. Like this: ShellCommandTextReturn(cmd /c findstr "Monitor Name";"Serial Number" c:\windows\system32\monitor.txt)

        If it's still not working...
        Is your file being dumped to C:\Windows\System32\monitor.txt? I decided to use C:\ProgramData\Dell\Kace instead since all users have write access to this location. My script was only working in user context and we have standard users, so I needed an area where the user had write access. System32 is obviously off limits to standard user. Don't think this is causing your issue, but I would verify the file is dumping to where your custom inventory rule is pointing. Sounds like you may have already done this.

        I had to add spaces to my rule to get it to pull the fields properly. (The space at the end of "Serial Number " for example. Try playing around with the spacing.
        ShellCommandTextReturn(cmd /c findstr "Monitor Name";"Serial Number ";"Manufacture Week ";"Maximum Resolution ";"Last Update Time" C:\ProgramData\Dell\Kace\mon.mon)
        This pulled all the fields I needed.

        To test, just use a command prompt and take out the kace stuff until you get the results you need:
        findstr "Monitor Name";"Serial Number ";"Manufacture Week ";"Maximum Resolution ";"Last Update Time" C:\ProgramData\Dell\Kace\mon.mon
        • This content is currently hidden from public view.
          Reason: Removed by member request
          For more information, visit our FAQ's.
      • Thanks for sticking with me and helping! The cmd /c did the trick
      • yeah cmd /c is needed for ShellCommandTextReturn to work properly after K1000 version 5.4. Glad it's working.
  • It looks like this supports up through Windows XP. Is that correct?
    • Documentation says up to XP however I have deployed it to over 300+ Windows 7 machines without any issues. It is also running fine on a few Win 8.1 machines.
      • It's working for me on Windows 7. Thank you so much!
      • Awesome, you're welcome. Just wanted to also point out 'Last Update Time:' is the last time a change to monitors was detected, not the last time the command or program was run on that machine.
Please log in to comment