Consolidating Disk Partitions in a Windows XP to Windows 7 Migration

If your Windows XP systems have multiple disk partitions and you are migrating them to Windows 7, you may have a requirement to combine all partitions into one so Windows 7 ends up on a sufficiently large partition.  In a Refresh scenario, where the same Windows XP system will end up with Windows 7, this can be a challenging requirement if you must preserve the user data.

Fortunately, this Windows 7 deployment scenario is possible if you are using System Center Configuration Manager (SCCM) 2007.  In a nutshell, SCCM can automate the following steps during deployment:

  1. Save the user data
  2. Delete the extra partition(s)
  3. Extend the primary partition where Windows XP is installed
  4. Install Windows 7 on the extended partition
  5. Restore the user data

In an SCCM task sequence, the “Capture User State” step is used to save the user data.  If the partition being deleted contains user data, you must save the state data to the State Migration Point (instead of using the USMT 4 hardlink feature which leaves the data on the local drive).  When integrating MDT 2010 with SCCM 2007, hardlinks will be used by default but you can force to use the State Migration Point by disabling the Determine Local or Remote User State step.

Deleting the extra partition(s) can be accomplished by running diskpart commands in the task sequence.  For example, if you have to delete one extra partition on disk 0, the diskpart commands would be

SELECT DISK 0
SELECT PARTITION 2
DELETE PARTITION
EXIT

You can automate the diskpart commands by entering them in a text file (such as myScript.txt) that you would call with the /s parameter of the diskpart command.  This is an example:

Diskpart /s myScript.txt

Of course, before you use a script like this in a deployment, you would have to first test the diskpart commands manually on test systems that are configured like your production systems to ensure that you obtain the desired results.

You would then run the diskpart command, calling the script, from the task sequence.  You can use the Run Command Line step to run the command.  However, we must find a way to make the script file available to the task sequence.  One way is to include the file in an SCCM package and then include that package in the Run Command Line step, as illustrated below.

You can place the WME – Fix Partitions step in the Refresh Only group:

Then the Apply Operating System Image step should be configured to use a unattend.xml file that sets the ExtendOSPartition variable in the specialize phase to True.

This is the bottom section of the Apply Operating System Image step:

If Extending the Partition Fails

Extending a disk is sometimes not possible.   A couple reasons for this limitation are detailed in this Microsoft article about diskpart.  Depending on your specific disk configuration, it may be possible to use the Format and Partition Disk step after the diskpart step to repartition the disk using all the available unallocated space.  This would allow you to end up with one partition, where Windows 7 would be installed.  The step should run while in Windows PE in the Refresh Only group (which runs after saving the user state).  You would need to first test the deployment to a test machine to ensure that it works as expected in your environment.

These are the properties of the Format and Partition step:

And these are the settings of the OSDisk (Primary) volume:

These format and partition settings may differ depending on the disk configuration of your systems.

Using Microsoft Security Baselines with System Center Configuration Manager

Microsoft provides security baselines with hundreds of security configuration settings that you can use to compare against your systems to determine how secure your environment is or to monitor security compliance in your organization.  Comparing the settings of a security baseline against many computers and obtaining the result may prove to be a challenging task.  Thankfully, the Microsoft Security Compliance Manager (SCM) tool makes it easy to export these security baselines into a System Center Configuration Manager (SCCM) configuration pack, which can easily be imported into SCCM as a Desired Configuration Management (DCM) configuration baseline.

The Security Compliance Manager comes with many security baselines for the latest versions of Windows, Office and Internet Explorer.  For example, for Windows 7, the following baselines are provided.

Selecting a baseline and then clicking on Properties on the right pane displays an explanation of the security baseline.  These are the properties of the Win7-EC-Laptop baseline (EC stands for Enterprise Client).

When you select a baseline, the main middle pane shows a list of the settings contained in that baseline.  For example, these are the first six settings (out of 266) in the Win7-EC-Laptop baseline:

The Default column indicates what the default value is for a setting, the Microsoft column indicates the recommended configuration from Microsoft, and the Customized column indicates the customized configuration if you have modified the setting.

