Steve Rachui's Manageability blog - ConfigMgr/OpsMgr

Using System Center Update Publisher with Verisign Certificates - Updated

I previously posted a blog entry detailing how to configure System Center Update Publisher to work with a Verisign provided certificate.  After additional work in this area it was clear this post needed to be expanded.  I have updated it to include far more detail.  Hope it helps.

http://blogs.msdn.com/steverac/archive/2009/03/31/using-third-party-certificate-with-scup.aspx

Unable to import WIM into SCCM console

Ran across an interesting issue today.  When trying to import an OSD WIM image into the ConfigMgr console we received an error that ‘the specified path does not contain a valid WIM file’.  Generally, this error can be linked to a corrupt install of the WAIK or spaces in the UNC path.  Thats what we thought so we uninstalled the WAIK only to find that we couldn’t reinstall it.  When trying to reinstall we received an error stating “The installer encountered an unexpected error installing the package.  This may indicated a problem with the package.  The error code is 2908”.  We tested further and found this error to be generated with most any MSI we would try to install.  Only the most basic MSI installed without issue. 

Ultimately, we traced the issue down to the fact that the core registry keys Windows Installer writes to/adjusts when performing an install were locked. When we attempted to access the components key for the SID representing the local system, we received an access denied.  In fact, before we cleared the permissions problem on the components key (which we did by taking ownership of it again), we couldn’t see any of the subkeys.  Even after resolving permissions on the components key itself, the child keys remained locked and nothing we did in regedit resolved the problem.

Finally, we used the SUBINACLS utility to reset permissions and access was restored.  The command line we used is below.

SUBINACLS.exe /subkeyreg HKEY_LOCAL_MACHINE\Software\Microsoft /grant=administrators=F

With the registry access restored, we were able to install the WAIK and were able then to import WIM’s without problem.

Monitoring for Heartbeat Failures on non-Server Agents

Monitoring for agent heartbeat failures is a built in function in OpsMgr.  Heartbeats ensure that agents running in the environment are available and that the agent is able to interact with it’s management server.  All agents, regardless of whether on a server or workstation class system, participate in sending heartbeats.  An agent that is not sending heartbeats is noted in the OpsMgr console in a ‘grey’ state.

For server systems, an alert is generated in conjunction with the grey state to indicate the heartbeat failure.

An agent heartbeat failure is detected by the ‘Health Service Heartbeat Failure’ monitor.  Note that this monitor is an aggregate rollup.

If we look at this monitor, specifically the override summary, we note something interesting – there is an override in place by default that will prevent any agents on Workstations from generating the failed heartbeat alert. 

The failed heartbeat is still noted by the grey state, but no alert is generated.  Why would this be the case?  In general, workstation systems are expected to be more in a state of change – meaning reboots, shut down for periods of time, etc. – than are server class systems.  it is still important to know when the workstation is not heartbeating (grey state) but it would be annoying to continually receive heartbeat failure alerts. 

OK – that makes sense.  But, what if there are a few workstation class systems that will be treated as server systems – meaning that they are expected to be available routinely.  Is there a way to enable the standard heartbeat failure alerts for those systems?  Yes.  To understand this, let’s first revisit the override that disables alerts on these systems.  Note the name of the override corresponds to a built-in group.  If we look in the groups node and filter by the name shown in the override, we find our group of interest.

If we look at the membership of this group we notice that my test XP system is included by default.

The most important thing here – note the icon circled above.  The object contained in this group is NOT a standard computer object.  Heartbeat failure detection is the job of a special class of objects called ‘health service watcher’ objects.  Thats what the object in the group is – noted by the glasses. 

So, we see our workstation system in this group so we know that because of this group and because of the override, we won’t get alerts when this workstation system fails to heartbeat.  So how can we change this?  Simple, create your own group containing workstation objects that you DO expect to be available routinely and where you DO want to receive heartbeat failure alerts if there is a problem.  In my test environment, I created a group with explicit membership containing my workstation object.  My group is called ‘test XP Heartbeat Group’, as you will see in a bit.  For now, the screenshots look very much the same

The key here is to make sure the group you are creating contains ‘health service watcher’ objects rather than windows computer objects – if you end up with windows computer objects, the group will be meaningless for use with the heartbeat monitor.

Now that we have our group created that we want to use to specify which workstation class systems should behave like servers in terms of heartbeat failure detection, we need to use that group to introduce another override to turn on alerting.

So, what we have now is the default override to disable alerting for all workstation class systems and then another override to turn it back on for my select group of workstation systems.  In my test lab, both groups contain the same test system.  In production, the default group will likely contain more systems than the custom group you create to enable alerting. 

With all of this in place, I stop the ‘System Center Management’ service (formerly knows as the OpsMgr Health Service in RTM and SP1) and wait for my agent to go into a grey state.  Now when I inspect the alerts pane, I see a heartbeat failure alert – just as I expect.

Standard operators and subscriptions

