One really cool usage of this was using ConfigMgr to run the script on PC's and add the information into WMI for inventorying later via mof edits.
Sherry Kissinger has an excellent article here:
While this is great for active clients, once the device is decommissioned or you have problems with the client and remove it from SCCM for one reason or another, your data is gone! Not so good for long term reporting or asset management.
Since I'm in the process of migrating all of our asset management reporting and information storage into Service Manager 2010, warranty expiration, start date, type etc was one of the main items of information that we needed to store so I started to think how I could automate this as much as possible.
3 Options sprang to mind:
- Supply Dell with a list of all our service tags and then CSV import it - allows large bulk updates but takes time if large volumes of updates required again.
- Implement the SCCM scripts then create a custom connector to gather the data - overly complex for my liking and duplicates the information storage
- Use Opalis to gather the data and update Service Manager - Sounded cool ;)
Things to note:
- This is proof of concept, failure handling etc would need adding for production
- I've extended the Windows Computer class in advance with a "Warranty Expiration Date" property. You could in theory extend any class to hold it, Computer (Deployed) might be more fitting but I've got other reasons for choosing the Windows Computer class.
So.... I created a policy that looks something like this:
All credit for this goes to Marcus Oh and his blog post here:
Et Voila! This could either be setup now to run when objects are updated by using the "Monitor Object" SCSM IP component and scoping it for updated serial number properties, or schedule it to run at scheduled times or even just manually when you desire.
Remember, this is proof of concept, it works in my test lab, but will need developing and testing before you would use it in a production environment.