Note that Microsoft does not allow you to modify their settings.  For example, when you click on a setting, the controls are greyed-out:

What you can if you need to modify settings is to make a copy of a baseline.  You make a copy by selecting the baseline and then click on Duplicate on the right-pane.

The Duplicate wizard prompts you to enter a name for the new baseline (you can accept the default which is “Copy of XXX”, where XXX is the name of the baseline that you are duplicating.

The duplicated baseline will then appear under Custom Baselines:

The controls of a setting in the duplicated baseline are no longer greyed-out, allowing you to make changes to it:

You can use your SCCM infrastructure to compare the settings in a baseline against your SCCM client computers and obtain the comparison results.  To accomplish this, first export a baseline by selecting it and clicking on SCCM DCM 2007 under Export in the right pane.

This will save the baseline as a CAB file.  You can then import this CAB file into SCCM by right-clicking on the Configuration Baselines node and selecting Import Configuration Data as illustrated below.

In the Import Configuration Data wizard click on Add to select the CAB file.

The wizard will display the configuration data being imported.  This is a partial list:

When the Import wizard finishes, it will display the imported configuration data.  This is a partial list:

The imported configuration baseline will them be added to the SCCM Configuration Baselines node.

You are now ready to assign the baseline to the appropriate collection for evaluation.   For information on how to assign a baseline to a collection and view the results of the evaluation on target systems, see the following article from Windows Management Experts:

Authoring a DCM Configuration Item to Identify and Fix Non-compliant Systems

START PLANNING FOR SCCM 2012 NOW

If you are currently using System Center Configuration Manager (SCCM) 2007, you may already be thinking about the next version of the product being released in the next few months.  In this article we provide tips regarding what you can do now to start getting ready for SCCM 2012.

Branch Distribution Points are no longer supported in SCCM 2012.  Instead of using a Branch Distribution Point, use the Windows BranchCache feature supported by Windows 7 and Windows Server 2008 R2.  The BranchCache feature has been integrated with SCCM 2012 to give you more control on when it gets used.  SCCM 2012 allows you to configure BranchCache settings on the deployment type of an application and on the deployment settings for a package.

Deployment Type for an Application in SCCM 2012

Deployment Settings for a package in SCCM 2012

For information on using BranchCache with SCCM 2007 see the following article:

Configuring SCCM and BranchCache

You no longer need to deploy a secondary site for bandwidth throttling.  Microsoft is moving towards flattening SCCM hierarchies and added the bandwidth throttling feature to a distribution point.  The PXE server role is also now part of a distribution point.  Because secondary sites have to be uninstalled from your SCCM 2007 hierarchy and redeployed to your new SCCM 2012 hierarchy, you may want to consider holding the deployment of a secondary site now and deploy instead a distribution point.  Upgrading an SCCM 2007 distribution point to SCCM 2012 automatically is supported (not for branch distribution points) if that is the only role on the system and has sufficient free disk space.

You can’t automatically migrate collections from SCCM 2007 to SCCM 2012 if they contain both user and system resources.  This also applies to linked collections or subcollections that have resources of a different type.  If you do have collections with mixed type of resources, you may want to start separating them now so they can be migrated to SCCM 2012.

Start setting the source location for your packages to a UNC path instead of a local drive letter.  This is because when the metadata of a package is migrated to SCCM 2012, if the source location is a local drive letter, the drive letter for the source location of packages on the new SCCM 2012 server may be different than the drive letter on the SCCM 2007 server.

If you are using the Reporting Point role (Web-based role) in your SCCM 2007 hierarchy, be aware that this role is no longer present in SCCM 2012.  SCCM 2012 supports only the Reporting Services Point (which relies on SQL Server Reporting Services).  Migrating reports from SCCM 2007 to SCCM 2012 is not supported.  However, if you were using a Reporting Services Point now, you could export the reports to an RDL file and then import them into your new SCCM 2012 hierarchy.  Due to this, you may want to start using the Reporting Services Point now.

The minimum operating system requirement for the SCCM 2012 client is Windows XP SP2 (x64) and SP3 (x86).  If you have any clients using a lower operating system version, you may want to start upgrading them now.  Also, the .Net Framework 4.0 is required for the SCCM 2012 client and will be installed automatically when the client is deployed.  If you want to decrease network traffic during the deployment of the SCCM 2012 client, you may want to start installing the .Net Framework 4.0 on your clients now.

Desired Configuration Management in SCCM 2007

Desired Configuration Management (DCM) in System Center Configuration Manager (SCCM) 2007 gives you the capability to determine whether your managed systems are compliant or not with configuration settings that are important to your organization.  Examples of configuration settings are whether a group of systems have the correct version of an application installed, whether an application on a group of systems is configured according to your defined settings, and whether specific systems are compliant with software updates or your specified security settings.

You tell SCCM what you want to check on client systems to be evaluated for compliance by creating configuration items.  A configuration item is a unit of configuration to be assessed for compliance.  A configuration item can contain one or more elements together with the criteria for their evaluation, such as the value of a registry parameter, the existence of a file, or the value of a setting in WMI.  For example, the following configuration item contains two settings.

Configuration items are then added to configuration baselines.  A configuration baseline is what you assign to a collection for evaluation.  One of the configuration settings of a baseline is to choose configuration items to be added to it, as illustrated below.

The systems in the targeted collection evaluate the settings in the configuration items of the baseline and report compliance to SCCM.  SCCM has many built-in DCM reports that you can use to find the compliance status of your systems.

Creating a configuration item may be a time consuming task, depending on the complexity of it.  This process is called authoring configuration data.  Configuration data is a DCM Digest XML file or a Service Modeling Language file.  However, SCCM provides a user-friendly interface for you to create the configuration items and baselines.  If your organization is not able to allocate resources to develop configuration items, you might be able to find configuration packs with configuration baselines and configuration items that meet your business needs.  Some configuration packs are free from Microsoft, and others you can purchase from vendors.  You can browse available configuration packs from the link below.

Configuration Packs at the Microsoft System Center Marketplace

The main function of DCM in SCCM 2007 is to report compliance on settings that are important to you.  However, it is possible to remediate non-compliant systems by developing scripts that you would run on non-compliant systems using SCCM software distribution.  In SCCM 2012, Microsoft automates the remediation of some types of configuration settings.

Authoring a DCM Configuration Item to Identify and Fix Non-compliant Systems

Sometimes administrators have the need to find systems that have an undesirable file and delete it.  A system with this file is not considered to be compliant with the organization’s policies.  One way to tackle this problem is using Desired Configuration Management (DCM) in System Center Configuration Manager (SCCM) 2007.  This article provides information on how to author a DCM Configuration Item (CI) and Configuration Baseline to identify systems with the file and how to use SCCM software distribution to delete the file automatically.

Creating a Configuration Item

In this example the undesirable file is redFlag.txt in the root of drive c:.  The first step is to create a DCM configuration item to detect the file.  Right-click on Configuration Items, select New and click on General Configuration Item.

In the Identification page of the wizard, provide a descriptive name and click on Next.

In the Objects page of the wizard, click on New and then click on File or Folder as illustrated below.

The New File or Folder Properties will open.  Enter the information for the file in the General tab as illustrated below.

Click on the Validation tab and configure it with the following settings.  We are indicating to report non-compliance when the instance count of less than 1 fails (meaning there’s one or more of this file).

Click on OK to close the New File or Folder Properties window and then click on Next to continue with the Configuration Item wizard.

Click on Next on the Settings page.   Then, click on Next to accept the default settings in the Applicability page.  Click on Next and Close twice to finish the wizard.  Now our Configuration Item has been created.

Adding Configuration Item to a Baseline

To add our Configuration Item to a new Baseline, right-click on Configuration Baselines and select New Configuration Baseline.

Give a name to the baseline and click on Next.

In the Set Configuration Baseline Rules page, select “These applications and general configuration items are required and must be properly configured:” as illustrated below.

Select our Configuration Item and click on OK.

Click on Next twice to finish the New Configuration Baseline wizard.

Assigning the Baseline to a Collection

Now we need to assign our new baseline to a collection with systems that will evaluate it to report compliance on it.  Right-click on the baseline and select Assign to a Collection to assign it to the appropriate collection by selecting the baseline you want to assign and the target collection.

Systems in the collection will retrieve the assignment of the baseline and evaluate it the next time they pull policies from SCCM (every 60 minutes by default).  When the client in this example retrieved the policy, it evaluated it.  The Configurations tab of the Configuration Manager applet in control panel provides information about our baseline.  This client has the RedFlag.txt file in the root of drive C: so it isn’t compliant.

Run a report to obtain compliance information

You can run the “Summary compliance by configuration baseline’ report to find compliance information on all the systems in the targeted collection.  Select the Configuration Baseline Name that you want to get information on.

And then click on Display.

Fixing non-compliant systems

To fix the non-compliant systems (the ones that have the c:\redFlag.txt file), we’ll put together a simple batch file and deliver it to the non-compliant systems using SCCM software distribution.  Our batch file contains just one line:

del c:\redFlag.txt

You can now create an SCCM program and package containing the batch file.  You’ll advertise this program to non-complaint systems.

Now we need to create a collection with non-complaint systems.  You can use WQL query language to create a dynamic collection that will be composed of only non-compliant systems every time it evaluates (you indicate how frequently the collection should be evaluated).  If you have R3 for SCCM 2007 installed, you can create the collection automatically by right-clicking on the baseline, select “Create New Collection” and click on “Non-Compliant Systems”.

In the New Collection wizard, give the collection a name and indicate how often it should be evaluated (the default is every 1 day).

The collection was created with the following WQL statement, which is what you would have to create if R3 wasn’t installed on your SCCM 2007 site server.

Click Next and Finish to create the collection.  In this example, it got populated with the non-compliant system.

You can now advertise the SCCM program to fix the non-compliant systems (by deleting the c:\redFlag.txt file) to this collection.

In our example, after the non-complaint system ran the advertised SCCM program and then evaluated the baselines on the next scheduled evaluation, our baseline was reported as “Compliant” in the Configurations tab of the Configuration Manager applet in control panel.

Then the next time our collection evaluated, it no longer had our system in it.

The DCM report now shows 1 compliant system instead of 1 non-compliant

INSTALLING SOFTWARE UPDATES DURING SCCM OSD

When deploying Windows 7, it is important to have the operating system fully patched as soon as it is deployed.  A newly deployed Windows 7 system missing security updates represents a security vulnerability and a risk to the corporate network.  Deploying Windows 7 with System Center Configuration Manager (SCCM) allows you to easily install the latest security updates during operating system deployment  (OSD) without having to update the master image every time software updates are released.

To be able to deploy software updates during the deployment of Windows 7 using SCCM, the Microsoft Deployment Toolkit  (MDT) 2010 Update 1 must be integrated with SCCM.  To integrate it, install MDT 2010 on your existing SCCM site server.  Then click on Configure ConfigMgr Integration in the Microsoft Deployment Toolkit program group.

This integration will add MDT task sequences to SCCM.  When you right-click on Task Sequences in the SCCM console, there’ll be a new option to access the MDT task sequences.

To install software updates while Windows 7 is being deployed using SCCM, the Install Updates Offline task should be used in the task sequence used to deploy the OS.  This task will install all the software updates included in a specific SCCM deployment package after the image has been applied to the disk.  This task should be placed in the PostInstall group just before the Configure task.   To insert the task, select the task just above the Configure task, and then click on Add in the pull-down menu bar on the top, hi-lite MDT and click on Install Updates Offline as illustrated below.

Configure the task by browsing to select the Updates package that contains the security updates that you want to install.

You can add as many Install Updates Offline tasks as needed as only one package can be included per task.

User-based Software Delivery in SCCM 2012

System Center Configuration Manager (SCCM) 2012 enhances software deployment over SCCM 2007 by allowing SCCM administrators to delegate control to end users on what software gets installed on their systems or devices and when it gets installed.  Microsoft has taken into account a trend in which end-users are using devices such as cell phones in addition of desktops and notebooks.  Also, users now tend to be more technology-savvy and have expectations to be able to use the software that they need to do their jobs on any device and at any time.

SCCM 2012 introduces the concept of an Application.  Think of an application as a high-level definition of software that has intelligence to determine if the user has been authorized to use it on a particular device, how it should be made available to the user on that specific device, and if that device has the capability of running the application for the user.

Applications are made up of the following:

  • Deployment Type(s) – installer technology or way in which the software is delivered to the user
  • Requirement Rules – Properties per deployment type of users and/or devices that make delivering software appropriate and evaluated by the SCCM client in real time
  • Dependencies – other deployment types that must be present before delivery of application
  • Detection Method – Enable systems to determine if an application is already present
  • Install Command – What command to run
  • Content – Files that comprise the application

To deliver the software to the user, the SCCM administrator creates a deployment.   A deployment is what an Advertisement is in SCCM 2007.  The deployment captures the administrator’s intent by having two deployment purposes: Required and AvailableRequired compares to a mandatory assignment of an advertisement in SCCM 2007; Available compares to an optional advertisement.  The deployment also has two types of actions: Install and Uninstall.

Note: In SCCM 2012 you can still use the Packages and Programs present in SCCM 2007 but you won’t have access to the intelligence built into Applications.

For applications that are not forced on the user devices –those with a deployment purpose of Available, SCCM 2012 offers a user-friendly web portal called Application Catalog, where the user can browse and install applications that are available to her (optionally the application may require approval from an administrator first).  If the Available deployment purpose targets a device instead of a user, then the application can be installed from Software Center, which is a local application on the client that replaces “Run Advertised Programs” present in the SCCM 2007 client.

One of the key features that Microsoft provides to make User Centric Software Distribution possible is User Device Affinity (UAC).  UAC provides the ability to identify a relationship between a user and a device.  This allows complex software deployment scenarios such as where an application should be installed only on a user’s primary device but still make the application available to the user on other devices via other deployment types.

An example of a complex software deployment –but simple to configure for the SCCM administrator, is when the user is using her primary device and wants to use Word 2010.  If not installed, the user can go to the Application Catalog and install it locally on the primary device (i.e. a desktop in the corporate network).  The following week the user logs-in to someone else’s desktop in the corporate network and needs to use Word 2010 but it isn’t installed.  The user then goes to Application Catalog and selects to install the software.  However, because of the intelligence built into the Application by the SCCM administrator, Word 2010 is delivered to the user via App-V.  The user then uses her Windows Phone and wants to use Word.  The user goes to the Application Catalog to install it, and Word Mobile is delivered to her phone using the Windows Mobile Cabinet deployment type.

User Device Affinity supports the following relationships in SCCM 2012

  • Single primary user to primary device
  • Multiple primary devices per user
  • Multiple primary users per device

Note: SCCM 2012 allows these relationships to be defined by the SCCM administrator and by the end user.

In conclusion, SCCM 2012 has made it easy for the SCCM administrator to empower users to use the software they need to perform their job at any time and on any supported device.

Operating System Deployment Logs in SCCM 2007 Integrated with MDT 2010

Many times when deploying an operating system using SCCM, the task sequence fails on the client.  Most of the time, the error presented on the screen does not provide sufficient information to determine what’s failing.  This is when you need to look at the logs created by the deployment.

If you have enabled command support on your boot image, you can press F8 if the task sequence failed while in Windows PE to gain access to a command prompt.  You enable command support in the Windows PE tab of the boot image properties.



Once at the command prompt, you can look for log files.  Their location may be tricky as they move around as the deployment progresses.  For example, the smsts.log file is

  • At x:\windows\temp\smstslog in Windows PE before the hard disk is formatted (x: is a RAM drive)
  • At x:\smstslog after the disk is formatted
  • At c:\_SMSTaskSequence\Logs\SMStslog after the disk is formatted

Another important log to analyze is the bdd.log.  This log contains a summarized view of all other MDT log files.  If it is difficult in your particular scenario to have access to the target machine to press F8 and gain access to a command prompt while in Windows PE, the machine will restart and the logs will be gone.  Although it is possible to configure your deployment so the log files are copied to a network share when the task sequence completes, sometimes a failure may prevent the task sequence from reaching the step at the end with instructions to copy the files.  The following entry in your CustomSettings.ini file will copy the logs to the specified share.

SLShare=\\<serverName>\<shareName>\%OSDComputerName%

In this case, the logs will be copied to a folder in the share named after the target computer name.

When working a difficult issue with your deployment, it may be necessary to enable real time logging over the network.  If you add the instruction below to your CustomSettings.ini file, real time logging is performed on the bdd.log file on the specified share location, in addition of logging on the target computer locally.  If you open the file with the Configuration Manager Toolkit utility trace32.exe, you can view the entries being added to the log.

SLShareDynamicLogging=\\<serverName>\<shareName>\%OSDComputerName%

Once you have fixed your challenging issue, disable this dynamic logging over the network.  There’s a substantial amount of network traffic generated as every line logged requires the file to be open, the line to be written to it, and the file to be closed.

SCCM USMT Migration Fails in a Refresh Scenario Involving Windows 7 SP1

System Center Configuration Manager (SCCM) 2007 generates certificates for the SCCM clients to communicate securely with SCCM site servers.  One of the properties of a certificate is the Friendly Name.  The SCCM certificates have contained a NULL character in the Friendly Name, and this hasn’t been a problem in the past.  This changed, however, with the release of security update 974571 from Microsoft:

MS09-056: Vulnerabilities in CryptoAPI could allow spoofing

For security reasons, this security update prevents importing certificates that contain a NULL character in the Friendly Name property.

As part of SCCM Operating System Deployments that use USMT (User State Migration Tool) to migrate state data in refresh or replace scenarios, the SCCM client certificates have to be migrated from the source operating system (OS) to the target OS.  If the source or target OS has security update 974571 installed, then the USMT migration will fail.

Service Pack 1 (SP1) for Windows 7 includes security update 974571.  Due to this, when the source or target OS is Windows 7 with SP1, the USMT migration will fail during USMT operations.  USMT will also fail during capture of state data on the source OS if the source OS is Windows XP or Windows Vista with security update 974571.

To avoid this problem, Microsoft has provided hotfix 977203:

User state migration is unsuccessful on an ConfigMgr 2007 SP1 or SP 2 client after you install security update 974571 or Windows 7 SP1

Hotfix 977203 needs to be installed on all SCCM site servers and on all SCCM clients so they stop generating certificates with a NULL character in the Friendly Name property.  The hotfix also includes a tool, ccmcertfix.exe, that will remove the NULL character in the Friendly Name from the SCCM certificates on systems that already have them.

When you install the hotfix on a site server, the ccmcertfix.exe tool is extracted to the following directory:

ConfigMgr_2007_Installation_Directory\Logs\KB977203

However, if the hotfix can’t be installed on a site server or SCCM client because it is not applicable, then you would have to manually extract the hotfix files to obtain the ccmcertfix.exe tool.  One reason for hotfix 977203 not to be applicable is that hotfix 977384 is installed on the site server.  Hotfix 977384 supersedes hotrfix 977203.  Hotfix 977384 includes hotfix 977203.  This is the error that you may get if the hotfix isn’t applicable.

Even if hotfix 977203 isn’t applicable (because hotfix 977203 or 977384 is already installed), the current certificates on SCCM clients still need to be fixed using the ccmcertfix.exe tool.

Extracting the hotfix files

The hotfix .exe file that you download from Microsoft is really a compressed file.  When you execute it, it extracts the actual .exe hotfix file.  You extract the files from this hotfix file by executing it with the /x parameter as in the following example.

SCCM2007-SP1-KB977203-X64-ENU.exe /x

You then specify where you want to extract the file.

This is a partial list if the extracted files.

The article for hotfix 977203 provides details on how to install the hotfix via SCCM software distribution or via a Task Sequence.  It also explains how to run the ccmcertfix.exe tool during refresh and replace OSD scenarios by using your deployment task sequences.

Example of Hardware Inventory Customization in SCCM

System Center Configuration Manager (SCCM) gathers lots of data from workstations and places it in the SCCM database. You can use this data to more intelligently manage your systems. For example, you can deploy a specific software product only to systems that don’t have it installed. Or you can obtain a report regarding software installed on systems and whether it is being used or not. This information is useful to assist you with licensing compliance.

Sometimes, administrators need to get some information from systems that is not gathered by SCCM.  For example, an in-house developed application creates an entry in the registry, and the administrator needs to know what systems have it enabled or set to a specific value. SCCM has a process called ”hardware inventory extension” that allows you to send your custom data to the SCCM database.  Getting custom data from the registry or WMI is fairly straight-forward as there is a registry provider and a WMI provider that allow you query for data.

In this article, we provide information on how to get the systems to send information of a specific event.  This solution was put together from an actual need by administrators to determine what Active Directory (AD) group policies the machines were applying. When the systems refresh their machine policies, they log a trace event in the Group Policy trace event. Trace events are different than the standard Windows event logs. Below you can see that trace events are in a different node in event viewer: Applications and Services


Events from standard Windows logs can be easily obtained by querying WMI but not Trace events. Part of this solution involves getting the trace events and putting them into WMI. Then the WMI provider is used to get the data into SCCM.

A powershell script was created to get the events into WMI. The script first creates a custom WMI class to define the type of data that will be stored in WMI. Then it gets the specific events (Group Policy event 5312) that have been logged in the last three days. The data from these events is recorded into WMI.

This is a sample of the information that event 5312 provides:

Sometimes the event indicates that no group policy was applied.  The reason is out of the scope of this article but our solution will concentrate on obtaining the group policy objects that get applied.

This is the powershell script that gets the last events 5312 that were logged and puts them into a custom WMI class. Every event that gets recorded into WMI is called an instance of our class. When the script runs, it first deletes any existing instances before adding the new instances of the events logged in the last three days. This is so we don’t have new instances appended to old ones when the script runs.

The script, called in this example event5312toWmi.ps1, has three functions, which are hi-lited. The first line of the EventsToWMI function has the following at the end: “days 3″. This is what determines how many days back from the time the script runs, to gather the events. You can change this number to any number of days that fits your needs.

The AddInstance function starts by defining that the data collected consists of a field type Date, and another field of type Text.

The createClass function creates a custom class in the root\cimv2 WMI namespace Russell_Event_5312.  The fourth line indicates that the SMS_Group_Name is Event_5312. This is the group name that will be used in SCMM.

Now we need to let SCCM know that it needs to get our custom data from WMI on each machine into the SCCM database. We do this by modifying two configuration files that tell SCCM what data to collect: configuration.mof and sms_def.mof. These files are in the following directory:

<SCCM_install_dir>\inboxes\clifiles.src\hinv

Add the following at the end of the configuration.mof file:

Add the following to the end of the SMS_DEF.mof file:

When you add the above information to the MOF files, SCCM will compile the new instructions, the dataldr.log SCCM log (in <SCCM_Install_Dir>\Logs) will immediately log “SMS_DEF.Mof change detected” or “Configuration.Mof change detected”. It will then log any errors if the compilation failed, or it will log “end of cimv2\sms-to-policy conversion; returning 0×0” if the compilation was successful and no error was detected.
After a successful compilation of the MOF changes, the next time client systems obtain policies from the Management Point, they will be instructed to report the custom data, and SCCM will be ready to receive it.

Now we need to find a way for the systems to run the powershell script at a regular basis. Since we have SCCM, we’ll have SCCM do it for us. We create an SCCM package that contains two files: the powershell script, and a batch or cmd file to call the script. In this example, we create a file called runEvent5312toWMI.cmd containing one line:

powershell.exe -NoLogo -ExecutionPolicy RemoteSigned %~dp0event5312toWmi.ps1 > c:\Event5312toWmi.log

The command line in the .cmd file runs the powershell script and sends the output to c:\Event5312toWmi.log in case you need to troubleshoot the execution of the script.

The Program in the SCCM package will just call the .cmd file.

You can advertise the program to a collection or collections of systems that you want to obtain this custom data from, and you can set the advertisement in a recurrent schedule to keep the data in SCCM current. For example, you can run the script once a day. Clients will get the data from WMI and send it to SCCM as frequently as the hardware inventory agent is configured to do so.

Once the data makes it SCCM, you can look at Resource Explorer in SCCM for one machine to see the data.

Finally, you can create some custom reports in SCCM to analyze the custom data in the SCCM database.

You can use the following queries to create SCCM reports.

All events 5312 for specified machine excluding events with “None” as applied GPO

select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.TimeCreated00 AS “Time

Created”, Event.GPOList00 AS “GPO List” from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID WHERE sys.Netbios_Name0 = @ComputerName AND Event.GPOList00 <> ‘None’ order by Event.TimeCreated00 DESC

prompt: ComputerName

begin

if (@filterwildcard = “)

SELECT DISTINCT SYS.Netbios_Name0 from v_R_System SYS WHERE SYS.Client0=1 ORDER By SYS.Netbios_Name0

else

SELECT DISTINCT SYS.Netbios_Name0 from v_R_System SYS WHERE SYS.Client0=1

and SYS.Netbios_Name0 like @_filterwildcard

ORDER By SYS.Netbios_Name0

end

Information for the last event 5312 on machines in collection excluding “none” for applied GPO

select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, MAX(Event.TimeCreated00) AS “Time Created”, Event.GPOList00 AS “GPO List” from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID JOIN v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> ‘None’ group by sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.GPOList00 order by sys.Netbios_Name0 DESC

Prompt CollectionID

begin

if (@_filterwildcard = “)

select v_Collection.CollectionID, v_Collection.Name from v_Collection order by

v_Collection.Name else

select v_Collection.CollectionID, v_Collection.Name from v_Collection

WHERE v_Collection.CollectionID like @filterwildcard

order by v_Collection.Name

end

Machines in collection that have “Baseline-Computer-Workstations” listed in the last Event 5312 excluding “None” applied

select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, MAX(Event.TimeCreated00) AS “Time Created”, Event.GPOList00 AS “GPO List” from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID JOIN v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> ‘None’ AND Event.GPOList00 LIKE ‘%Baseline-Computer-Workstations%’ group by sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.GPOList00 order by sys.Netbios_Name0 DESC

Prompt CollectionID

begin

if (@_filterwildcard = “)

select v_Collection.CollectionID, v_Collection.Name from v_Collection order by v_Collection.Name

else

select v_Collection.CollectionID, V-Collection.Name from v_Collection

WHERE v_Collection.CollectionID like @_filterwildcard

order by v_Collection.Name

end

Machines that don’t have “Baseline-Computer-Workstations” listed in the last Event 5312 excluding “None” applied

select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, MAX(Event.TimeCreated00) AS “Time Created”, Event.GPOList00 AS “GPO List” from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID join v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> ‘None’AND SYS.ResourceID NOT IN (SELECT sys.ResourceID FROM v_R_System SYS join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID JOIN v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> ‘None’ AND Event.GPOList00 LIKE ‘%Baseline-Computer-Workstations%’) group by sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.GPOList00 order by sys.Netbios_Name0 DESC

Prompt CollectionID

begin

if (@_filterwildcard = “)

select v_Collection.CollectionID, v_Collection,Name from v_Collection order by v_Collection.Name

else

select v_Collection.CollectionID, v_Collection.Name from v_Collection

WHERE v_Collection.CollectionID like @__filterwildcard

order by v_Collection.Name

end