Do you like the idea of spending several hours creating all of the notification subscriptions your opsmgr operators will ever need?  If that sounds fun to you – enjoy.  For the rest of us, opsmgr allows a standard operator the ability to create their own subscriptions for alerts of interest and, with R2’s new subscription links directly off of the actions menu when viewing alerts, the process is even easier. 

Before unleashing your operators to build subscriptions at will, make sure you spend a bit of time showing them how.  When a standard operator launches the opsmgr console and selects an alert view the subscriptions actions may be greyed out as shown. 

This is completely normal and indicates that no subscriber data has been provided for the operator.  You can either create the subscriber before the operator is allowed to work in the opsmgr console or you can show the operator how to do it themselves.  All that is required is to have the operator complete the ‘My Subscriber Information’ wizard from the tools menu

Once done, the subscriber will see the links to create subscriptions is now available.

Yes, a bit simple – but it came up recently so thought I’d pass it along.

SCCM features NOT supported through IBCM

I was looking for this information recently and had a hard time locating it – probably my poor searching skills!  Nevertheless, I found it again so am posting it on my blog so I can always have it close!  The information comes from http://technet.microsoft.com/en-us/library/bb693755.aspx

The following features are not supported when clients are managed on the Internet:

• Software distribution that is targeted to users (either directly or through Microsoft Windows security groups).
• Branch distribution points (a branch distribution point cannot support Internet clients, and clients on the Internet cannot be configured as a branch distribution point).
• Client deployment over the Internet.
• Auto-site assignment.
• Network Access Protection (NAP).
• Wake On LAN.
• Operating system deployment.
• Remote control.
• Out of band management in Configuration Manager 2007 SP1.
• The client ping functionality used with the client status reporting feature in Configuration Manager 2007 R2.

Is your RMS updating configuration too frequently?

The RMS is responsible for maintaining a master list of agent configurations for the management group.  As new information arrives from discoveries that are running on agents, that configuration becomes stale and needs to be updated.  You can see this happening in the OpsMgr event log on the RMS – just look for an event 21025 or 21025 as shown below.

Event Type:    Information
Event Source:    OpsMgr Connector
Event Category:    None
Event ID:    21024
Date:        6/5/2009
Time:        3:03:25 PM
User:        N/A
Computer:    STEVERACRMS
Description:
OpsMgr's configuration may be out-of-date for management group primarymg, and has requested updated configuration from the Configuration Service. The current(out-of-date) state cookie is "59 F7 28 D9 AB A3 21 0D 9B 0C FB 83 EC 87 33 28 08 C0 32 48 "

Event Type:    Information
Event Source:    OpsMgr Connector
Event Category:    None
Event ID:    21025
Date:        6/5/2009
Time:        3:03:29 PM
User:        N/A
Computer:    STEVERACRMS
Description:
OpsMgr has received new configuration for management group primarymg from the Configuration Service.  The new state cookie is "4D BD 9A A0 E6 11 26 C7 ED 0D 03 5F 55 BA FB 82 68 CC 7C 8F "

Updating configuration is a normal function for the RMS and the frequency will flex based on the size of the management group (number of agents/number of management packs) and amount of change within the management group.  During new agent deployment, for instance, you would expect the frequency of RMS configuration updates to be more frequent due to all of the discoveries firing on these new agents.  The same holds when agents are removed.  In general, however, you wouldn’t expect the frequency of RMS configuration updates to remain high for sustained periods of time.

Recently I’ve reviewed the OpsMgr event logs from the RMS of a couple of different management groups and have noticed that the frequency of RMS configuration updates was happening every couple of minutes with the largest gap between updates at about 5 minutes – and this frequency was sustained.  Is this update frequency a concern?  If sustained, yes.  Here are a few reasons why

1.  Configuration data is held in memory on the RMS – this is done for efficiency and to reduce impact on the disk.  When the configuration is updated the RMS has to adjust data in memory and also make adjustments to the disk based configuration file.  This isn’t a big deal under normal circumstances but with frequent RMS configuration updates there can be an impact.
2.  With frequent churn the RMS may not be able to obtain a consistent database state and processing may be delayed as a result.
3.  Configuration churn will cause disk utilization to increase that would normally be allocated for other processing.  In one management group – which was running borderline but still within supported range for RMS hardware - this caused intermittent but very noticeable console hangs that would persist for 5-6 minutes at a time. 
4.  Fully decked out hardware may mask the problem but you will still see degraded OpsMgr function (even if not noticeable) as a result.

Here is a snip from an OpsMgr event log from an RMS being updated very frequently

OK, so now we understand this isn’t a good thing – so what do we do about it?  The first thing is to look and see if your RMS is updating configuration frequently.  Not all environments will experience this.  It really depends on the number of agents, the number of management packs, what your environment looks like operationally, etc.  If your RMS is having frequent configuration updates we need to understand what discovery is causing this churn.  There are a series of SQL queries that will assist with this.  Some are taken from a blog here.

I like to run these queries in the order listed below.  Some of these queries run against the data warehouse – noted by DW – and others run against the operational database – noted by OpsDB

