Software Inventory Tips for ConfigMgr

In general, Hardware Inventory customization is where most energy is spent in customization in ConfigMgr. But there are some tips and tricks to make Software Inventory better, as well.

Let me start by saying why I recommend customizing Software Inventory. Out of the box, the default SINV (software inventory) rule is *.exe on all drives. As a general statement, you usually don't need *.exe on all drives. Most software is installed into the "program files" section of a computer, so that's really all you need, 99% of the time. If you look at "inventoryagent.log" on a sample computer, look for how long a Software Inventory action takes. Depending upon how much is on the computer, how fast it is, whether it is hyperthreaded/dual processor or not, the speed of a SINV action is usually at least a few minutes, and *could* be several hours. I don't know about you, but several hours of scanning for all *.exe file information seems overkill, when I rarely need that information.

So, here's what you do. Remove the existing rule you have in SINV for *.exe on all drives. and replace it with these 2:

*.exe, %programfiles%\, include subdirectories, exclude files in the Windows Directory
*.exe, %programw6432%\, include subdirectories, exclude files in the windows directory

(OPTIONAL note: If we are talking about Configmgr 12, you may want to also have this rule in your CM12 SINV client agent properties: *.exe, %programfiles(x86)%\, include subdirectories, exclude files in the windows directory)

What does this gain you? Lots of time on the client, and less useless data in your database. If you do a quick baseline check of how long a SINV action took on a client when you were doing *.exe on all drives vs. just the *.exe in the program files folders, the client will finish much faster; and you'll still have all the information you really care about.

----------
Some optional prep work. Check to see if anyone is currently using a Collection query that references a specific .exe, which may or may not be in program files. Here's the sql, you could run in SQL Management Studio. You connect to your database, and run this, and see what collection queries are out there, referencing files:

Step 1: look for collections that have dependencies on software inventory filenames:
select crq.queryexpression
from v_collectionrulequery crq
where crq.queryexpression like '%filename%'

Step 2: you may need to export those results into a .csv so you can look at them easier. Unfortunately, this next part is the time consuming part. You may need to check in v_gs_softwarefile.filename and .filepath; and see if, for example, if there is a collection query looking for Widgets.exe, is widgets.exe only in Program Files? If so, then your existing rules limiting to just %programfiles% mentioned above will cover everything. But, if widgets.exe is in c:\SomeWierdLocation; you'll want to add in another rule in your SINV rules, looking specifically for widgets.exe in C:\SomeWierdLocation, so that the collection rule query will have appropriate results. Repeat for any other collections you have that look for a filename, specifically.

Another potential place you need to check might be reporting; it's hard to tell if someone is using one of the built in reports to look for all instances of foobar.exe, whether or not foobar.exe is in programfiles or not. In those cases, you may need to rely on the communications you send out, or wait for someone to ask why the report no longer works correctly.

----------
To me, using the sinv rules I've outlined above will alleviate your need for this next tip, but I'll mention it anyway. There's also a "skip this directory and all subdirectories" workaround you can implement. For example, perhaps you don't want c:\program files\widgets to have it's *.exe inventoried on a specific computer, but everything other *.exe in c:\program files you do want to be inventoried. On that single computer, you can place a "skip" file in that folder. http://technet.microsoft.com/en-us/library/bb632671.aspx

Posted by skissinger | with no comments
Filed under: ,

Non-Security Hotfix detection for Windows 7 / 2008

This topic came up recently in the forums.  After pondering it for a bit, I thought of several ways to obtain the information you need about a non-security hotfix.  Which approach you might take depends upon what you need, or what you need to do about the information, once you have it.

Beginning with the OS' of Windows 7 and Server 08; hotfixes aren't listed in Add/Remove Programs. That is normally fine because we have Software Updates.

But some non-security hotfixes seem to never be detectable with Software Updates.

