K1000 detecting plug in/out CRT/LCD monitors
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?
-
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. - AFCUjstrick 10 years ago
-
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. - dlistar 10 years ago
Answers (1)
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.
Comments:
-
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"... - dlistar 10 years ago-
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. - SDNBTP 10 years ago-
Here is another post that may help, I used some of this to create my install.
http://www.itninja.com/blog/view/k1000-use-a-third-party-program-in-a-managed-install-to-return-a-monitor-s-model-and-serial-number - SDNBTP 10 years ago -
I understand. Thank you for the effort and explanation. I'll try to manage it like you said. - dlistar 10 years ago
-
No problem. Good luck! - SDNBTP 10 years ago
-
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 - rockhead44 10 years ago -
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 - SDNBTP 10 years ago -
Thanks for sticking with me and helping! The cmd /c did the trick - rockhead44 10 years ago
-
yeah cmd /c is needed for ShellCommandTextReturn to work properly after K1000 version 5.4. Glad it's working. - SDNBTP 10 years ago
-
It looks like this supports up through Windows XP. Is that correct? - rockhead44 10 years ago
-
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. - SDNBTP 10 years ago
-
It's working for me on Windows 7. Thank you so much! - rockhead44 10 years ago
-
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. - SDNBTP 10 years ago