Top discovery rule in the last 24 hours (DW) – This query will return the top discovery rules from the last 24 hour period along with the number of changes detected per rule. 

select ManagedEntityTypeSystemName, DiscoverySystemName, count(*) As 'Changes'
from
(select distinct
MP.ManagementPackSystemName,
MET.ManagedEntityTypeSystemName,
PropertySystemName,
D.DiscoverySystemName, D.DiscoveryDefaultName,
MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName', MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName',
ME.Path, ME.Name,
C.OldValue, C.NewValue, C.ChangeDateTime
from dbo.vManagedEntityPropertyChange C
inner join dbo.vManagedEntity ME on ME.ManagedEntityRowId=C.ManagedEntityRowId
inner join dbo.vManagedEntityTypeProperty METP on METP.PropertyGuid=C.PropertyGuid
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId
AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ChangeDateTime > dateadd(hh,-24,getutcdate())
) As #T
group by ManagedEntityTypeSystemName, DiscoverySystemName
order by count(*) DESC

and some sample results from running this query

Looking at the results you can see right away that the IIS MP discovery is submitting a significant number of changes within a 24 hour period.  This is quickly followed by the Dell MP.  This query was run on a management group with roughly 500 agents.  Doing the math, that means that each of our agents submitted updated NNTP discovery data over 5 times in a 24 hour period. 

When the OpsMgr agent executes a discovery it will only return data to the management servers if something was found to have changed.  So, in theory, you should be able to run a discovery every 15 minutes and see no configuration churn provided that the discovery is written according to best practices (meaning no frequently changing values are being discovered).  Please don’t take that as a recommendation – there really shouldn’t be a need to run discovery more than every 12-24 hours – and there is little benefit from a more frequent schedule.

Other queries that can help pinpoint what is happening with our discoveries.  I’ll just list these out without discussion

Discovered objects in the last 24 hours (DW) – This query works with the query above and will list out all of the objects that have been discovered in the last 24 hour period

select distinct
MP.ManagementPackSystemName,
MET.ManagedEntityTypeSystemName,
D.DiscoverySystemName,
D.DiscoveryDefaultName,
MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName',
MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName',
ME.Path, ME.Name,
ME.DWCreatedDateTime
from dbo.vManagedEntity ME
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId
AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ME.DWCreatedDateTime > dateadd(hh,-24,getutcdate())

Modified properties in the last 24 hours (DW) – This query will list out the specific properties that changed from one discovery run to the next.  Sometimes a property will be chosen for a discovery that will be noisy in most environements – like the temperature sensor discovery in the Dell MP.  These types of properties shouldn’t be included in a discovery but some still persist.  This query will track down such properties.

select distinct
MP.ManagementPackSystemName,
MET.ManagedEntityTypeSystemName,
PropertySystemName,
D.DiscoverySystemName, D.DiscoveryDefaultName,
MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName', MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName',
ME.Path, ME.Name,
C.OldValue, C.NewValue, C.ChangeDateTime
from dbo.vManagedEntityPropertyChange C
inner join dbo.vManagedEntity ME on ME.ManagedEntityRowId=C.ManagedEntityRowId
inner join dbo.vManagedEntityTypeProperty METP on METP.PropertyGuid=C.PropertyGuid
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId
AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ChangeDateTime > dateadd(hh,-24,getutcdate())

Entities with the most properties (DW) 
select distinct top 50 mep.ManagedEntityRowId, me.FullName, Count(mep.managedEntityPropertyRowId) as 'Total'
from ManagedEntityProperty mep WITH(NOLOCK)
LEFT JOIN ManagedEntity me WITH(NOLOCK) on mep.ManagedEntityRowId = me.ManagedEntityRowId
group by mep.ManagedEntityRowId,me.FullName order by Total desc

Instance changes in the last hour (OpsDB) – This query will list out the instances that have changed in the last hour.  Used with the previous queries this can help validate on an hourly basis what is being seen in the warehouse based queries.  Instances that show up consistently in the query results may indicate an overactive discovery.

select discovery.discoveryname, modified.*
from DiscoverySourceToTypedManagedEntity with(nolock)
inner join typedmanagedentity with(nolock)
on typedmanagedentity.typedmanagedentityid = DiscoverySourceToTypedManagedEntity.typedmanagedentityid
inner join discoverysource with(nolock)
on discoverysource.discoverysourceid = DiscoverySourceToTypedManagedEntity.discoverysourceid
inner join discovery with(nolock)
on discoverysource.discoveryruleid = discovery.discoveryid
inner join
(
Select fullname, basemanagedentityid, basemanagedentity.lastmodified
from basemanagedentity with(nolock)
Where basemanagedentity.lastmodified >= dateadd(minute, -60, getutcdate())
)as modified
on modified.basemanagedentityid = typedmanagedentity.basemanagedentityid

Relationship changes in the last hour (OpsDB) – This query is simlar to the one above but looks at relationships.