A couple of suggestions:

  1. Before you check into any of the below possibilities, there are a lot of non-security updates which ARE detectable via SUM.  It may be that you simply haven't enabled that Category in your Software Updates Management.  Do a custom Search Folder in your Updates, and look for that hotfixID; see if it's there already.  If not, go to Site Settings, Component Configuration, Software Update Component, and carefully review the "Classifications", and "Products" tabs.  You normally do NOT want to enable everything.  But just check to see if what you are missing is simply because you didn't check the box for that product.
  2. If you have the addon to ConfigMgr, System Center Updates Publisher 2011, you can design your own rules for deploying an update, using the same methods that are used by security hotfixes.  That does take time, testing and planning of course.  There are guides out there on how to do so when you need to deploy a third party update which doesn't have a SCUP catalog.  For example, Adobe does have a 3rd party catalog for SCUP, but currently Java does not. (This is the one I would pursue if I needed to have a long term solution, if it was a quick one-off, I'd probably pick one of the other possibilities below).
  3. Another possibility for finding non-security updates is the following.  Although it was no longer enabled by default in the inventory definition file (sms_def.mof), it does still exist, and can be enabled (win32_quickfixengineering).  So you could enable that (change from FALSE to TRUE) and get the information back.  Personally, this is a lot of data for very little return; but it is one of the easiest solutions to implement.  (I wouldn't enable it in my environment, but it may be the right answer for your company.)
  4. If you know exactly which hotfixid you are looking for, you could create a DCM ConfigItem to look for
    that specific hotfixid in win32_quickfixengineering.  (This is my favorite; of course, I'm enamored of DCM in general)
  5. And Yet Another Possibility is this.  win32_quickfixengineering does contain all of the information, including security hotfixes.  We're already getting Security hotfix information from Software Updates.  So to have that information twice just seemed like a waste of space.  Here's a potential custom mof edit, to get back updates, but not security updates which you already get.  There will still be some overlap; because some non-security updates are already available in SUM (Software Update Management), but it's less overlap if you use this mof edit:


///Put the following on the bottom of your configuration.mof

//======================================
// Quick Fix Engineering, Limited
//======================================
#pragma deleteclass("qfeLTD",NOFAIL)
[Union, ViewSources{"select HotfixID,Description,ServicePackInEffect from win32_quickfixengineering where Description<>'Security Update'"},
ViewSpaces{"\\\\.\\root\\cimv2"},
dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]
class qfeLTD
{
 [PropertySources{"HotfixID"},Key ]           string HotfixID;
 [PropertySources{"Description"}  ]           string Description;
 [PropertySources{"ServicePackInEffect"},Key] string ServicePackInEffect;
};


////Put the following on the bottom of your sms_def.mof


//======================================
// Quick Fix Engineering, Limited
//======================================
#pragma deleteclass("qfeLTD",NOFAIL)

[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
 SMS_REPORT(TRUE),
 SMS_GROUP_NAME("qfeLTD"),
 SMS_Class_ID("CUSTOM|qfeLTD|1.0")]
class qfeLTD : SMS_Class_Template
{
 [SMS_Report(TRUE), key] String HotfixID;
 [SMS_Report(TRUE)     ] String Description;
 [SMS_Report(TRUE),key] String ServicePackInEffect;
};

My company did have the custom mof edit in place for about a month.  It worked fine, but we determined that it was literally one non-security hotfix that was being looked for.  So instead of getting back everything (it ended up being 8gb of data in the database!) I instead created a DCM rule to look for the specific hotfixid in win32_quickfixengineering.

Posted by skissinger | with no comments
Filed under: ,

ConfigMgr2012Beta2 Hardware Inventory Set Classes does not load

This has happened to me a few times as I experiment with adding custom classes to ConfigMgr 2012 Beta 2 hardware inventory.

I make a change, or want to re-import an existing custom reporting class.  Or I just did add a custom class, and it won't let me go back in and "Set Classes..."  It just says (in the pane) "Loading Inventory classes...", but it never loads them.

Here's a potential fix.  

go check <installed location>\logs\dataldr.log
Look for a line similar to this:
*** [42000][3705][Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot use DROP VIEW with 'v_HS_ABCSoftware0' because 'v_HS_ABCSoftware0' is a synonym. Use DROP SYNONYM.

In my case, ABCSoftware was a custom hardware inventory I was testing with, and it seemed like "all of the sudden", I couldn't use it anymore.  dataldr told me why.

Open up SQL Management Studio, and connect to your ConfigMgr 12 database (usually SMS_xxx, where xxx is your 3-char site code).  Do exactly what that line of code says, i.e.,   DROP SYNONYM v_hs_abcsoftware0   (in my example above). and hit Execute.

Something you may optionally need to do...you may not, but if DROP SYNONYM wasn't enough to allow you to see results in Set Classes... you may need to go to WMI (as an administrator).  Using wbemtest as an example...
wbemtest
connect
root\sms\site_abc   (because my site code is abc)
query...
select * from sms_inventoryclass
Scroll and look for your recently added custom class report definitions.  Highlight them (JUST those, the problem ones.  Leave the real ones alone!!! Danger here if you delete the wrong ones!!!).  and delete your custom report classes.

Now... go back into Default Client Agent Settings, Properties, and re-import your custom report mof snippet.  Should be all better now.

Posted by skissinger | with no comments
Filed under:

ConfigMgr2012Beta2 Hardware Inventory Custom WMI

Disclaimer: These instructions worked on Beta 2. No guarantees about RC, RTM, or honestly, if they will work in anyone else’s Lab environment but my own.  Your mileage may vary.  :)

Basic steps to be performed:

  1. Necessary at all?
  2. Truly Custom, or a pre-existing class?
  3. Obtain Edits
  4. Stage the ability for Clients to know HOW to report
  5. Stage the ability for Client to know WHAT to report
  6. Customize Client Settings
  7. Confirmation

Necessary at all?

Before you start, have you evaluated whether or not you actually need a hardware inventory edit at all?  Depending upon your past knowledge of how ConfigMgr 2007 or SMS 2003 worked, you may have gotten into the habit of thinking you need to know the custom WMI entry so you can create collections around that information.  In ConfigMgr 2012, using the new Application Deployment Method, that may no longer be necessary.  Instead of creating a collection with a certain custom WMI value as reported by HINV (Hardware Inventory), you could instead make that custom WMI value a parameter of the deployment.

Just a suggestion that perhaps you don’t need a hardware inventory edit at all!

Truly Custom, or a pre-existing class?

This document is for truly custom WMI edits, the type where a change to configuration.mof is necessary.  It may be all you want to do is pull in an existing WMI class, one that already exists.  If you are unsure, follow the online Technet documentation on Custom Hardware Inventory Edits.  If following those instructions about Add a Class work, you do not need these instructions.

Obtain Edits for Custom WMI Classes

There are very few Custom WMI edits out there.  Some of them are located on http://www.mofmaster.com, like the SQL version one, or the ServiceLTD one.  It’s rare that you would make up your own, custom WMI edit without finding one to suit your purposes already available online.  If you are unsure if what you need is a Custom WMI Class type, your best bet might be to post a query in the myitforum.com Forums, and see what other people advise you to do.

For demonstration purposes, the SQL version Custom WMI mof edit from ConfigMgr 2007, located, here, will be used: http://myitforum.com/cs2/blogs/skissinger/archive/2010/12/20/installed-sql-05-and-08-version-information-via-configmgr-hardware-inventory.aspx

Stage the ability for Clients to know HOW to report

On your ConfigMgr 2012 Beta 2 Server, browse to <installed location>\inboxes\clifiles.src\hinv

Potentially unnecessary paranoia step: copy the existing configuration.mof to a backup location.  You don’t necessarily need to; a backup will be taken for you and placed in <installed location>\data\hinvarchive. But sometimes paranoia is a good thing.

Using the latest trace exe (trace is located in <your beta2 source files>\Tools), open up <installed location>\logs\dataldr.log

Using Notepad, open up <installed location>\inboxes\clifiles.src\hinv\configuration.mof.  Scroll all the way to the bottom.  Near the bottom are some comments (Comments are started with two // characters) indicating that is where custom Extensions, like the ones we are doing here, should be placed.

From the Blog entry above, copy and paste ONLY the sections that start with //=================================

//Add the below two sections to the bottom of Configuration.mof
//=================================

Save the modified configuration.mof.

Back in your open trace32 view of dataldr.log, monitor that log file to confirm your edit has been accepted, and not rejected.  If rejected, potential rejection reason is that you missed something in the copy/paste, even missing the last } will cause a rejection.

Stage the ability for Client to know WHAT to report

To be clear, this step, on purpose, is to just stage the ability, not actually enable it.  Why we don’t enable it immediately will make sense in a later step.

Open up a notepad to a new entry.  Do a file, Save As, and change the type from txt to “all”, and save the empty file to a known location as (using this example) SQLHinvReporting.mof.

From the Blog entry above, copy and paste ONLY the section starting with:

//=================================
//Add these two sections to the bottom of sms_def.mof

And ending prior to the section that says:
//=================================
//Add the below two sections to the bottom of Configuration.mof

Save the File.

Launch your ConfigMgr 2012 Beta 2 Console, using an account with appropriate security rights to edit inventory data.

Go to Administration, client Settings.

Right-click on “Default Client Agent Settings”, Properties

Click on “Hardware Inventory” on the left.

Click on “Set Classes…”

Click on “Import…” and browse to find your saved, modified mof file (in this example, it was called SQLHinvReporting.mof)

After importing, you will notice that those new classes are by default set to TRUE.  Uncheck them so that by default they are set to False in your “Default Client Agent Settings”.  This will make sense in the next step.

Hit OK until you are back to client settings.

Customize Client Settings

In your Configmgr 2012 Beta 2 console, if you have not already done so, choose “create custom client settings”, and create ‘Custom Client Device Settings’.

Give it an appropriate name, like “Any box with SQL in Add Remove Programs”.  Check on the box for “Hardware Inventory”.

On the left, click on the now-available Hardware Inventory.

Click on “Set Classes…”

Check on the boxes for your custom classes (in this example, the SQL Property, and SQL Property Legacy)

Note: If you cannot check the boxes on, then in the earlier step above, in “Default Client Agent Settings”, you forgot to uncheck them there.  Go back to that step, and uncheck them there.

Hit OK until you are back to Client Settings

If you have not already done so (this is a brand new Client Device Setting), right-click on this customization, and Assign it to an appropriate collection.  For example, if this information should only be gathered from Computers which indicate sql is installed, assign it to that collection.  If you don’t have a SQL installed –specific collection, of course make one first, then assign it.

Note you do NOT have to make a custom Client Device Setting.  You could make it be by default enabled for every single client in your enterprise, by leaving it enabled on the ‘default client agent setting’.  But for demonstration purposes, this guide assumes you would want to have customized Hinv settings, that could then be targeted to a subset of clients.

Confirmation

The steps are essentially this:

On a client that should deserve to report on these WMI Classes, do machine policy refreshes. Monitor the client’s policyagent.log to confirm that it does pick up a new policy.

On the client, after you’ve confirmed the policy has been received, invoke a Hardware Inventory action.  Monitor the client’s inventoryagent.log to watch for the select statement indicating that it is reporting on the new classes.

On the server, monitor dataldr.log for that client’s inventory; once you see it pass through dataldr.log, you can now run reports, queries, or use Resource Explorer to confirm that information was successfully received.

Note: the views will be called something like v_gs_custom_sql_property<some  more characters> and v_gs_custom_sql_property_legacy<some more characters>.  If that *really* bothers you, having the word “custom” in there, prior to saving and importing the Reporting section (the “HOW” section), modify the SMS_Class_ID  from being something like (“CUSTOM|SQLProperty|1.0”) to just be “SQLProperty”

Posted by skissinger | with no comments
Filed under: ,

ConfigMgr2012Beta2 Hardware Inventory Registry Customization

Disclaimer: These instructions worked on Beta 2. No guarantees about RC, RTM, or honestly, if they will work in anyone else’s Lab environment but my own.  Your mileage may vary. 

Basic steps to be performed:

  1. Necessary at all?
  2. Obtain Edits
  3. Stage the ability for Clients to know HOW to report
  4. Stage the ability for Client to know WHAT to report
  5. Customize Client Settings
  6. Confirmation

Side Note: These instructions are written from the standpoint that you will have only 1 primary site server, not a CAS site and child primary sites.  Since in general most companies won’t need a CAS unless they are hugely multinational, or have more than 100,000 clients, a single site is the expected norm.  For those companies that will have a CAS, any different steps will be mentioned.

Necessary at all

Before you start, have you evaluated whether or not you actually need a hardware inventory edit at all?  Depending upon your past knowledge of how ConfigMgr 2007 or SMS 2003 worked, you may have gotten into the habit of thinking you need to know the registry key so you can create collections around that information.  In ConfigMgr 2012, using the new Application Deployment Method, that may no longer be necessary.  Instead of creating a collection with a certain regkey value as reported by HINV (Hardware Inventory), you could instead make that regkey value a parameter of the deployment.

Just a suggestion that perhaps you don’t need a hardware inventory edit at all!

Obtain Edits

Custom Registry Keys – individual, not dynamic used in this example

Mark Cochrane’s RegKeytoMof 3.0 or higher is required.  Older versions do not have the tab with the necessary edits for use with ConfigMgr 2012.

On a workstation or server which has the regkeys you need, use RegkeytoMof.

  1. Start by browsing to the registry to the location containing the registry keys.  Note that "HKeyCurrentUser" cannot be used, because the ConfigMgr Client is doing the regkey query, and it likely will not have the CurrentUser key you wanted to gather.
  2. Change the ClassName to something that makes sense. Try to keep it short, no spaces.

Stage the ability for Clients to know HOW to report

On your ConfigMgr 2012 Beta 2 Primary site Server, browse to <installed location>\inboxes\clifiles.src\hinv (If you have a CAS, browse to the CAS\Inboxes\clifiles.src\hinv, not a child primary)

Potentially unnecessary paranoia step: copy the existing configuration.mof to a backup location.  You don’t necessarily need to; a backup will be taken for you and placed in <installed location>\data\hinvarchive. But sometimes paranoia is a good thing.

Using the latest trace exe (trace is located in <your beta2 source files>\Tools), open up <installed location>\logs\dataldr.log

Using Notepad, open up <installed location>\inboxes\clifiles.src\hinv\configuration.mof.  Scroll all the way to the bottom.  Near the bottom are some comments (Comments are started with two // characters) indicating that is where custom Extensions, like the ones we are doing here, should be placed.

So, in regkeytomof, on the "ConfMgr12, Configuration.mof" tab, copy and paste the entire contents of that tab, without any changes, to the bottom of configuration.mof.

Save the modified configuration.mof.

Back in your open trace32 view of dataldr.log, monitor that log file to confirm your edit has been accepted, and not rejected.  If rejected, potential rejection reasons:

  • You missed something in the copy/paste, even missing the last } will cause a rejection.
  • You used special characters in the group name or class name.
  • Sometimes it is unavoidable to make modifications to the configuration.mof results.  For example, if you have a regkey which has a space, or has special characters, or is a reserved word, you may have to change the ‘label’ to be something acceptable.


Stage the ability for Client to know WHAT to report

To be clear, this step, on purpose, is to just stage the ability, not actually enable it.  Why we don’t enable it immediately will make sense in a later step.

Open up a notepad to a new entry.  Do a file, Save As, and change the type from txt to "all", and save the empty file to a known location as (using this example) abcsoftwareHinvReport.mof

From RegkeyToMof, the "ConfMgr12,to import in Admin/ Agent Settings/ HardwareInventory/ SetClasses/ Import " tab, copy and paste the contents into Notepad. 

Save the file, remembering the location you saved it into.

Launch your ConfigMgr 2012 Beta 2 Console (If you have a CAS, it is recommended that you connect the console to a child site), using an account with appropriate security rights to edit inventory data.

Go to Administration, client Settings.

Right-click on "Default Client Agent Settings", Properties

Click on "Hardware Inventory" on the left.

Click on "Set Classes…"

Click on "Import…" and browse to find your saved, modified mof file (in this example, it was called ABCSoftwareHinvReporting.mof)
After importing, you will notice that those new classes are by default set to TRUE.  Uncheck them so that by default they are set to False in your "Default Client Agent Settings".  This will make sense in the next step.

Hit OK until you are back to client settings.

Customize Client Settings

In your Configmgr 2012 Beta 2 console, if you have not already done so, choose "create custom client settings", and create ‘Custom Client Device Settings’.

Give it an appropriate name, like "All Windows 7 Customizations".  Check on the box for "Hardware Inventory".

On the left, click on the now-available Hardware Inventory.

Click on "Set Classes…"

Check on the boxes for your custom classes (in this example, the ABCSoftware, and ABCSoftware 64)

Note: If you cannot check the boxes on, then in the earlier step above, in "Default Client Agent Settings", you forgot to uncheck them there.  Go back to that step, and uncheck them there.

Hit OK until you are back to Client Settings

If you have not already done so (this is a brand new Client Device Setting), right-click on this customization, and Assign it to an appropriate collection.  For example, if this information should only be gathered from Windows 7 computers, assign it to that collection.  If you don’t have a Windows 7 –specific collection, of course make one first, then assign it.

Confirmation

If you need to ensure that the edit works as you expect on both X86 and X64 targets, test on both types.  But the steps are essentially this:

  1. On a client that should deserve to report on these registry keys, do machine policy refreshes. Monitor the client’s policyagent.log to confirm that it does pick up a new policy.
  2. On the client, after you’ve confirmed the policy has been received, invoke a Hardware Inventory action.  Monitor the client’s inventoryagent.log to watch for the select statement indicating that it is reporting on the new classes.
  3. On the server, monitor dataldr.log for that client’s inventory; once you see it pass through dataldr.log, you can now run reports, queries, or use Resource Explorer to confirm that the regkey information was successfully received.

Note: the views will be called something like "v_gs_custom_abcsoftware0" and "v_gs_custom_abcsoftware640".  If that *really* bothers you, having the word "custom" in there, prior to saving and importing the Reporting section (the "HOW" section), modify the SMS_Class_ID  from being something like ("CUSTOM|ABCsoftware|1.0") to just be "ABCSOFTWARE"

Posted by skissinger | with no comments
Filed under: ,

Hardware Inventory mof edit for win32_TerminalServiceSetting

John Costello, in -->this<-- forum entry was looking to correctly gather win32_terminalservicesetting information from both Windows Server 2003, and Server 2008 clients.  From 1 OS to the next, the location in WMI changed enough so that a special mof edit was required.

Below is the mof edit that he has tested in his environment.

//This next section goes at the bottom of Configuration.mof
// Edit Created by John Costello
======================================================
//---------------------------------------------
// TS 2008 Properties
//---------------------------------------------
 
[Union, ViewSources{"select ServerName,TerminalServerMode,LicensingName from Win32_TerminalServiceSetting"},ViewSpaces{"\\\\.\\root\\cimv2\\TerminalServices"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]
 
class ts_win2008
 

    [PropertySources{"ServerName"},key  ] string ServerName;
    [PropertySources{"TerminalServerMode"}  ] uint32 TerminalServerMode;
    [PropertySources{"LicensingName"}  ] string LicensingName;
};
 
//---------------------------------------------
// TS 2003 Properties
//---------------------------------------------
 
[Union, ViewSources{"select ServerName,TerminalServerMode,LicensingName from Win32_TerminalServiceSetting"},ViewSpaces{"\\\\.\\root\\cimv2"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]
 
class ts_win2003
 

    [PropertySources{"ServerName"},key  ] string ServerName;
    [PropertySources{"TerminalServerMode"}  ] uint32 TerminalServerMode;
    [PropertySources{"LicensingName"}  ] string LicensingName;
};

//============================
// This next section goes at the bottom of sms_def.mof
//==============================

//                            Terminal Server 2008 Information                        Class Created:  6/15/2011

[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
 SMS_Report (TRUE),
 SMS_Group_Name ("TS_Win2008"),
 SMS_Class_ID ("CUSTOM|TS_Win2008|1.0")]

class ts_win2008 : SMS_Class_Template
{
[SMS_Report(TRUE),key] string ServerName;
[SMS_Report(TRUE)] uint32 TerminalServerMode;
[SMS_Report(TRUE)] string LicensingName;
};


//                            Terminal Server 2003 Information                        Class Created:  6/15/2011

[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
 SMS_Report (TRUE),
 SMS_Group_Name ("TS_Win2003"),
 SMS_Class_ID ("CUSTOM|TS_Win2003|1.0")]

class ts_win2003 : SMS_Class_Template
{
[SMS_Report(TRUE),key] string ServerName;
[SMS_Report(TRUE)] uint32 TerminalServerMode;
[SMS_Report(TRUE)] string LicensingName;
};

//================

With those mof edits, you'll end up with two views, likely called v_gs_ts_win20030, and v_gs_ts_win20080. 

What is this information good for?  According to http://msdn.microsoft.com/en-us/library/aa383640%28v=vs.85%29.aspx, TerminalServerMode is either 1 or 0.  A 1 means the server operates as an application server, a 0 means it is administered remotely.  LicensingName is 'The Name of the Licensing Mode'.

Posted by skissinger | with no comments
Filed under: ,

Hardware Inventory mof edit for .net Frameworks (updated with v1)

This updated mof snippet adds in v1.0 for .net Frameworks, if you happen to have older OS' out there, or XP Media Center Edition. 

If you currently have dotNetframeworks (older) mof edit, you may want to carefully check if replacing the old one with this new one will affect any current collection queries or reports. Fyi, there isn't any SP 's for v4 yet; so in the v4 section I made a complete guess about what the regkey might be if a ServicePack ever comes out for v4.  There may never be one, or if there is one, I've guessed the regkey incorrectly.  That might need to be updated if my guess is wrong.

The registry key locations are from http://support.microsoft.com/kb/318785/en-us

Mof Snippets -->Here<--

If you implement this mof snippet, here's a potential report.

 select sys1.netbios_name0,
        MAX(CASE dn.version0 when '1.0' THEN
          case dn.installed0 when '1' then dn.BuildNumber0 End END) AS [.Net 1.0],
        MAX(CASE dn.version0 when '1.0 MCE' THEN
          case dn.installed0 when '1' then dn.BuildNumber0 End END) AS [.Net 1.0 MCE],
        MAX(CASE dn.version0 when '1.1' THEN
          case dn.installed0 when '1' then dn.BuildNumber0 End END) AS [.Net 1.1],
        MAX(CASE dn.version0 when '1.1' THEN
          case dn.installed0 when '1' then dn.ServicePack0 End END) AS [.Net 1.1 SP],
        MAX(CASE dn.version0 when '2.0' THEN
          case dn.installed0 when '1' then dn.BuildNumber0  end END) AS [.Net 2.0],
        MAX(CASE dn.version0 when '2.0' THEN
          case dn.installed0 when '1' then dn.ServicePack0  end END) AS [.Net 2.0 SP],
        MAX(CASE dn.version0 when '3.0' THEN
          case dn.installed0 when '1' then dn.BuildNumber0  end END) AS [.Net 3.0],
        MAX(CASE dn.version0 when '3.0' THEN
          case dn.installed0 when '1' then dn.ServicePack0  end END) AS [.Net 3.0 SP],
        MAX(CASE dn.version0 when '3.5' THEN
          case dn.installed0 when '1' then dn.BuildNumber0  end END) AS [.Net 3.5],
        MAX(CASE dn.version0 when '3.5' THEN
          case dn.installed0 when '1' then dn.ServicePack0 end END) AS [.Net 3.5 SP],
        MAX(CASE dn.version0 when '4.0' THEN
          case dn.installed0 when '1' then dn.BuildNumber0  end END) AS [.Net 4.0]

FROM
v_r_system AS sys1
Left Join v_gs_dotnetframeworks0 dn
ON dn.resourceid=sys1.ResourceID
group by sys1.netbios_name0
 
  
Posted by skissinger | with no comments
Filed under: ,

AutoDesk (AutoCad) information via DCM and Mof Edit

For a project, I got the mof edits for CM07, and they worked, but wow, they created tables and views for every minor release (26 tables and views!  yipes!)  
 
You'd take the attached and either drop it into a DCM (just like you would for LocalGroupMembers DCM), or ship it out as a vbscripted recurring advertisement.  You could target that DCM or advert just to a collection w/Autocad listed in ARP, or even to all workstations/servers.  Only boxes w/the regkeys should create the custom namespace locally. Theoretically, you'd end up with just 1 table and view, for all of the autodesk products (as listed in the script, their 'parent' regkey).  if/when version "R19" comes out, you'd have to add another str1 variable, and increment everything where the script enumerates through from 25 to 26, but it would still be cleaner than the multiple edits that are currently necessary.
 

fyi, this routine was only done in a lab, and 1 other environment, use at your own risk, etc. etc. 


And here's the mof edit, for sms_def.mof only, should end up with v_gs_autodeskcombo0 for a view: 

 
//----------------
//Mof edit for Autodesk products, 
//Note, must be used with a DCM recurring CI, or a recurring Advert script
//----------------
[ SMS_Report     (TRUE),
  SMS_Group_Name ("AutoDeskCombo"),
  SMS_Class_ID   ("Custom|AutoDesk|1.0") ]

class cm_AutoDesk : SMS_Class_Template
{
    [SMS_Report (TRUE),key] string KeyName;
    [SMS_Report (TRUE)    ] string ProductName;
    [SMS_Report (TRUE)    ] string Rel;
    [SMS_Report (TRUE)    ] string SerialNumber;
    [SMS_Report (TRUE)    ] uint32 StandaloneNetworkType;
};

 

For those of you who aren't too familiar with using DCM, here's a (hopefully) step by step:

Step 1:  The DCM Configuration Item.
- Create a new, General Configuration Item, call it whatever Name you wish. For this demo, the name is "AutoDesk Info into WMI", click Next
- There are no Objects, click Next
- Under Settings, Select New, Script.
  - Display Name doesn't matter, I'll call it "WMIFramework For AudoDesk"
  - Description can be anything, perhaps something like "Building the Custom WMI Namespace of root\cimv2\cm_autodesk for later inventory retrieval"
  - and paste in the vbscript
  - Click on the Validation Tab, and change Severity to "Information - no Windows Event Message".  Retain the check box for "report a non-compliance event when this instance count fails, of Greater than 0
  - OK
- Applicability = All Windows Platforms.

Step 2:  Create a DCM Baseline, or if you already have a DCM Baseline targeted to an appropriate Collection, add this CI to that Baseline.  If you do not already have an appropraite one, create a DCM Baseline, name doesn't matter, and add the CI to the "These applications and general configuration items are required and must be properly configured"

Step 3: Right-click that DCM Baseline, and assign it to a collection--whichever collection is appropriate.  I.e., you could create a collection of machines with anything autocad in ARP, and assign to them.  Or you can just assign it to "all systems".  When you assign, you are required to select a schedule.  I recommend a Simple Schedule, and to make it be the same as your existing Simple Hardware Inventory schedule, i.e., if you have Hinv every 3 days, make this every 3 days.

Step 4: add in the sms_def.mof edit to inboxes\clifiles.src\hinv\sms_def.mof on all of your primary sites (to the bottom)

One Way to Deploy SCUP 4.5 Certificates

I forget who it was (sorry!) but at MMS, someone asked me to blog how we deployed our SCUP certificates. 

To put everything in context, we essentially followed Jason Lewis' instructions on how to setup SCUP 4.5: http://blogs.technet.com/b/jasonlewis/archive/2007/11/30/how-to-setup-scup-and-configmgr-2007-to-deploy-custom-updates.aspx

Within those instructions, he indicates using certutil from the Windows Server 2003 Admin toolkit, to run (for example):

certutil.exe -addstore ROOT <certname>.cer
and
certutil.exe -addstore TrustedPublisher <certname>.cer

Interpreting those instructions to be a package/program/advertisement, this is what I have in the package source:

4 files:

2 from the toolkit:
certutil.exe
certadm.dll

1 cert file from my SCUP implementation:
MyServerCert.cer

1 vbscript:
InstallSCUPCert.vbs

Here is inside the vbscript, be careful of word wrap, there are 15 lines:

On Error Resume Next
Set sho = Wscript.CreateObject("Wscript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")
strCurrentDir = Left(Wscript.ScriptFullName, (InstrRev(Wscript.ScriptFullName, "\") -1))
Set strSysFolder = FSO.GetSpecialFolder(1) 'get system32 folder
'Copy the dll to the system folder
FSO.CopyFile strcurrentdir & "\certadm.dll",strSysFolder & "\"
'Register the dll
sho.Run "cmd.exe /c regsvr32.exe /s " & Chr(34) &_
  strSysFolder & "\certadm.dll" & Chr(34),0,vbTrue
intret = sho.Run(strcurrentdir & "\certutil.exe -addstore " & Chr(34) &_
"ROOT" & Chr(34) & " " & strCurrentDir & "\MyServerCert.cer",0,vbTrue)
intret2 = sho.Run(strcurrentdir & "\certutil.exe -addstore " & Chr(34) &_
"TrustedPublisher" & Chr(34) & " " & strCurrentDir & "\MyServerCert.cer",0,vbTrue)
wscript.quit(intret+intret2)

End result, advertise cscript.exe InstallSCUPCert.vbs, and the cert will be installed into root and trusted publishers. 

Posted by skissinger | with no comments

Mark Cochrane's RegKeyToMof v2.6

Mark has updated RegKeyToMof to v2.6!

 

So, what's new?  It will correctly interpret  multi-reg or binary regkeys and add the braces [ ], as well as define a "default", if the default regkey is populated.  So it's even smarter than it was before.

 

Here's a sample of how you would use it.  Let's say you have some custom regkeys, ABCStuff, which you want to grab via Hardware Inventory.  It includes data in the (default) value, as well as binary, dword, multi-sz, as well as string

How to Use RegKeytoMof:

  1. While on either the x64 computer or the x86 computer, launch "RegKeyToMofv2.5.exe"
  2. Browse to "Software\ABCStuff"
  3. Change the ClassGroup and ClassName to be values you want
    a. For me, I always change the group to be "CUSTOM", however, if you work for ACME Corporation, you may want to change it to "ACMECorp" for example.  It's really simply a label.
    b. Change the ClassName to be something unique, and no spaces is recommended.  For this edit, I'm going to use "ABCStuff"
  4. Check the box about "Enable 64bits"

Now follow the wiki, on updating your mof files and confirming the edit worked.  You simply copy and paste the contents of the tabs appropriate to your environment into the mof files on your server(s), and follow the wiki.

5. Now that you have data in your database, here's a sample sql query, and the resulting report.

To interpret what that means...
   5a. workstation1 is a 32-bit OS, and as such, does not have WMI provider architechture that would try to report on 64-bit regkeys (this line in the

sms_def.mof edit:  SMS_Context_1("__ProviderArchitecture=64|uint32").  For that reason, there is only 1 row of data returned for workstation1.
   5b. workstation2 is a 64-bit OS, and does have both providerarchitechtures, 32 and 64.  So it will *attempt* to report on registry keys in both areas, that's why there are two rows of data, but the attributes that correspond to registry keys are null for those that don't exist, and contain data for the ones that do exist.

From a collection query creation standpoint, or from a reporting standpoint, having to look only in 1 location when you design your SQL or WQL queries is a very cool and timesaving thing.  Not only to you, but your database has 1 less table, view, and stored procedures

Posted by skissinger | with no comments
Filed under: ,

Determining Server08 Core using Hardware Inventory

It may be difficult to determine the SKUVersion (Standard, Core, DataCenter, SBS, Enterprise) of Server08.  Here's one way to extend Hardware Inventory to pull in the attribute "OperatingSystemSKU" from win32_operatingsystem.  That attribute is only available on Vista and higher, so we can't just add it into the existing win32_operatingsystem default mof edit.

Edits to both configuration.mof, and sms_def.mof are needed to pull this off.  Once you've added the sections to the bottom of your mof files, you'll get a new view, v_gs_OSAddtl0, but only for those computers which have the OperatingSystemSKU attribute.

//---------------------------------------------
// Custom OS properties, place this section bottom of sms_def.mof
//---------------------------------------------


[ SMS_Report     (TRUE),
  SMS_Group_Name ("OSAddtl"),
  SMS_Class_ID   ("CUSTOM|OSAddtl|2.0") ]

class CM_CustomOSAddtl : SMS_Class_Template
{
    [SMS_Report (TRUE), key ]        string     Name;
    [SMS_Report (TRUE)      ]        uint32     OperatingSystemSKU;
};

 

//---------------------------------------------
// Custom OS properties, place this section bottom of configuration.mof
//---------------------------------------------

[Union, ViewSources{"select Name, OperatingSystemSKU from win32_operatingsystem"},ViewSpaces{"\\\\.\\root\\cimv2"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

class CM_CustomOSAddtl


   [PropertySources{"Name"},key ]            string Name;
   [PropertySources{"OperatingSystemSKU"}  ] uint32 OperatingSystemSKU;
};

 

Potential Report:

Select SYS.Netbios_Name0, OPSYS.Caption0, OPSYS.Version0, OPSYS.CSDVersion0,
osa.name0, osa.operatingsystemsku0
,Case
when osa.operatingsystemsku0=0 then 'Undefined'
when osa.operatingsystemsku0=1 then 'Ultimate'
when osa.operatingsystemsku0=2 then 'Home Basic Edition'
when osa.operatingsystemsku0=3 then 'Home Basic Premium Edition'
when osa.operatingsystemsku0=4 then 'Enterprise Edition'
when osa.operatingsystemsku0=5 then 'Home Basic N Edition'
when osa.operatingsystemsku0=6 then 'Business Edition'
when osa.operatingsystemsku0=7 then 'Standard Server Edition'
when osa.operatingsystemsku0=8 then 'Datacenter Server Edition'
when osa.operatingsystemsku0=9 then 'Small Business Server Edition'
when osa.operatingsystemsku0=10 then 'Enterprise Server Edition'
when osa.operatingsystemsku0=11 then 'Starter Edition'
when osa.operatingsystemsku0=12 then 'Datacenter Server Core Edition'
when osa.operatingsystemsku0=13 then 'Standard Server Core Edition'
when osa.operatingsystemsku0=14 then 'Enterprise Server Core Edition'
when osa.operatingsystemsku0=15 then 'Enterprise Server IA64 Edition'
when osa.operatingsystemsku0=16 then 'Business N Edition'
when osa.operatingsystemsku0=17 then 'Web Server Edition'
when osa.operatingsystemsku0=18 then 'Cluster Server Edition'
when osa.operatingsystemsku0=19 then 'Home Server Edition'
when osa.operatingsystemsku0=20 then 'Storage Express Server Edition'
when osa.operatingsystemsku0=21 then 'Storage Standard Server Edition'
when osa.operatingsystemsku0=22 then 'Storage Workgroup Server Edition'
when osa.operatingsystemsku0=24 then 'Server For Small Business Edition'
when osa.operatingsystemsku0=25 then 'Small Business Server Premium Edition'
end as [SKU OS Type]
from v_R_System SYS
join v_GS_OPERATING_SYSTEM OPSYS on SYS.ResourceID=OPSYS.ResourceID
left join v_gs_OSAddtl0 osa on osa.resourceid=sys.resourceid
order by SYS.Netbios_Name0

Note: Inspired by a request from Sumradagnoth.


Posted by skissinger | with no comments
Filed under: ,

Installed SQL 05 and 08 version information via ConfigMgr Hardware Inventory

I've seen this request multiple times, and with John Nelson's help, here's a mof edit and a sample report to answer the question of "what version of sql, and what service pack, and/or Cumulative Updates have been applied"

 

You will likely need to consult with an outside source, like http://www.sqlsecurity.com/FAQs/SQLServerVersionDatabase/tabid/63/Default.aspx, to answer the question of exactly what cumulative update or sql hotfix is applied, but this mof edit should get you most of the way there.  Attached are the mof snippets, as .txt files in case that is easier than copy/paste.

 

//=================================
//Add these two sections to the bottom of sms_def.mof
//=================SQL Information 2008 and possibly newer

[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
 SMS_Report(TRUE),
 SMS_Group_Name("SQL Property"),
 SMS_Class_ID("CUSTOM|SQL_Property|2.0")]
class cm_sql08 : SMS_Class_Template


    [SMS_Report(TRUE)    ]  boolean IsReadOnly; 
    [SMS_Report(TRUE),key]  uint32 PropertyIndex; 
    [SMS_Report(TRUE),key]  string PropertyName;
    [SMS_Report(TRUE)    ]  uint32 PropertyNumValue;
    [SMS_Report(TRUE)    ]  string PropertyStrValue;
    [SMS_Report(TRUE)    ]  uint32 PropertyValueType;
    [SMS_Report(TRUE),key]  string ServiceName;
    [SMS_Report(TRUE),key]  uint32 SqlServiceType;
};

//==================SQL Information 2000 (possibly) and 2005

[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
 SMS_Report(TRUE),
 SMS_Group_Name("SQL Property Legacy"),
 SMS_Class_ID("CUSTOM|SQL_Property_Legacy|2.0")]

class cm_sql2kand05 : SMS_Class_Template


    [SMS_Report(TRUE)    ]  boolean IsReadOnly; 
    [SMS_Report(TRUE),key]  uint32 PropertyIndex; 
    [SMS_Report(TRUE),key]  string PropertyName;
    [SMS_Report(TRUE)    ]  uint32 PropertyNumValue;
    [SMS_Report(TRUE)    ]  string PropertyStrValue;
    [SMS_Report(TRUE)    ]  uint32 PropertyValueType;
    [SMS_Report(TRUE),key]  string ServiceName;
    [SMS_Report(TRUE),key]  uint32 SqlServiceType;
};

//=================================
//Add the below two sections to the bottom of Configuration.mof
//=================================

//---------------------------------------------
// SQL 2008 (and possibly higher) Properties
//---------------------------------------------

[Union, ViewSources{"select IsReadOnly,PropertyIndex,PropertyName,PropertyNumValue,PropertyStrValue,PropertyValueType,ServiceName,SqlServiceType from sqlServiceAdvancedProperty"},ViewSpaces{"\\\\.\\root\\microsoft\\sqlserver\\computermanagement10"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

class cm_sql08


    [PropertySources{"IsReadOnly"}        ] boolean IsReadOnly;
    [PropertySources{"PropertyIndex"},key ] uint32 PropertyIndex;
    [PropertySources{"PropertyName"},key  ] string PropertyName;
    [PropertySources{"PropertyNumValue"}  ] uint32 PropertyNumValue;
    [PropertySources{"PropertyStrValue"}  ] string PropertyStrValue;
    [PropertySources{"PropertyValueType"} ] uint32 PropertyValueType;
    [PropertySources{"ServiceName"},key   ] string ServiceName;
    [PropertySources{"SqlServiceType"},key] uint32 SqlServiceType;
};

//---------------------------------------------
// SQL 2000/2005 Properties
//---------------------------------------------

[Union, ViewSources{"select IsReadOnly,PropertyIndex,PropertyName,PropertyNumValue,PropertyStrValue,PropertyValueType,ServiceName,SqlServiceType from sqlServiceAdvancedProperty"},ViewSpaces{"\\\\.\\root\\microsoft\\sqlserver\\computermanagement"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

class cm_sql2kand05


   [PropertySources{"IsReadOnly"}        ] boolean IsReadOnly;
   [PropertySources{"PropertyIndex"},key ] uint32 PropertyIndex;
   [PropertySources{"PropertyName"},key  ] string PropertyName;
   [PropertySources{"PropertyNumValue"}  ] uint32 PropertyNumValue;
   [PropertySources{"PropertyStrValue"}  ] string PropertyStrValue;
   [PropertySources{"PropertyValueType"} ] uint32 PropertyValueType;
   [PropertySources{"ServiceName"},key   ] string ServiceName;
   [PropertySources{"SqlServiceType"},key] uint32 SqlServiceType;
};


Here is a potential report, and what it might look like:

select sys1.Netbios_name0,
max(Case sql.PropertyName0 when 'SKUName' then
   sql.PropertySTRValue0 end) as [SQL08 Type]
,max(Case sql.PropertyName0 when 'SPLEVEL' then
   sql.PropertyNUMValue0 end) as [SQL08 Service Pack]  
,max(Case sql.PropertyName0 when 'VERSION' then
   sql.PropertySTRValue0 end) as [SQL08 Version]
,max(Case sql.PropertyName0 when 'FILEVERSION' then
   sql.PropertySTRValue0 end) as [SQL08 CU Version]
,max(Case sql2.PropertyName0 when 'SKUName' then
   sql2.PropertySTRValue0 end) as [SQL05 Type]
,max(Case sql2.PropertyName0 when 'SPLEVEL' then
   sql2.PropertyNUMValue0 end) as [SQL05 Service Pack]
,max(Case sql2.PropertyName0 when 'VERSION' then
   sql2.PropertySTRValue0 end) as [SQL05 Version]
,max(Case sql2.PropertyName0 when 'FILEVERSION' then
   sql2.PropertySTRValue0 end) as [SQL05 CU Version]
from v_r_system sys1
left join v_gs_sql_property0 sql on sys1.resourceid=sql.ResourceID
left join v_gs_sql_property_legacy0 sql2 on sys1.ResourceID=sql2.ResourceID
where sql.PropertyName0 in ('SKUNAME','SPLevel','version','fileversion')
or
sql2.PropertyName0 in ('SKUNAME','SPLevel','version','fileversion')
group by sys1.Netbios_name0

 

Posted by skissinger | with no comments

Mark Cochrane's RegKeyToMof v2.5

Mark has updated his excellent RegKeytoMof utility for custom regkey MOF edit creations. The coolest part about it is a better method of pulling in registry keys from the 64-bit registry section. 

I'm in love with it, because of how the end result is that there is only 1 table and 1 view in your database, making report writing that much easier (fewer joins). 

Major kudos go to Jonas Hettich for figuring out the intricasies of how this type of mof edit works.

This blog entry will step through how to use RegKeytoMof to create a (fictitious) custom mof entry for "ABCStuff"

Below is a screen shot of the registry of a x86 computer, and a x64 computer.

How to Use RegKeytoMof:

  1. While on either the x64 computer or the x86 computer, launch "RegKeyToMofv2.5.exe"
  2. Browse to "Software\ABCStuff"
  3. Change the ClassGroup and ClassName to be values you want
    a. For me, I always change the group to be "CUSTOM", however, if you work for ACME Corporation, you may want to change it to "ACMECorp" for example.  It's really simply a label.
    b. Change the ClassName to be something unique, and no spaces is recommended.  For this edit, I'm going to use "ABCStuff"
  4. Check the box about "Enable 64bits"

Screen shot of the work so far:

Now we have a very, very close base.  Most of the time you could copy the contents of the tabs "SCCM Configuration.mof" and "SCCM sms_def.mof" directly to the bottom of your inboxes\clifiles.src\hinv files, and be golden.

However, for this particular mof edit, I made sure to add in some special cases, that might trip you up.  As mentioned, most of the time you won't have these special cases.

Three things:

  1. I'm asking for the value of the (Default) regkey.  that requires a manual edit.
  2. one of the values I want "MultiSZIWant", contains multiple strings.  In order to pull that information in nicely, there is another manual edit.
  3. one of the values I want "BinaryIwant", also needs a manual edit.

5. To adjust for the (Default) regkey, a label is required.  There are 6 places to put in that label; 4 places in configuration.mof, and 2 in sms_def.mof.

6. To adjust for the multiple string values, there is 4 places to put in braces [], 2 places in configuration.mof, and 2 in sms_def.mof.

7. To adjust for the binary value, there is 4 places to put in braces [], 2 places in configuration.mof, and 2 in sms_def.mof.

Attached is the completed mof edit. 

Notes: I decided to label the default value "TheDefault"  so search for that in the files to see how that was accomplished.  For the multi-values, search for the [] to see where those should be placed.

8. Now follow the wiki, on updating your mof files and confirming the edit worked:

9. Now that you have data in your database, here's a sample sql query, and the resulting report.
 

To interpret what that means...
   9a. workstation1 is a 32-bit OS, and as such, does not have WMI provider architechture that would try to report on 64-bit regkeys (this line in the

sms_def.mof edit:  SMS_Context_1("__ProviderArchitecture=64|uint32").  For that reason, there is only 1 row of data returned for workstation1.
   9b. workstation2 is a 64-bit OS, and does have both providerarchitechtures, 32 and 64.  So it will *attempt* to report on registry keys in both areas, that's why there are two rows of data, but the attributes that correspond to registry keys are null for those that don't exist, and contain data for the ones that do exist.

From a collection query creation standpoint, or from a reporting standpoint, having to look only in 1 location when you design your SQL or WQL queries is a very cool and timesaving thing.  Not only to you, but your database has 1 less table, view, and stored procedures

Posted by skissinger | with no comments
Filed under: ,

BitLocker and Trusted Platform Module (TPM) mof edit

Panu Saukko, a configMgr MVP, forwarded this mof edit to share:

//
// BitLocker related information
// Panu Saukko, 17.11.2010

[ SMS_Report     (TRUE),
  SMS_Group_Name ("BitLocker Volume Encryption"),
  SMS_Class_ID   ("MICROSOFT|BITLOCKER_VOLUME_ENC|1.0"),
  SMS_Namespace  (FALSE),
  Namespace      ("\\\\\\\\localhost\\\\root\\\\cimv2\\\\security\\\\MicrosoftVolumeEncryption") ]

class Win32_EncryptableVolume : SMS_Class_Template
{
    [SMS_Report (TRUE), key ]        string     DeviceID;
    [SMS_Report (TRUE)      ]        string     DriveLetter;
    [SMS_Report (FALSE)     ]        string     PersistentVolumeID;
    [SMS_Report (TRUE)      ]        uint32     ProtectionStatus;
};

[ SMS_Report     (TRUE),
  SMS_Group_Name ("Trusted Platform Module"),
  SMS_Class_ID   ("MICROSOFT|TRUSTED_PLATFORM_MODULE|1.0"),
  SMS_Namespace  (FALSE),
  Namespace      ("\\\\\\\\localhost\\\\root\\\\cimv2\\\\security\\\\MicrosoftTPM") ]

class Win32_TPM : SMS_Class_Template
{
    [SMS_Report (TRUE)      ]        boolean    IsActivated_InitialValue;
    [SMS_Report (TRUE)      ]        boolean    IsEnabled_InitialValue;
    [SMS_Report (TRUE)      ]        boolean    IsOwned_InitialValue;
    [SMS_Report (FALSE), key]        uint32     ManufacturerId;
    [SMS_Report (TRUE)      ]        string     ManufacturerVersion;
    [SMS_Report (FALSE)     ]        string     ManufacturerVersionInfo;
    [SMS_Report (FALSE)     ]        string     PhysicalPresenceVersionInfo;
    [SMS_Report (TRUE)      ]        string     SpecVersion;

}; 

Posted by skissinger | with no comments
Filed under: ,

SMSBackup false positive, harddiskvolumeshadowcopy not readable

Situation: server08 x64 sp1, configmgr 07 sp2/r2.  The one post-sp2 hofix for backup issues KB981640, is already installed.
 
Symptoms: the local smsbkup.log file finishes with the statement that the backup was successful.  However, within the log are individual file failures like:
 
Error: Failed to backup \\?\GLOBALRoot\Device\HarddiskVolumeShadowCopy144\SMS_ABC\SMS_ABC_05.nsf up to \\Q:\CMBackup\ABC\ABCBackup\SiteDBServer: \\?GLOBALRoot\Device\HarddiskVolumeShadowCopy144\SMS_ABC\SMS_ABC_05.nsf is not readable.

Troubleshooting:  because what was referenced in the error was "Volume Shadow Copy", I presumed it was something related to the VSS service.  Although the fix may be less than what I did to resolve this issue, this is what worked for me:

Resolution:

  1. In your smsbkup.log file, take note of all of the lines like "Added volume containing D:\ to the snapshot set"
    Because this was our central, we have the db files over a bunch of drive letters, for speed, etc. reasons.  So I have D, O, R, S, X
  2. On the primary site, cmd prompt, vssadmin list shadowstorage, and take note of the entries for D:\ (and anyone else) for me, it was things like   d:\ on D:\ 977mb, O: on O:, 977mb
  3. Do some investigation, on each of the drives, take note of the size of the .mdf or .ndf files on them.  for me, O:, R, and S were 50+gb, X was 20+gb.
  4. More investigation, pick a drive letter with at least that much free space, for each of the drives, but NOT itself.  For me, I decided everyone but R: would use R:, and R: would use D:  Also, do NOT use the drive letter that will be the location for the actual sms backup task (for me, that's P:)
  5. delete the existing entries, for example:
         vssadmin delete shadowstorage /For=D: /On=D:
         vssadmin delete shadowstorage /For=O: /On=O:
  6. Create new ones with  
         vssadmin add shadowstorage /for=D: /On=R: /MaxSize=60GB
         vssadmin add shadowstorage /for=O: /On=R: /MaxSize=60GB
         vssadmin add shadowstorage /For=R: /On=D: /MaxSize=60GB
         vssadmin add shadowstorage /for=s: /On=R: /MaxSize=60GB
         vssadmin add shadowstorage /for=X: /On=R: /MaxSize=30GB

A few caveats: I'm not sure if I needed 30gb or 60gb for the /MaxSize.  I did try simply using /for=D /On=R using the original size (977mb, or 1gb), but just moving the drive letters to not itself didn't seem to do the trick for me.  So perhaps I went a little overkill on the /maxsize.  All I can say is since I've done the above, the harddiskshadowcopy not readable errors have ceased.

Posted by skissinger | with no comments
Filed under:
More Posts Next page »