|
|
Overview  The Inventory Manager for Systems Center Configuration Manager 2007 is a unique tool that extends SCCM user interface and allows administrators to: · Easily view, edit and create inventory rules for hardware and software within SCCM · View and change properties and reporting attributes of built-in inventory rules · Create new rules for WMI values and registry keys using simple WMI and registry browsers that no longer require manual edit MOF files   Description Inventory Manager provides administrators the ability to custom tailor SCCM inventory to suit the needs of their company and remove the complexities of editing configuration MOF files by means of an intuitive and easy to use graphical user interface (GUI). Overview Currently administrators must manually edit the code in two text files (sms_def.mof and configuration.mof) by hand if they want to customize hardware and software inventory by SCCM. This requires knowledge and understanding of the programming language and syntax used in these files. The work involved is tedious, time consuming, susceptible to typographical errors which cost the administrator even more headaches. Even well experienced administrators and engineers can make mistakes here quite easily. Proposal Replace the manual, text based process with a front end solution that provides a GUI to allow the user to easily add, edit and remove inventory items from SCCM. Provide a completely rule based management solution, which takes all the guess work out inventory and speeds the process of managing inventory rule items in SCCM to a few minutes rather than several hours or possibly days. Reasoning If every possible piece of client data was enabled in inventory, SCCM databases would be too large to manage, so SCCM has a certain set of data included out of the box. Not long after the installation of SCCM, management often comes asking for information that isn’t being reported out of the box. This is where administrators start reading up on MOF’s and do one of two things. They either report back that SCCM can’t get the data, or they start down the laborious road of learning how to read and edit MOF files.   For the sake of an example, let’s say our administrator is asked to report on antivirus definition dates. Researching: The administrators will probably first try to query the SCCM database for these dates and come up empty. Reading the online help or the operations guide, he’ll be pointed to the MOF files and will see there is nothing in there mentioning antivirus dates. His next stop will probably be Google groups or myITforum groups. He might turn up something he feels he can copy and paste from or he can post and wait hours or days for a response on. Hopefully he’ll see he needs to not only create the class but setup reporting for it as well.   Programming: If the administrator was lucky to find exact code, he might get away with a simple copy and paste. More likely he’ll need to copy an existing entry in the MOF, but edit names and registry locations on the fly to get the mof pointed to the antivirus date keys in the registry. This is all done by hand in code where typos don’t stand out easily.     //==================================NAV INFO CLASS MOF #pragma namespace("\\\\.\\root\\CIMV2 <file:///\\root\CIMV2>") #pragma deleteclass("NAV",NOFAIL) [DYNPROPS] Class NAV { [key] string KeyName; string DEFWATCH_10; string NAVCORP_70; string Parent; string VirusEngine; }; [DYNPROPS] instance of NAV { KeyName = "NAV INFO"; [PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Intel\\LANDesk\\VirusProtect6\\CurrentVersion|Parent"), Dynamic, Provider("RegPropProv")] Parent; [PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Intel\\LANDesk\\VirusProtect6\\CurrentVersion|VirusEngine"), Dynamic, Provider("RegPropProv")] VirusEngine; [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Symantec\\SharedDefs|DEFWATCH_10"),Dynamic, Provider("RegPropProv")] DEFWATCH_10; [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Symantec\\SharedDefs|NAVCORP_70"),Dynamic, Provider("RegPropProv")] NAVCORP_70; }; //==================================NAV INFO REPORTING MOF #pragma namespace("\\\\.\\root\\cimv2\\sms <file:///\\root\cimv2\sms>") [SMS_Report(TRUE),SMS_Group_Name("NAV INFO"),SMS_Class_ID("NAV")] Class NAV : SMS_Class_Template { [SMS_Report(TRUE),key] string KeyName; [SMS_Report(TRUE)] string DEFWATCH_10; [SMS_Report(TRUE)] string NAVCORP_70; [SMS_Report(TRUE)] string Parent; [SMS_Report(TRUE)] string VirusEngine; };   Testing: The new MOF code now needs to be tested in the lab. This involves copying the MOF’s out, kicking off inventory on the clients, and looking for the new data to show up in queries or reports. This is hand coded and can never be assumed to be correct or safe, so testing is a critical part before deploying into production.   Change Controls: Every company has or should have a change control process that must be followed when introducing a new change into the environment. Since the legacy method of modifying inventory in SMS is based on manually modifying and programming code files, a change control to implement this is and should be a mandatory requirement. The communication process to gain approvals and allow stake holders to see and validate testing results can take anywhere from 1-7 days and in some cases much longer if communication within your company is slow possibly due to resource constraints which are typical in most environments.   Deployment: In SMS 2003 our administrator would have to do the following: · Add the MOF’s to the sms_def.mof file. · Create an advertisement to all systems in SMS and have them run the MOFCOMP command against the newly updated sms_def.mof file. · Wait for inventory to start coming back as clients run the advertisement and their hardware inventory. In SCCM 2007, once changes to the MOF’s are made, the policy manager pulls the edits into the client policy and begins applying to the client policies immediately. Therefore, it's absolutely imperative that the new edits be working correctly. Also the administrator now has two MOF files that must be edited and both have very specific uses and requirements that must be met.   Summary: This is a brief sample of the process scenario above, but you can see that managing inventory items in SMS/SCCM can be very complex, time consuming and a risky task to implement. The reasoning for having a better, more effective and safe way to manage inventory extensions within SMS/SCCM is highly needed. Administrators probably are not aware of all the items they could be reporting on or the database savings they could have if they disabled reporting on items they are not interested in. The GUI that Inventory manager provides makes it very clear to the administrator what is being inventoried so that unneeded items can be switched off and needed items can be easily and safely added. It’s obvious that to have a better more effective and safe way to manage inventory extensions within SCCM2007 is highly needed.   The Solution The Inventory Manager for Systems Center Configuration Manager 2007 is a unique tool that extends SCCM user interface and allows administrators to: · Easily view, edit and create inventory rules for hardware and software within SCCM · View and change properties and reporting attributes of built-in inventory rules · Create new rules for WMI values and registry keys using simple WMI and registry browsers that no longer require cut and paste into MOF files Adding new rules is easy. Just right click the Inventory Manager node, select to Create a new rule, (either a WMI Class or and registry type inventory rule), connect to a reference system, select the items desired to report back to SMS and click Apply. The Inventory manager handles editing the sms_def.mof and configuration.mof code files on the site server so that the admin never has to worry about programming any code, and because this solution writes the MOF edits accurately administrators don't need to worry about errors that might affect your production environment. Inventory Manger creates accurate MOF edits based on its ability to create WMI class and Registry key inventory items. It’s that simple and straight forward. Inventory Manger makes use of simple wizards to guide administrators through creating and selecting the inventory items attribute they wish to have SCCM report back from the client's inventory cycle.   Cost Benefits The return on investment for this solution is evident right from the start. With Inventory Manager, administrators can create a new rule in less than three minutes.   Scenario The administrator receives request to inventory 5 registry key values, it has been found that a new software deployment has caused errors in another business application and any systems that have these matching keys have been impacted the only way to find out how wide spread the problem has gone is to get this data.   Without Inventory Manager: An average administrator plans to create a new inventory rule - the old way. · 3-6 hours to research and program the MOF code · 8 hours to stage in lab, correct any errors, and retest. · 1 day to file company required change controls, send out communications and any other administrative tasks that might need to be done for this production change. Since this implements a change on the clients and is considered a customization (every time a new edit is added) a change control may be required. That could possibly take 1 - 7 days to receive approvals from management and stake holders to deploy and apply your new edit into to production. · 10 minutes to manually edit the sms_def.mof and configuration.mof, being very careful because any change saved to the file is delivered instantly, and even with a valid MOF, a user might make an accidentally copy paste of bad data before he realizes it’s too late and has to restore the backup mof files. The good news is that SCCM does that for you if it detects an error upon compile, but there are also cases where it tells SCCM to STOP inventorying any and all existing items if the error is severe enough - it just turns everything off. Considering all aspects above, it can take approximately three days to research, program, gain approvals and deploy just ONE inventory MOF item. Also consider that the an average administrator cost approx $85 per hour x 24 hours (3 X 8 hour working days), the average cost for one inventory item to be added or edited in production is $2040.00   With Inventory Manager: Considerations: Approved tool, endorsed by industry leaders with tested and proven success. This means administrators now have a tool that handles the inventory management process for them just as any other native tool inside SMS and because of this, it eliminates errors, time consuming research and testing and even change controls in many cases because it’s now a native process inside SCCM. Average time for creating a new inventory rule: · Open Admin Console, click Inventory Manager node, view existing rules, right click Inventory Manager node and select Add New Inventory Rule, loads simple self explanatory wizard that guides users through the steps. · One can easily create a rule and select one or more registry key values to inventory in less than three minutes, click apply, the new rule is created and your sms_def.mof and configuration.mof code files are automatically updated. · Done! Time to complete: 3 minutes (Create new inventory rule with simple wizard, integrated into SCCM, click apply). Even if it were still required to go through a testing and formal change management process to approve for production, the administrator would still be able to save a substantial amount of work.   Cost savings: Legacy and Manual method: Task: 1 rule with 5 registry key inventory items. Time to complete: 24 hours (program, test, approvals, deploy) Average cost to implement: $2040.00   (note: Although we are only assuming the administrators time and tasks, this cost may seem high, we are not factoring in any other resources that may have to participate in the process such as communications and approvals, when you factor the extended costs this amount is very realistic and could actually be quite higher overall.) Inventory Manager: Task: 1 rule with 5 registry key inventory items. Time to complete: 3 minutes (Create new inventory rule with simple wizard, integrated into SCCM, click apply) Cost: $4.25 -How's that for cost savings? Consider administrators may make 25 inventory edits per year and we'll consider the administrator is getting better at programming these edits and dealing with any administrative communications, so we'll divide the overall cost by half, and leave the cost of using the Inventory Manager alone.   Legacy / Manual Method: 25 edits x $ 2040.00 = $51,000.00 / 2 = $ 25500.00 per year Inventory Manager: 25 edits x $ 4.25 = $ 106.25 per year   Consider that Administrators could be pulling back inventory on a critical registry values that may be causing an issue in your environment and you have 10,000 systems, you can start getting back data in a matter of minutes. For about $4.25, you just isolated 3,000 systems that have been affected by a bad software install and you can now get busy with tackling that separate issue. Many companies are not making this many new inventory edits per year, and for some very real reasons; it's risky, takes a lot of time, and change control processes and approvals take time. If we eliminate the time, the risk and streamline the approval process with an automated solution, then every company could be extending their inventory to meet their business needs much more frequently and at a huge savings in time and cost.   Take control of your inventory today! Let Inventory Manager make it easy.               | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|