select discovery.discoveryname, relationship.*
from DiscoverySourceToRelationship with(nolock)
inner join Relationship with(nolock)
on Relationship.relationshipid = DiscoverySourceToRelationship.relationshipid
and Relationship.lastmodified >= dateadd(minute, -60, getutcdate())
inner join discoverysource with(nolock)
on discoverysource.discoverysourceid = DiscoverySourceToRelationship.discoverysourceid
inner join discovery with(nolock)
on discoverysource.discoveryruleid = discovery.discoveryid

OK, so we have reviewed the query results and it seems we have some overactive discoveries in the environment.  What can be done about it?  Three options

1.  Disable the discovery – It is a best practice to review all management packs before deploying to production to tune out unneeded components – such as discovery.  If you don’t need a discovery, disable it.  In some cases, this is easy to do by override.  In other cases a particular discovery may be part of a ‘super discovery’ – meaning a single discovery that creates and populates multiple classes.  Unless an override is exposed for the specific discovery of interest, you won’t be able to individually impact it’s frequency.
2.  Tune it – If disabling isn’t an option then we can tune the discovery to execute less frequently.  While this won’t ‘fix’ the problem it is a viable workaround to reduce the discovery noise.  There are potential impacts here so be sure you know what you are doing.  In addition, some discoveries are ‘nested’ and have dependencies between one another.  For more information take a look at my blog post here.
3.  Live with it – i don’t like this option but sometimes it’s the only one available.  If the churn was observed from the OpsMgr event log but not noticed from a performance perspective then your hardware likely is masking the issue or your issue isn’t severe enough to cause noticeable impact.  In such cases you might decide to leave things alone.  If this is your decision make certain that you keep an eye on this to ensure performance impacts or other problems aren’t seen as a result.

If you do notice a problem with a particular management pack in your environment, please don’t keep this to yourself.  If it is a Microsoft management pack, let us know so we can investigate any issues.  If it is a 3rd party management pack, please contact the vendor so the issue can be investigated.  Let me state again – just because one environment may see issues with a particular discovery doesn’t mean all environments will.  These issues may exist for one management group and not another.  It really does depend on the details of your management group.

Understanding ‘nested’ management pack discoveries and how they impact total discovery time?

Most management packs require discoveries be run to figure out which systems are hosting the objects we wish to monitor with the management pack.  Only after the discoveries find our target objects do processes kick in to deliver appropriate monitors/rules so that monitoring begins. 

In some cases, discoveries are ‘nested’.  What does ‘nested’ mean?  Put simply, discoveries that are ‘nested’ are in relation to one another.  Generally a broader discovery runs that finds systems hosting the general class of object to be monitored.  Based on the results, more specific discoveries run to determine details about the object found by the first discovery run.  Before monitoring is fully in place, all of these ‘nested’ discoveries have to run and return data for a system hosting the monitoring object.  This approach may take longer to get through the entire discovery process – but the benefit is that rules/monitors are only delivered to systems that specifically have the components of interest.

Confusing?  Not really – an example will clear things up.  Let’s take a look at the IIS 2003 Management Pack as an example.  To understand the discoveries and how they related to one another the first thing we need to do is find the ‘root’ discovery.  There are a couple of approaches to this – using the OpsMgr UI, reading through the XML or using MP Viewer.

I don’t like using the OpsMgr UI for this for a couple of reasons.  First, some object discoveries are ‘hidden’ from the list requiring you to go searching for them.  Kevin has a good blog about doing this – click here.  Second, the UI will sometimes show the same discovery rule multiple times – once for each type being discovered as shown.

This can be a bit confusing.  Just remember, even though the rule is listed multiple times, these are all the same discovery rule. 

You can also review the management pack in raw XML but this requires advanced knowledge and isn’t a good option for many administrators.

That leaves us with MP Viewer (make sure you use the latest version – 1.7 as of this blog entry).  Opening a management pack in MP viewer will show us any discoveries in that management pack – one line per discovery! 

The first thing we need to do is find out which of our discoveries is the ‘root’ discovery.  As mentioned ‘root’ discoveries will have the broadest target.  For the IIS 2003 Management Pack, there are 18 discoveries.  From the list we find only one that targets the Windows Server class – since this is the broadest class targeted, this is our ‘root’ discovery.

Notice the list of discovery targets though – most discoveries in the list target the ‘IIS 2003 Web Server’ class.  So the question at this point is – which discovery creates and populates the ‘IIS 2003 Web Server’ class.  Glad you asked, lets keep going. 

Now that we have the ‘root’ discovery identified the next question is – what class does this ‘root’ discovery create and populate?  Looking at the XML tab for this discovery we can easily see that this discovery creates the InternetInformationServices.2003.ServerRole class.

Very quickly we know that our ‘root’ discovery doesn’t create our ‘IIS 2003 Web Server’ class – but it does create the IIS 2003 Server Role class.  So far in the discovery ‘cascade’ this is the only class created.  So is there a discovery that targets the IIS Server Role class?  There are three.

The License Discovery rule doesn’t sound of interest to us at this point, the IIS All Components rule is disabled by default, so that’s not it.  that leaves us with the IIS Base Class Discovery.  What does the discovery for this class do and what classes are created and populated as a result?  Taking a look at the XML shows us that this one discovery results in several classes being populated – IIS FTP, IIS NNTP, IIS SMTP Virtual Server and several others – along with them is our class of interest – IIS 2003 Web Server (shown in Red)

- <Discovery ID="Microsoft.Windows.InternetInformationServices.2003.DiscoverBase" Enabled="onEssentialMonitoring" Target="Microsoft.Windows.InternetInformationServices.2003.ServerRole" ConfirmDelivery="false" Remotable="true" Priority="Normal">
  <Category>Discovery</Category>
- <DiscoveryTypes>
- <DiscoveryClass TypeID="Microsoft.Windows.InternetInformationServices.2003.ServerRole">
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.ServerRole" PropertyID="MinorVersion" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.ServerRole" PropertyID="MajorVersion" />
  </DiscoveryClass>
  <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPServer" />
- <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite">
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="SiteID" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="Description" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="ServerBindings" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="SecureBindings" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="AllowAnonymous" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="AnonymousOnly" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="AnonymousUsername" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="LogFileDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="Path" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="ConnectionTimeout" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="MaxConnections" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="LogType" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="URL" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="LogFileType" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="LogFilePattern" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="LoggingEnabled" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.FTPSite" PropertyID="PerfCounterInstance" />
  </DiscoveryClass>
  <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.WebServer" />
  <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPServer" />
- <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer">
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="SiteID" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="Description" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="ServerBindings" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="SecureBindings" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="DefaultDomain" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="BadMailDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="PickupDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="QueueDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="LogFileDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="EnableReverseDNSLookup" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="ConnectionTimeout" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="MaxConnections" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="MaxMessageSize" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="NTAuthenticationProviders" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="RemoteSMTPPort" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="RemoteSMTPSecurePort" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="RemoteTimeout" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="LogFileType" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="LogFilePattern" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="LoggingEnabled" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.SMTPVirtualServer" PropertyID="PerfCounterInstance" />
  </DiscoveryClass>
  <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPServer" />
- <DiscoveryClass TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer">
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="SiteID" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="Description" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="ServerBindings" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="SecureBindings" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="Path" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="NewsDropDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="NewsFailedPickupDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="NewsPickupDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="LogFileDirectory" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="AllowAnonymous" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="ArticleTable" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="MaxMessageSize" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="NTAuthenticationProviders" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="ClientPostHardLimit" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="ClientPostSoftLimit" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="FeedPostHardLimit" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="FeedPostSoftLimit" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="LogFileType" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="LogFilePattern" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="LoggingEnabled" />
  <Property TypeID="IISCommon!Microsoft.Windows.InternetInformationServices.NNTPVirtualServer" PropertyID="PerfCounterInstance" />
  </DiscoveryClass>
  </DiscoveryTypes>
- <DataSource ID="DS" TypeID="Microsoft.Windows.Server.IIS.IISDiscoveryDataSource.2003">
  <PeriodInSeconds>3600</PeriodInSeconds>
  <DiscoverySourceType>0</DiscoverySourceType>
  <DiscoverySourceObjectId>$MPElement$</DiscoverySourceObjectId>
  <DiscoverySourceManagedEntityId>$Target/Id$</DiscoverySourceManagedEntityId>
  <ComputerPrincipalName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</ComputerPrincipalName>
  <DiscoveryType>1</DiscoveryType>
  <LowerDiscoveryPercentage>0</LowerDiscoveryPercentage>
  <UpperDiscoveryPercentage>100</UpperDiscoveryPercentage>
  </DataSource>
  </Discovery>

Notice also that the properties that are discovered for each class are shown here as well.

So now we have drilled through the discoveries.  From our review we have learned:
    1.   ‘Root’ discovery – IIS Role Discovery Rule – creates and populates 
          IIS 2003 Server Role class
     2.  IIS 2003 Server Role class – creates and populates several classes,
          including IIS 2003 Web Server Role
     3.  12 discoveries run against the members of the IIS 2003 Web     
          Server Role class.

A logical question out of this – we saw that a number of classes were created and populated in step 2 above – but we don’t see any discoveries targeted against those classes.  Remember, not all classes that are discovered have a discovery targeted to them.  Some classes are created for the purpose of targeting rules and monitors.  Some classes are created for the purpose of targeting further discoveries.  Some classes are created for both purposes.

OK, so now we understand how the discoveries relate to each other.  But now we need to understand how long it will take for each of these discoveries to create and populate their classes and get the job of monitoring IIS started for the environment.  The answer here is easy.  In MP Viewer we notice that beside each discovery we show the frequency at which the discovery runs – 3600 minutes for each discovery show – or every hour. 

Knowing the timings we can figure out how long, at longest, it will take for all objects to become discovered in the environment.  When the MP is first imported, the ‘root’ discovery runs right away.  After it runs, the resulting class will be populated and the next level of discovery will be deployed.    So on we go until all discoveries are deployed. 

Going by the frequency for each discovery, the maximum time for all discoveries to run and for an object to be fully discovered/monitored would be 3 hours – this is true because there are three layers of discovery, each running on an hour interval.  You also need to factor in some time to accommodate for internal works of OpsMgr as classes are created, config changes are processed, new management packs are requested by agents, etc. 

A couple of more things to factor in here – when the MP is first imported the ‘root’ discovery runs right away.  Once imported, for any new agents that are added, the ‘root’ discovery will be on a schedule and likely will not run right away.  Bottom line?  The discovery cascade will run more quickly when the MP is first imported that for subsequent runs.  Further, the discoveries shown here are running every hour.  This is generally far too frequent for environments that have any size at all.  Depending on the environment I generally recommend moving discoveries to no more than every 12-24 hours.  There are a lot of factors that go into whether or not to modify a discovery and, as such, I don’t suggest modifying discovery schedules without a good reason.  So what are some good reasons?  Console sluggishness can be caused by too frequent discovery and too much churn in the discovery data.  Environments monitoring lots of a particular type of object (in this case IIS) may see problems due to the flood of data that comes in with the discoveries.  I discuss one example where it would be beneficial to modify discovery frequency in my recent blog post here  If you think you may be adversely affected by too frequent discoveries, it would be worth a call to PSS before carte blanche changing discovery frequency. 

One last thing as I wrap this up.  In some environments, certain SLA’s are in place to ensure monitoring begins within a certain time frame of agent install.  Because of this you might be a bit hesitant to modify discovery frequencies even if needed.  It’s worth noting a couple of things.
     1.  Monitoring will begin in some form after the first discovery in the  
          cascade completes – so the agent will be monitored fairly quickly. 
          Additional monitoring will be deployed as the discovery cascade
          continues to fill out.

     2.  If it is vital to ‘get through the discovery cascade’ quickly but you
         also find you need to adjust the discovery frequency for your
         environment, you can still make this work and meet SLA’s – getting
         through the ‘cascade’ can be expedited by simply restarting the
         health service on the target agent.  At each health service restart
         the agent will process through all assigned discoveries.  So, if
         needed, you can use this method of restarting the health service a
         few times and watching for appropriate events in the opsmgr
         event log to expedite the agents way through the discovery cascade.

Using a variable to query TOP N entries from SQL

I was recently building a SQL query for use in a report and was looking for a way to return the ''top N’ results from a table matching my query criteria.  No big deal, right?  We do this all the time with a simple statement similar to

Select TOP 10 <what you want to display> from <tablename>

Ah, but what if you want to use a variable to specify the value for TOP?  Give it a try and you will quickly find that this simple syntax doesn’t work.  So how do you make this work then?  A little trick I found that works great is to just wrap the query you want with the rowcount variable – similar to

declare @v int
set @v = 6
set rowcount @v
select * from alert
set rowcount 0

With this simple example you can see that rowcount CAN be set with a variable.  Using the rowcount option is functionally the same as TOP as it only returns the number of rows specified by rowcount.  Notice the last entry where rowcount is set to 0.  Zero in this case clears out row count effectively taking away the filter.  You will want to be SURE to clear the rowcount filter after your query or all subsequent queries will have the rowcount value applied

LocalizedText issues gone in R2?

Routine maintenance to keep the LocalizedText table trim has been a part of the OpsMgr administrators world for a while now.  We have had a standardized query to clean this table that is posted on many blogs around the community – Kevin has a good article on the required cleanup posted here.

I recently came across a problem where this cleanup script was not fully effective.  My customer had 18 million rows but we were only able to purge down to 9 million.  Turns out that the extra rows were due to specific event collection that happens with the SCCM and Exchange management packs – and perhaps others.  Through our work we came up with the  script at the bottom of this page that took care of the remaining rows and purged the localizedtext to roughly 500,000 rows – well within the manageable range.  If you find that your localizedtext just won’t clean up to under a million rows you might find this extra query useful.

In an SP1 environment, make sure you continue to run the initial localizedtext cleanup as mentioned in Kevins blog and follow it by the one below.  In an R2 environment, the localizedtext query Kevin references should no longer be required but the one below WILL continue to be required if you are affected by the issues that cause the row count to remain.

Many thanks to our product team for help guiding the creating of this query.

OpsMgr DB Grooming – How it works

A while back I wrote up a blog post on how grooming works for the OpsMgr DB and the warehouse http://blogs.msdn.com/steverac/archive/2007/12/13/scom-2007-operational-and-datawarehouse-grooming.aspx

Recently I put the detailed grooming steps for the OpsMgr DB into a graphical form that I share here.  Please note – even though there are specific tables shown here don’t consider this posting sanction to modify these tables.  Doing so is unsupported and the tables are included here as information only and to show the total snapshot of the grooming process.  Further, the diagram below shows the detail around grooming the OpsMgr DB for partition objects (event/perf) but leaves detail about grooming other data types, such as self-tuning threshold data, alerts, state changes, job status, etc.  Information about ACS grooming, discovery data grooming, data warehoulse grooming, etc., is also absent.  All that to say, grooming is a multi-step process and, while many of the moving parts are shown below, many are also not detailed.

Large table query, with rowcount

Kevin has a number of very helpful queries on his blog – posted here.  One of the most commonly used is the large table query.  The large table query returns the space consumed by the table in kb, the space consumed by the index in kb and the space consumed by the blob in kb.  One value I like to see as well is the row count for each table returned.  I modified Kevins query to add this value and am posting it here for those that might also like this information in the same return set.

SELECT so.name, si.rowcnt as row_count,
8 * Sum(CASE WHEN si.indid IN (0, 1) THEN si.reserved END) AS data_kb, Coalesce(8 * Sum(CASE WHEN si.indid NOT IN (0, 1, 255) THEN si.reserved END), 0) AS index_kb,
Coalesce(8 * Sum(CASE WHEN si.indid IN (255) THEN si.reserved END), 0) AS blob_kb
FROM dbo.sysobjects AS so JOIN dbo.sysindexes AS si ON (si.id = so.id)
WHERE 'U' = so.type GROUP BY so.name, si.rowcnt  ORDER BY data_kb DESC

OpsMgr R2 RTM!

It’s been a long time coming but OpsMgr R2 has finally released – with general availability shortly.  I spent some time today upgrading my lab environment and the process went smoothly.  As with any upgrade, be sure to review the documentation and make sure any errors being seen are corrected ahead of the upgrade.  You may have some console issues until you get all to the R2 version but there shouldn’t be any major issues.  Be sure to review the release notes for the list of known issues.  In general, this should be smooth but let me know of any problems you encounter.

Tool to verify AMT certificates

One of the challenges that some customers face when configuring AMT support in SCCM is certificates.  There are two types of certificates needed.

Provisioning certificate – This certificate is used to connect with AMT capable systems in preparation for provisioning.  AMT systems with firmware 2.2.x, 2.6.x and 3.2.1 or higher all support the use of the provisioning certificate.  Provisioning certificates are normally obtained from a provider such as Verisign, Comodo, GoDaddy or StarField.  The BIOS of AMT systems is preconfigured to support certificates from these providers so no additional work is needed.  You can also use a certificate generated by a Microsoft Certificate Authority but that requires additional work and is only supported by AMT 3.2.1 or higher.

AMT client certificate – This certificate is generated during the provisioning process, is specific to each AMT client and is used for ongoing management of the AMT client.  This certificate is generated by a Microsoft Certificate Authority and is an automated process.

Obtaining and setting up these certificates requires specific steps which I won’t go into here.  Once the certificates are configured, however, it is useful to have a way to verify they are configured correctly.  I wrote the attached tool to address this need.  CertValidator.vbs is a vbscript that will check both the provisioning certificate and perform a test request of the client certificate to ensure all is configured properly.

The CertValidator.vbs utility is designed to run on Windows 2003 and Windows 2008 servers and uses the following command lines:

     Provisioning certificate check:
     cscript CertValidator.vbs 1 <certificatefile> <certificatepasswod>

     Client certificate check:
     cscript CertValidator.vbs 2 <name of CA in format server\CA>

The following screenshots show the CertValidator.vbs utility being used to check a provisioning certificate provided by Versign:

If all command line variables are correct, testing proceeds.  The screenshot below shows sample output from certificate checking.  Note that not all checks pass but a failure does not necessarily indicate an invalid certificate.  Depending on the certificate provider, the structure of the certificate may cause some tests to fail yet, the certificate is valid due to the result of other checks.

Note:  During script testing I ran the provisioning certificate check mostly on the computer hosting the certificate authority itself and this is the system where I would recommend running the tool when checking for provisioning certificate health.

The following screenshots show the CertValidator.vbs being used to connect to and perform a test request of a client web certificate for AMT use:

If all of the command line options are correct then checking begins.  During this process the script will connect to the specified certificate authority, request a test web certificate, retrieve the certificate from the certificate authority and check the certificate for validity.

 
Note:  During script testing I ran the client certificate check mostly on the computer hosting the certificate authority itself and this is the system where I would recommend running the tool when checking for provisioning certificate health.

When the SCCM server requests a web certificate on behalf of an AMT client it does so in the context of the SCCM computer account.  The documentation for configuring security on the certificate authority discuss how to setup security on the AMT web template to allow for this to work.  For SCCM, template security should allow the SCCM site server computer account read, enroll and autoenroll permissions.  This is generally done by group.  If you are using groups, ensure the SCCM site server in question is a member of the group.  The is shown in the screenshot below

For this version of the CertValidator utility, the context of the user running the tool is used to interact with the certificate authority so a temporary change to security on the AMT web template is required.  To make the change, open your certificate authority console, right-click on certificate templates and select manage.  Locate your ConfigMgr AMT Web Server Certificate, right-click and select properties.  Add your user account or a group containing your user account to have Read, Write and Enroll permissions.  In my lab I’ve granted these permissions to the Authenticated Users group.

Error checking is built into the script but likely doesn’t catch everything.  There may be timing issues in some environments so if the script fails the first time, run it a few times to make sure you aren’t affected by timing problems.  Screenshots of other errors you may encounter are below

 

Please send in your feedback as I want to make sure this tool is usable for the community. 

Modifying SMS_DEF.MOF and Configuration.MOF to pull information from a 64-bit registry

Recently had the occasion to modify the SMS_DEF.MOF and Configuration.MOF files to pull information from a native 64-bit registry.  It’s a relatively simple process – there are even some classes, like addremove and virtual machines, that are default and give examples to do this.  Below are the relevant sections from each file for my project.

SMS_DEF.MOF
---------------
#pragma namespace ("\\\\.\\root\\cimv2\\sms")

[ SMS_Report(TRUE),
  SMS_Group_Name("Widget Build"),
  SMS_Class_ID("MICROSOFT|Widget_Build|1.0"),
  SMS_Context_1  ("__ProviderArchitecture=32|uint32"),
  SMS_Context_2  ("__RequiredArchitecture=true|boolean") ]

class Win32Reg_Widget_Build : SMS_Class_Template
{
    [SMS_Report (TRUE), key ]     
    string IndexKey;
    [SMS_Report (TRUE) ]          
    string Widget_Product;
    [SMS_Report (TRUE) ]          
    string Widget_Release_Date;
    [SMS_Report (TRUE) ]          
    string Widget_Type;
};

#pragma namespace ("\\\\.\\root\\cimv2\\sms")

[ SMS_Report(TRUE),
  SMS_Group_Name("Widget Build 64"),
  SMS_Class_ID("MICROSOFT|Widget_Build_64|1.0"),
  SMS_Context_1  ("__ProviderArchitecture=64|uint32"),
  SMS_Context_2  ("__RequiredArchitecture=true|boolean") ]

class Win32Reg_Widget_Build_64 : SMS_Class_Template
{
    [SMS_Report (TRUE), key ]     
    string IndexKey;
    [SMS_Report (TRUE) ]          
    string Widget_Product;
    [SMS_Report (TRUE) ]          
    string Widget_Release_Date;
    [SMS_Report (TRUE) ]          
    string Widget_Type;
};

Configuration.MOF
------------------
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("Win32Reg_Widget_Build", NOFAIL)
[DYNPROPS]
class Win32Reg_Widget_Build
{
    [Key]
    string IndexKey;
    string Widget_Product;
    string Widget_Release_Date;
    string Widget_Type;
};

[DYNPROPS]
instance of Win32Reg_Widget_Build
{
    IndexKey="Widget Build Data";

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Product"),      Dynamic, Provider("RegPropProv")] 
    Widget_Product;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Release_Date"),      Dynamic, Provider("RegPropProv")] 
    Widget_Release_Date;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Type"),      Dynamic, Provider("RegPropProv")] 
    Widget_Type;
};

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("Win32Reg_Widget_Build_64", NOFAIL)
[DYNPROPS]
class Win32Reg_Widget_Build_64
{
    [Key]
    string IndexKey;
    string Widget_Product;
    string Widget_Release_Date;
    string Widget_Type;
};

[DYNPROPS]
instance of Win32Reg_Widget_Build_64
{
    IndexKey="Widget Build Data 64";
    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Product"),       Dynamic, Provider("RegPropProv")] 
    Widget_Product;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Release_Date"),      Dynamic, Provider("RegPropProv")] 
    Widget_Release_Date;

    [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\ATT\\Windows\\Build|Widget_Type"),      Dynamic, Provider("RegPropProv")] 
    Widget_Type;
};

From the above you notice that to pull both 32-bit and 64-bit information we need a section in the control files for each platform.  Also notice the bolded text – this is the key to pulling data from 64-bit systems so make sure you include it.  Using the example above works in my lab but there have been reports of problems so be aware.  If you don’t want to worry about it just add your registry information under the wow6432node and use 32-bit MOF extensions to pull the data.  A very cool GUI based utility to auto-build these extensions on 32-bit systems is in referenced in my previous post.

Custom MOF additions in SCCM – Simplified

I was working recently on extending the SMS_DEF.MOF and Configuration.MOF files in SCCM to pull information out of the registry.  This isn’t too difficult of a task to do manually but while looking around I came across a really sweet GUI tool that allows you to expand the registry keys of interest and pull out the values you want with just a couple of points and click.  The relevant portions of the SMS_DEF.MOF and Configuration.MOF are created for you so it’s a simple copy and paste operation to include them. 

It doesn’t seem this tool works yet with 64-bit native registries but for 32-bit, it’s very cool. Take a look at http://myitforum.com/cs2/blogs/skissinger/archive/2009/04/13/mark-cochrane-s-regkeytomof.aspx