First, here's a snip of the details of a sample certificate I wanted to check for.  Notice that the Issuer is "russlab-LABHOST-CA".  You could check the certificates Issuer, Subject, or any other property, but in my case, I'm going to look for the Issuer.

You have two options for running PowerShell scripts on clients, one is to sign the script with a trusted certificate, and the other is to set the PowerShell execution policy to "Bypass".  In my example, I won't be signing my PowerShell script, so I will go into Administration->Client Settings and select the default or create a new Client Settings.  Then go into the "Computer Agent" section of the client settings, and set the PowerShell execution policy to "Bypass".  This allows unsigned PowerShell scripts to execute when executed by the Computer Agent.  If you don't use the default client settings, you'll also need to make sure the custom client settings you created are also deployed to the collection you will be checking compliance on.

Now, go to Assets and Compliance->Compliance Settings->Configuration Items and click "Create Configuration Item".  The Create CI Wizard will appear.  Give it a meaningful name, select any categories if desired, and click "Next".

Select which operating systems are applicable and click "Next"

Click "New" to add a new setting to the CI.

Give the setting a meaningful name, change the Setting type to "Script" and leave the Data type "String".  Then click "Add Script"

Here's the PowerShell script I created for this demonstration.  It first sets a variable called "Compliance" to a value of "Compliant".  This way, if the certificate does NOT exist, we will call the machine compliant.  If the certificate DOES exist, we will set the Compliance variable to "Non-Compliant".  This assumes you do not want this certificate to be on any client.  If you want to make sure the cert IS on the clients, you can either flip things around in the script, or set the string to "Non-Compliant" instead of "Compliant" in the upcoming step.  You can massage the $Check = line to meet your specific needs.  The next line says if the results of the $Check has any data in it, set the variable $Compliance to "Non-Compliant".  Otherwise, it will still be set to "Compliant" because of the first line.  Finally, we echo out the value of $Compliance so ConfigMgr has something to go on.

Here it is again in copy/paste friendly format:

$Compliance = 'Compliant'
$Check = get-childitem -path cert:\localmachine -recurse | where-object {$_.Issuer -like '*RussLab*'}
If ($Check) {$Compliance = 'Non-Compliant'}
$Compliance

Now that you've pasted the script in, click the "Compliance Rules" tab and click "New" to add a new rule.

Give the rule a meaningful name, and put the word "Compliant" into the values.  As mentioned earlier, if you want to make sure the cert DOES exist on the machine, change this to "Non-Compliant" instead.  Select a severity level for Noncompliance and click "OK".

Next, Next through the wizard until the CI wizard completes.

Now go to Configuration Baselines and click "Create Configuration Baseline"

Click "Add", and select "Configuration Items"

Add the CI you just created, select any assigned categories if you wish, and click "OK" a couple of times until the Create Baseline wizard completes.

Now, right-click the new Configuration Baseline you just created and select "Deploy".

Click "Browse" and select the collection you want to check for the existence of the certificate on.  Select a schedule of how often you want to check the clients.

Click OK to complete the Deploy Configuration Baselines wizard.

Now, initiate a Machine Policy Retrieval on your test client to speed things along a bit, and then go to the Configuration tab.  Once it appears, click the ''Evaluate" button to once again speed things along a bit.

As you can see, it will come back with either Compliant or Non-Compliant.  In my demo, it came back as Non-Compliant because I didn't want the certificate to exist on my clients, but it does exist.

Now, you can also run a built-in report like "Summary compliance by configuration baseline" or another preferred report.

Voila!  Now I know that my client has the certificate on it that I don't want it to have!

Now, what if you want to verify that you have your "ConfigMgr Client Certificate" on all your clients before enabling HTTPS across the board?  The challenge with this is if you followed the directions on TechNet to a T, you don't have any friendly name to search on, and only the certificate template is something unique to look for.

A script like the one below pasted into your CI will accomplish this verification (assuming you named your ConfigMgr Client Certificate template the same as mine if you followed https://technet.microsoft.com/en-us/library/gg682023.aspx#BKMK_client2008_cm2012 to create your ConfigMgr client certificate templates.  If not, just modify the Template –eq line to meet your needs to match your template.)

$cert = Get-ChildItem Cert:\localmachine\My |

% {

$_ | Select `

Friendlyname,

Thumbprint,

@{N="Template";E={($_.Extensions |

?{$_.oid.Friendlyname -match "Certificate Template Information"}).Format(0) `

-replace "(.+)?=(.+)\((.+)?", '$2'}},

@{N="Subject";E={$_.SubjectName.name}}

}

foreach ($a in $cert)

{

if ($a.Template -eq "ConfigMgr Client Certificate") {$Compliance = "Compliant"}

}

$Compliance

What if you want to just find out which web servers have Server Authentication certificates that are going to expire in 90 days? An important thing to note here is certificates with an issuer starting with CN=MS-Organization-P2P-Access need excluded since they are pushed from AzureAD, and they also have an "Intended purpose" of Server Authentication even though they're on a workstation OS.

$certchk = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.EnhancedKeyUsageList.FriendlyName -eq "Server Authentication" -and $_.Issuer -notlike "CN=MS-Organization-P2P-Access*"} | Select-Object -Property PSComputerName, Subject, @{n='ExpireInDays';e={($_.notafter – (Get-Date)).Days}} | Where-Object {$_.ExpireInDays -lt 90}

If (!($certchk)) {$Compliance="Compliant"}

Else {$Compliance="Non-Compliant"}

$Compliance

Enjoy!

To download the ConfigMgr baseline and CIs to detect compliancy of machines, visit https://gallery.technet.microsoft.com/Speculation-Execution-Side-1483f621

Additional articles regarding the Speculation Control vulnerability

Security Advisory 180002 - Vulnerability in CPU Microcode Could Allow Information Disclosure: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

KB 4073229 - Protect your device against the recent chip-related security vulnerability: https://support.microsoft.com/help/4073229

KB 4073119 - Windows Client Guidance for IT Pros to protect against the speculative execution side-channel vulnerabilities: https://support.microsoft.com/help/4073119

KB 4072698 - Windows Server Guidance to protect against the speculative execution side-channel vulnerabilities: https://support.microsoft.com/help/4072698

KB 4072699 - Important Information regarding the Windows Security Updates Released January 2018 (A/V): https://support.microsoft.com/help/4072699

KB 4073235 - Microsoft Cloud Protections Against Speculative Execution Side-Channel Vulnerabilities: https://support.microsoft.com/help/4073235

KB 4073065 - Surface Guidance for Customers and Partners "Protect your devices against the recent chip-related security vulnerability": https://support.microsoft.com/help/4073065

KB 4073225 - Guide to protect SQL Server against speculative execution side-channel vulnerabilities

https://support.microsoft.com/en-gb/help/4073225/guidance-for-sql-server

Windows Client Updates

Windows Server Updates

Microsoft SQL

Operating System: Windows 2008 R2

SQL Server: SQL 2008 R2

Configuration Manager Version: If you’re currently running Configuration Manager 2012 R2 (with or without SP1) with co-located SQL 2008 or higher on your CAS or Primaries, you must first do an in-place upgrade to ConfigMgr 1511, and then upgrade to ConfigMgr 1602, as long as you’re running a supported version of SQL along the way for each version of ConfigMgr.  ConfigMgr 1602 supports an in-place OS upgrade of Windows 2008 R2 to Windows 2012 R2.

You can upgrade from SQL 2008 or SQL 2008 R2 to SQL 2012 or 2014, but I would recommend going to SQL 2014 so you don’t have to worry about upgrading SQL again for awhile.  As of this writing, SQL 2014 is the latest GA release of SQL.

You may choose to either do an in-place upgrade of SQL 2008 or 2008 R2 to 2014, or you may choose to uninstall SQL 2008 or 2008 R2 and install SQL 2014.

I’ll cover the in-place upgrade method first.  If you’re already on SQL 2012 or 2014, you can skip ahead to the Operating System upgrade steps.

Warning: This has not been tested in an environment with non domain-joined clients.  You may have issues with these clients which require manual intervention on the client to remediate them after this upgrade.

In-Place Upgrading SQL 2008 or 2008 R2 to SQL 2014

Stop SMS_EXECUTIVE service on the site server you are upgrading.  You may even want to temporarily set it to “Manual” start type in the event you need to restart.

Launch the SQL 2012 or 2014 Setup.exe

Select the “Upgrade from SQL” option under “Installation”

You will receive a warning about the User Database Compatibility Level being equal or less than 90.  The upgrade will change this compatibility level to 100 which is OK as long as you aren’t using SQL for anything other than Configuration Manager, SQL Reporting, or WSUS.  If you are using it for other applications, make sure your applications support the newer version before doing the upgrade.

If you fail any of the rules, you will need to take action to remediate them as necessary.

Click OK –> Next –> Upgrade to begin the upgrade process.

If there are any failures, the default directory for logs is C:\Program Files\Microsoft SQL Server\120\Setup Bootstrap\Log in a directory with the name format of YYYYMMDD_HHMMSS.  Look for log files in this directory and open them to determine the cause.  Also open the file named “Detail.txt” and scroll to the bottom to determine the error which prevented the upgrade.

One common issue you may run into is an error in the sqlncli_cpu64_1.log.  An error in this log may state “Product: Microsoft SQL Server 2012 Native Client  -- Configuration failed.”  The error in Detail.txt may state “Error result: –2068643839” and “Condition "Is the user's scenario set to EditionUpgrade" did not pass as it returned false and true was expected.”  If you receive this error, you may have the SQL 2012 Native Client installed.  Uninstall it and you should be able to proceed with the upgrade.

You can set SMS_EXECUTIVE back to Automatic start if you set it to Manual, and start it.  Launch the ConfigMgr Administration Console and verify it connects as expected.

Now that you have successfully upgraded SQL, you may want to uninstall the SQL 2008 or 2008 R2 Management Studio so that you don’t accidently continue using it.  To do so, just go to Programs and Features, and select SQL 2008 or 2008 R2, right-click and select Uninstall/Change, and the SQL 2008 or 2008 R2 Setup will launch.  Select all of the components you wish to remove, and the SQL 2008 or 2008 R2 components will uninstall.

Now your SQL Management Studio should show 12.2.2000 assuming you installed SQL 2014. 

Windows 2008 R2 –> Windows 2012 R2 Upgrade Process

Next we will upgrade the Windows 2008 R2 OS to Windows 2012 R2. 

If WSUS is currently installed on your Windows 2008 R2 based stand-alone primary or CAS, you must uninstall it first.  Of course, this also means you must uninstall your Software Update Point (SUP) role as well.  If you prefer to keep your SUSDB intact, you can export it first using the WSUSUTIL.EXE EXPORT <package filename> <logpath> command-line tool located by default in the %ProgramFiles%\Update Services\Tools directory.  Note, you may need to export the package filename using filename.xml.gz extension as a .cab is only sufficient for smaller files, and you may need a hotfix for WSUSUTIL EXPORT command to work properly.  See https://blogs.technet.microsoft.com/wsus/2013/04/09/problem-solved-the-wsus-export-bug/ for more details.  Once you install the WSUS role on your 2012 R2 server, you can then re-import it using WSUSUTIL.EXE IMPORT. Also I recommend installing KB3095113 hotfix after re-installing WSUS on your upgraded Windows 2012 server so that you can service Windows 10 clients.
Once this is completed, insert the Windows 2012 R2 with Update 1 media.
Run SETUP.EXE and click “Install Now” to begin.

Select “Go online to install updates (recommended)”

Enter your product key

Select the edition of Windows 2012 R2 to install

Select “Upgrade: Install Windows and keep files, settings, and applications”

The Compatibility Report will be saved to the desktop at this point.  Review it for any compatibility issues you may run into.

The upgrade process will begin

After the upgrade is complete, launch the ConfigMgr Admin Console, and if you have a hierarchy, verify your database replication is functioning properly.  It may temporarily show “Link failed” due to the site server being down for a period of time, but should clear up after replication resumes normal operation.

Windows 2008 or 2008 R2 will now be sitting in a directory in C:\Windows.old.  After you’re comfortable that things are working as they should be, feel free to run the disk cleanup utility and remove it to free up disk space on C:.

You will need to reinstall the BITS Feature as it will not be installed following the in-place upgrade, but you’ll need it for ConfigMgr, so make sure to re-add the BITS feature at this time.

Also the Windows Process Activation and World Wide Web Publishing services will most likely be disabled (I found this true on a child primary, but not my CAS).  Re-enable them and re-start them as needed.

Lastly, if you launch IIS Manager, you will probably find that the various application pools are set for “No managed code” under the .NET CLR Version column:

Set them back to their previous .NET CLR Versions as follows (note that the Classic .NET AppPool should be v2.0 and the rest should be v4.0), and restart the server afterwards.

Now I’ll cover the uninstall->reinstall method to get to SQL 2014.

Uninstalling SQL 2008 or 2008 R2 and Installing SQL 2014

First, we will uninstall SQL 2008 or 2008 R2.

First we need to run a PREINST /STOPSITE on the site server in order to successfully close all the connections so you can detach the database.

Right-click the ConfigMgr site database, select Tasks and Detach.

Check the boxes to drop connections and update statistics (if they appear) and click OK

Once all of the needed databases are detached, we can now uninstall SQL by launching Programs and Features, selecting Microsoft SQL 2008 or 2008 R2 from the list, and clicking Uninstall/Change

Click Select all to de-install all SQL 2008 or 2008 R2 features/components and click Next

SQL will now uninstall.

Following completion of the SQL 2008 or 2008 R2 uninstallation, proceed to the Windows 2008 –> Windows 2012 Upgrade Process above to do an in-place upgrade of the OS.

After the OS is upgraded, go through the normal SQL 2014 installation process, making sure to specify the ConfigMgr SQL Service account when prompted.

After SQL 2014 is installed, launch SQL Management Studio

Right-click Databases and click Attach

Click “Add” and browse to your detached ConfigMgr database MDF (it should find the LDF as well).

Click OK

Now click New Query, and make sure the CM_XYZ (replace XYZ with your site code) database is selected.  Next paste the following commands into the query window:

EXEC SP_CHANGEDBOWNER ‘SA’

ALTER Database CM_XYZ SET TRUSTWORTHY ON

ALTER DATABASE CM_XYZ SET SINGLE_USER WITH ROLLBACK IMMEDIATE

ALTER DATABASE CM_XYZ SET ENABLE_BROKER

ALTER DATABASE CM_XYZ SET MULTI_USER WITH ROLLBACK IMMEDIATE

SP_CONFIGURE 'CLR ENABLED', 1

RECONFIGURE

Now restart the SQL service, start the SMS_EXECUTIVE service, and launch the ConfigMgr admin console to verify it connects successfully and that if you have a hierarchy, DRS replication is functioning as expected.

If you have any issues connecting, review SMSPROV.LOG in the ConfigMgr logs directory or SMSADMINUI.LOG in your AdminConsole\Logs directory for clues

If you had to remove your SUP and WSUS, you may re-install WSUS, and then your SUP at this time. 

First things first…  Read through the upgrade checklist at https://technet.microsoft.com/en-us/library/mt691556.aspx.  Additionally, here are some scenarios to streamline your installation https://technet.microsoft.com/en-us/library/mt703292.aspx.  First things first, you MUST be running build 1511 in order to upgrade to build 1602.  If you are currently running ConfigMgr 2012 R2 SP1, you’ll first need to upgrade to build 1511.  Then you’ll be able to use the new in-console servicing upgrade feature to upgrade your hierarchy to 1602.  Also, as always it is recommended to take a backup prior to any upgrade, as well as run the /testdbupgrade on a copy of the most recent backup of your database prior to beginning any ConfigMgr upgrade.

Note: Even if you find unsupported methods to upgrade from ConfigMgr 2012 R2 SP1 to ConfigMgr 1602, not only is it not supported, but you will miss getting important database schema changes that take place during the 1511 upgrade process.  Do NOT take this unsupported route!

If you are running Configuration Manager build 1511 and aren’t yet seeing the Configuration Manager 1602 upgrade available in the Updates and Servicing node under the “Cloud Services” folder because you just finished upgrading to 1511 you may need to wait a bit.  The new Service Connection Point role downloads a ConfigMgr.Update.Manifest.cab every 24 hours and copies it to the inboxes\hman.bo\CFD directory.  The manifest identifies if there are new updates or hotfixes available to download.  If you still don’t see it after awhile and are OK with restarting SMS_EXECUTIVE, this can sometimes make it happen sooner.

Another reason you may not see the update is you may not have the proper RBAC permissions needed.  Your Security Scope setting radio button should be set to “All instances of the objects that are related to the assigned security roles” rather than “Only the instances of objects that are assigned to the specified security scopes and collections.”

Once you’re able to see it, the State should start off with “Downloading”.

Watch “DMPDownloader.log” in your ConfigMgr install directory, it will begin downloading files to the “<ConfigMgrInstallDir>\EasySetupPayload” directory.  ConfigMgrSetup.log in the root of C: will show the files being extracted and hashes being checked within the EasySetupPayload directory download directory.

If you click “Show status” in the lower right hand corner under “Related Objects” it will bring up the Site Servicing Status node.  Right-click the Update Package Name and again click “Show Status” which is also very informative.

You may see an error on occasion in dmpdownloader.log or ConfigMgrSetup.log.

In my experience, it seems to continue without fail, or recovers from this.  If it appears everything is stopped for a long period of time, as long as CMUpdate.exe process is running, just be patient – this process can take some time, but killing cmupdate.exe or stopping services may cause issues, so be patient here.

Finally, you should see the “State” change from “Downloading” to “Available”:

At this point, to be on the safe side I would recommend right-clicking the Configuration Manager 1602 node and selecting the “Run prerequisite check” option to verify your pre-requisites are all in place.  This will also verify pre-requisites on any child primaries you have as well.

The State column will change to “Checking prerequisites” and “Prereq Only” will change to “Yes”.

After a while, you’ll see C:\ConfigMgrPrereq.log begin updating.  If the State changes to Prerequisite check failed, review ConfigMgrPrereq.log to determine why.  Remediate the cause, and re-run the prerequisite checks again until the State finally changes to “Prerequisite check passed”

Now right-click the 1602 node and this time select “Install Update Pack”

You will be prompted with the following dialogs:

Select which features you want to enable in the following screen:

For the Options for Client Update prompt, I would recommend validating the client updates against a pre-production collection to be on the safe side.  After validating, you should then roll out the new client to the remaining clients.

The last two screens displayed are the license terms, and summary pages.  After finishing, the upgrade will proceed. Watch cmupdate.log for all the activity at this point as ConfigMgrSetup.log will no longer show any activity.  You will see CMUpdate.log downloading content to your <ConfigMgrInstallDir>\CMUStaging directory.  Also watch sitecomp.log for activity as well.

..and eventually:

After the upgrade is complete, the next time you launch the Configuration Manager Admin Console it will prompt you to update it.

Click OK, watch it upgrade, and if you have a standalone primary site, you’re all done.  If you just finished upgrading the CAS, the child primaries will automatically begin upgrading next.  If you have any secondary sites, you must update them manually.

Depending on which option you picked on the “Client Update Options” screen, your clients, or a subset of them will also begin automatically upgrading.  As always, the new client version will not be reflected in the console until they also run their next heartbeat discovery.

Make sure you if you’re using SQL backups in lieu of the internal site backup maintenance task, that you’re also backing up the CD.Latest folder as well.  Beginning with build 1511, this is your media for site recovery and reinstall activities.

Thanks for reading!

Thanks to all who attended the event!

InventoryCapture – Capture client hardware/software inventory or heartbeat before they upload to the management point, and output to CSV files for review https://gallery.technet.microsoft.com/Configuration-Manager-5eeaa49a

DPPing – Determine ICMP latency between clients and the distribution points within their boundary https://gallery.technet.microsoft.com/Determine-the-latency-46d2cd19

PatchTuesdayDeploymentCreator – Create dynamic deployments based on a number of days after Patch Tuesday  https://gallery.technet.microsoft.com/Patch-Tuesday-Deployment-f57cf9fc

RemoveExpiredUpdatesFromallGroups – Remove all expired software updates from all software update groups https://gallery.technet.microsoft.com/Remove-expired-updates-be68d12a

MaintWindowCreate – Create dynamic maintenance windows based on a number of days after Patch Tuesday https://gallery.technet.microsoft.com/Create-dynamic-maintenance-0f160f16

DPMonRedist – Uses a status filter rule automatically redistribute a package to a distribution point which has generated a content validation failed message. https://gallery.technet.microsoft.com/Distribution-Point-Monitor-f0d68e19

DPContentFix – Prompts for which distribution point to check, enumerates all packages and which distribution points they’re distributed to, and compares the two results.  The “Fix” button will initiate a redistribute on the selected package or packages. https://gallery.technet.microsoft.com/Find-and-fix-content-out-70edee54

ComputerImporter – Allows technicians who don’t have the ConfigMgr admin console installed the ability to import new devices into specified collection. https://gallery.technet.microsoft.com/Import-new-computers-cf57e377

I also HIGHLY recommend checking out MVP David OBrien’s CM12 documentation builder script which is extremely cool.  Another very cool script I recommend checking out is Nikolaj Andersen’s Configuration Manager 2012 Prerequisites tool.

First, here’s a snip of the details of a sample certificate I wanted to check for.  Notice that the Issuer is “russlab-LABHOST-CA”.  You could check the certificates Issuer, Subject, or any other property, but in my case, I’m going to look for the Issuer.

You have two options for running PowerShell scripts on clients, one is to sign the script with a trusted certificate, and the other is to set the PowerShell execution policy to “Bypass”.  In my example, I won’t be signing my PowerShell script, so I will go into Administration->Client Settings and select the default or create a new Client Settings.  Then go into the “Computer Agent” section of the client settings, and set the PowerShell execution policy to “Bypass”.  This allows unsigned PowerShell scripts to execute when executed by the Computer Agent.  If you don’t use the default client settings, you’ll also need to make sure the custom client settings you created are also deployed to the collection you will be checking compliance on.

Now, go to Assets and Compliance->Compliance Settings->Configuration Items and click “Create Configuration Item”.  The Create CI Wizard will appear.  Give it a meaningful name, select any categories if desired, and click “Next”.

Select which operating systems are applicable and click “Next”

Click “New” to add a new setting to the CI.

Give the setting a meaningful name, change the Setting type to “Script” and leave the Data type “String”.  Then click “Add Script”

Here’s the PowerShell script I created for this demonstration.  It first sets a variable called “Compliance” to a value of “Compliant”.  This way, if the certificate does NOT exist, we will call the machine compliant.  If the certificate DOES exist, we will set the Compliance variable to “Non-Compliant”.  This assumes you do not want this certificate to be on any client.  If you want to make sure the cert IS on the clients, you can either flip things around in the script, or set the string to “Non-Compliant” instead of “Compliant” in the upcoming step.  You can massage the $Check = line to meet your specific needs.  The next line says if the results of the $Check has any data in it, set the variable $Compliance to “Non-Compliant”.  Otherwise, it will still be set to “Compliant” because of the first line.  Finally, we echo out the value of $Compliance so ConfigMgr has something to go on.

Here it is again in copy/paste friendly format:

$Compliance = 'Compliant'
$Check = get-childitem -path cert:\localmachine -recurse | where-object {$_.Issuer -like '*RussLab*'}
If ($Check) {$Compliance = 'Non-Compliant'}
$Compliance

Now that you’ve pasted the script in, click the “Compliance Rules” tab and click “New” to add a new rule.

Give the rule a meaningful name, and put the word “Compliant” into the values.  As mentioned earlier, if you want to make sure the cert DOES exist on the machine, change this to “Non-Compliant” instead.  Select a severity level for Noncompliance and click “OK”.

Next, Next through the wizard until the CI wizard completes.

Now go to Configuration Baselines and click “Create Configuration Baseline”

Click “Add”, and select “Configuration Items”

Add the CI you just created, select any assigned categories if you wish, and click “OK” a couple of times until the Create Baseline wizard completes.

Now, right-click the new Configuration Baseline you just created and select “Deploy”.

Click “Browse” and select the collection you want to check for the existence of the certificate on.  Select a schedule of how often you want to check the clients.

Click OK to complete the Deploy Configuration Baselines wizard.

Now, initiate a Machine Policy Retrieval on your test client to speed things along a bit, and then go to the Configuration tab.  Once it appears, click the ‘'Evaluate” button to once again speed things along a bit.

As you can see, it will come back with either Compliant or Non-Compliant.  In my demo, it came back as Non-Compliant because I didn’t want the certificate to exist on my clients, but it does exist.

Now, you can also run a built in report like “Summary compliance by configuration baseline” or another preferred report.

Voila!  Now I know that my client has the certificate on it that I don’t want it to have!

Now, what if you want to verify that you have your “ConfigMgr Client Certificate” on all your clients before enabling HTTPS across the board?  The challenge with this is if you followed the directions on TechNet to a T, you don’t have any friendly name to search on, and only the certificate template is something unique to look for.

A script like the one below pasted into your CI will accomplish this verification (assuming you named your ConfigMgr Client Certificate template the same as mine if you followed https://technet.microsoft.com/en-us/library/gg682023.aspx#BKMK_client2008_cm2012 to create your ConfigMgr client certificate templates.  If not, just modify the Template –eq line to meet your needs to match your template.)

$cert = Get-ChildItem Cert:\localmachine\My |
    % {
    $_ | Select `
        Friendlyname,
        Thumbprint,
        @{N="Template";E={($_.Extensions |
            ?{$_.oid.Friendlyname -match "Certificate Template Information"}).Format(0) `
                -replace "(.+)?=(.+)\((.+)?", '$2'}},
        @{N="Subject";E={$_.SubjectName.name}}
    }

foreach ($a in $cert)
      {
        if ($a.Template -eq "ConfigMgr Client Certificate") {$Compliance = "Compliant"}
      }
$Compliance

Enjoy!

Similar to one of my past blog posts on how to go about collecting network adapter driver information including which are wireless versus wired adapters, you can also collect things like Scanners, Digital Cameras, and WebCams which are attached to your clients.

The registry key for these “Imaging Devices” is located in the registry at HKLM\SYSTEM\CurrentControlSet\Control\Class\{6bdd1fc6-810f-11d0-bec7-08002be2092f} 

If you take a look at this MSDN page for STI_DEVICE_TYPE Enumeration, you’ll learn that for the DeviceType registry value,

Scanner         = 1
DigitalCamera   = 2
StreamingVideo  = 3

For the value SubClass, “StillImage” is also a value that exists for Digital Cameras and Scanners as they are obviously still image creation devices.

Now – let’s get on with the fun!

Make a backup of your current configuration.mof in your \Inboxes\clifiles.src\hinv, and copy and paste the information from the configuration.mof snip to your Configuration.mof in (see below):

[ dynamic,
  provider("RegProv"),
  ClassContext("local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{6bdd1fc6-810f-11d0-bec7-08002be2092f}")
]
class Win32Reg_ImagingDevices
{
    [key]
        string    Index;
    [PropertyContext("DeviceType")]
        uint32 DeviceType; 
    [PropertyContext("DriverDesc")]
        string    DriverDesc;
    [PropertyContext("DriverVersion")]
        string    DriverVersion;
    [PropertyContext("DriverDate")  ]
        string    DriverDate;
    [PropertyContext("ProviderName")]
        string    ProviderName;
    [PropertyContext("SubClass")  ]
        string    SubClass;
};

Paste it into configuration.mof on your site server between the section at the bottom in between “// Added extensions start” and “//Added extensions end” and save it, so the final result looked like this:

Next, enter the information from the snip below into a somefilename.MOF for importing into your hardware inventory section of Administration/Client Settings.  All of this will be inserted into the new SQL View it will automatically create named “v_GS_IMAGING_DEVICES”.

#pragma namespace ("\\\\.\\root\\cimv2\\sms")
 
  [ SMS_Report     (TRUE),
  SMS_Group_Name ("Imaging Devices"),
  SMS_Class_ID   ("MICROSOFT|IMAGING_DEVICES|1.0"),
  Namespace      ("\\\\\\\\localhost\\\\root\\\\cimv2") ]
 
  class Win32Reg_ImagingDevices : SMS_Class_Template
  {
    [SMS_Report (TRUE), key ]
        string Index;
    [SMS_Report (TRUE)      ]
        uint32 DeviceType;
    [SMS_Report (TRUE)      ]
        string DriverDesc;
    [SMS_Report (TRUE)      ]
        string DriverVersion;
    [SMS_Report (TRUE)      ]
        string DriverDate;
    [SMS_Report (TRUE)      ]
        string ProviderName;
    [SMS_Report (TRUE)      ]
        string SubClass;
  };

Here’s what the .MOF you’ll import into client settings should end up looking like:

Go to Administration/Client Settings and modify Default Client Settings on your top-level site server.  Drill into the Hardware Inventory, and click “Set Classes”:

Next, click “Import” and browse to the .MOF file you saved.

Leave the “Import Summary” option at the default of “Import both hardware inventory classes and hardware inventory class settings”.  Once again click the “Import” button.

Select which classes you want to collect, and click OK a couple times.

Now, initiate a machine policy retrieval and a hardware inventory on a client or two which has a Scanner or other imaging device connected so the database gets populated with the new SQL view.  You can confirm the view exists by running a select * from v_GS_Imaging_Devices in SQL Management studio to confirm that you can proceed with creating the report.

Next, go to Monitoring->Reporting->Reports and click “Create Report”

The “Create Report Wizard” will appear.  Select “SQL-based Report”, give it a memorable name, and select which folder on your SSRS you want to store it in.  Click “Next", “Next”, “Close”.

Once SQL Report Builder appears, select “Table or Matrix”:

And then “Create a Dataset”.  The “New Table or Matrix” wizard appears with your Data Source Connection to your ConfigMgr database.  Click the “Test Connection” if you want to confirm all is well.

If you don’t have the required permissions with your currently logged on account, instead of using your currently logged on credentials, type in the login credentials for an account which has the appropriate permissions to the site database, and click “Next”.

In the “Design a query” wizard, expand dbo –>Views:

Next, expand v_GS_IMAGING_DEVICES and select the values that you want included in your report.  I recommend at a minimum ResourceID, DriverDate0, DriverDesc0, DriverVersion0, ProviderName0, SubClass0, and DeviceType0.  These will be listed in v_GS_IMAGING_DEVICES which is our Imaging Device information:

Then, select Name0 from the v_GS_System view so that you will also get a computer name included.

Click on “Auto Detect”, and then click the “Add Relationships” button to the right of “Edit Fields”

Single click into the “Left Table”, selecting one of the two tables, then single click into the “Right Table”, and of course select the other view.  Your join can be Inner, Left Outer, Right Outer, or Full Outer, but I’m not going to go into depth on SQL joins today, so you can read more about them here.

Now, click the “Add Field” button:

Under the “Left Join Field”, select “ResourceID”.  Then under the “Right Join Field” column, once again select “ResourceID”.  ResourceID is the field which you should always be familiar with as pretty much every report that contains information about clients has a unique ResourceID value which identifies each client and allows you to join the various views together for reporting purposes.

Now the final result should look like the image below:

If all is well, click “Next” to continue, and on the “Arrange fields” step, drag “Name0” to the “Row groups” box, and the rest of the information you want associated with each computer name to the “Values” box” and click “Next”.

Uncheck the “Show subtotals and grand totals” and “Expand/collapse groups” checkboxes.

Select your favorite style, click Finish, and after your clients run their next hardware inventory, you should have a report showing each of your scanners, digital cameras, and webcams and their pertinent driver information, manufacturer, etc.  You can also customize the column names to something more meaningful as I have below (ie. Name0 –> Computer Name):

Now, if you want to filter it down to something like only the scanners, under Datasets,  right-click “DataSet1” and click “Properties”.

Then click “Filters” and click "Add” to add a filter:

In “Expression” field, select “[DeviceType0]”.  Leave the Operator at "=”, and the value for all Scanners is “1”.

Save the report, run it again, and viola, only the scanners will appear for each client, along with their driver dates, descriptions, and versions.

Now, run the report and pat yourself on the back for making it to the end of this blog post (and hopefully you even have a working report!)

With the introduction of applications in Configuration Manager 2012, applications and packagaes are now stored in a \SCCMContentLib folder, within the DataLib, FileLib, and PkgLib sub-folders.  For more information on how these folders are used, see this blog post.

Now, what if you’re looking in distmgr.log and see something like “Taking snapshot for content Content_54e07188-f697-44d3-8b2b-eb09234522be.1 from source \\server\share”

Or on a client’s CAS.log stating something like “Download started for content 0d5f261e-87c7-4e5d-872f-c92b12e1ac78.1”

Or while looking at a client’s Datatransferservice.log you run into an entry like “UpdateURLWithTransportSettings(): NEW URL - https://mylab.com:80/SMS_DP_SMSPKG$/Content_65fbb8e9-8de2-42da-ae80-44e52e44f95e.1”

Or maybe you’re looking through your Content Library’s DataLib and see the Content_ folders and want to know which applications they map to.

Quickly determining via the admin console which package is being referenced can be a challenge – you could add the “Content ID” column and go to the deployment types tab of each application to find a match…  Your mouse may quickly tire out.

I created an easier way using PowerShell to translate the Content_ directories into plain English package IDs and names.  Below is an example of what this looks like in action.  Just run the script, supplying the –dbserver, –dbname, and –content switches.  If you just run .\contentxlate.ps1 without any switches, you’ll be prompted to enter each value.

Alternatively, you could create a single report to list out all applications with their Content_ folders and associated Pkg IDs:

Here are both solutions depending on your needs.

SQL QUERY for a REPORT

SELECT LP.DisplayName,
CP.CI_ID,
CPS.PkgID,
CPS.ContentSubFolder
FROM dbo.CI_ContentPackages CPS
INNER JOIN dbo.CIContentPackage CP
ON CPS.PkgID = CP.PkgID
LEFT OUTER JOIN dbo.CI_LocalizedProperties LP
ON CP.CI_ID = LP.CI_ID
ORDER BY LP.LocaleID DESC

POWERSHELL SCRIPT

<#
.EXAMPLE
    PS C:\Scripts> .\contentxlate.ps1 -dbserver yourdbserver.local -dbname CM_XXX -content Content_54e07188-f697-44d3-8b2b-eb09234522be.1

.NOTES
    NAME: contentxlate.ps1
    VERSION: 0.1
    AUTHOR: Russ Rimmerman, Premier Field Engineer
    LASTEDIT: December 17, 2013
    Change history:
        12.17.2013: Created script
#>

Param(    
    [parameter(
    Position = 0, 
    Mandatory=$true )
    ] 
    [ValidateNotNullOrEmpty()]
    [string]$dbserver="",
    
    [parameter(
    Position = 1, 
    Mandatory=$true )
    ]
    [ValidateNotNullOrEmpty()]
    [string]$dbname="",

    [parameter(
    Position = 2, 
    Mandatory=$true )
    ] 
    [ValidateNotNullOrEmpty()]
    [string]$content=""
    
)

$sqlquery = "SELECT LP.DisplayName,
CP.CI_ID,
CPS.PkgID
FROM dbo.CI_ContentPackages CPS
INNER JOIN dbo.CIContentPackage CP
ON CPS.PkgID = CP.PkgID
LEFT OUTER JOIN dbo.CI_LocalizedProperties LP
ON CP.CI_ID = LP.CI_ID
WHERE CPS.ContentSubFolder = `'"
$sqlquery += $content
$sqlquery += "`' ORDER BY LP.LocaleID DESC"

invoke-sqlcmd -Serverinstance $dbserver -database $dbname -query $sqlquery

Download the toolkit from: https://www.microsoft.com/en-us/download/details.aspx?id=36213

Here is a summary of the changes and contents of the R2 Toolkit:

Server Based Tools 

• * DP Job Manager - A tool that helps troubleshoot and manage ongoing content distribution jobs to Configuration Manager distribution points.
• * Collection Evaluation Viewer - A tool that assists in troubleshooting collection evaluation related issues by viewing collection evaluation details.
• * Content Library Explorer - A tool that assists in troubleshooting issues with and viewing the contents of the content library.
• Security Configuration Wizard Template for Microsoft System Center 2012 R2 Configuration Manager - The Security Configuration Wizard (SCW) is an attack-surface reduction tool for the Microsoft Windows Server 2008 R2 operating system. Security Configuration Wizard determines the minimum functionality required for a server's role or roles, and disables functionality that is not required.
• Content Library Transfer – A tool that transfers content from one disk drive to another.
• Content Ownership Tool – A tool that changes ownership of orphaned packages (packages without an owner site server).
• Role-based Administration Modeling and Auditing Tool – This tool helps administrators to model and audit RBA configurations.
• Run Metering Summarization Tool - The purpose of this tool is to run the metering summarization task to analyze raw metering data

• Client Spy - A tool that helps you troubleshoot issues related to software distribution, inventory, and software metering on System Center 2012 Configuration Manager clients.
• Configuration Manager Trace Log Viewer – A tool used to view log files created by Configuration Manager components and agents.
• Deployment Monitoring Tool - The Deployment Monitoring Tool is a graphical user interface designed help troubleshoot Applications, Updates, and Baseline deployments on System Center 2012 Configuration Manager clients.
• Policy Spy - A policy viewer that helps you review and troubleshoot the policy system on System Center 2012 Configuration Manager clients.
• Power Viewer Tool – A tool to view the status of power management feature on System Center 2012 Configuration Manager clients.
• Send Schedule Tool - A tool used to trigger a schedule on a client or trigger the evaluation of a specified DCM Baseline. You can trigger a schedule either locally or remotely.
• Wakeup Spy – A tool that provides a view of the power state of Configuration Manager client computers and which operate as managers or manages.

You can view the MSDN online SDK content here: https://msdn.microsoft.com/en-us/library/hh948960.aspx

Download the installable SDK from here: https://www.microsoft.com/en-us/download/details.aspx?id=29559

Here is a summary of the changes and contents of the R2 SDK:

What's new in the System Center 2012 R2 Configuration Manager SDK

The following topics are new or updated in the System Center 2012 R2 Configuration Manager SDK:

• New Solutions and Samples
  • Solution: Configuration Manager Application Approval Workflow
  • Sample: How to create Software Update groups (SUMCreateGroup)
  • Sample: How to assign Software Update groups (SUMAssignGroup)
• New Classes and Methods
  • AddChangeNotification Method in Class SMS_VhdPackage
  • AddDistributionPoints Method in Class SMS_VhdPackage
  • CancelDistribution Method in Class SMS_DistributionPoint
  • ChangeOwnership Method in Class SMS_Collection
  • ClientEditions Method in Class SMS_Collection
  • GetChainedPullDPs Method in Class SMSDistributionPointInfo
  • GetImageProperties Method in Class SMS_VhdPackage
  • GetTSRelatedToDriverCategory Method in Class SMS_TaskSequencePackage
  • ReassignClientsToSite Method in Class SMS_Collection
  • RefreshPkgSource Method in Class SMS_VhdPackage
  • ReloadImageProperties Method in Class SMS_VhdPackage CCM_NetworkSettings Client WMI Class
  • RunOfflineServicingManager Method in Class SMS_VhdPackage
  • SetSourceSite Method in Class SMS_VhdPackage
  • SMS_ClientResourcesConfig Server WMI Class
  • SMS_DistributionJob Server WMI Class
  • SMS_G_SYSTEM_ResourceClientSettingsAssignment Server WMI Class
  • SMS_ObjectContentExtraInfo Server WMI Class
  • SMS_UserSettings Server WMI Class
  • SMS_UserVariable Server WMI Class
  • SMS_VhdPackage Server WMI Class
  • Unlock Method in Class SMS_VhdPackage
• Updated Classes and Methods
  • CCM_SoftwareBase Client WMI Class
  • CheckReferencesShareType Method in Class SMS_TaskSequencePackage
  • CreateCCR Method in Class SMS_Collection
  • CreateCCRs Method in Class SMS_Collection
  • CreateCCRs Method in Class SMS_Query
  • SMS_AppDeploymentAssetDetails Server WMI Class
  • SMS_Application Server WMI Class
  • SMS_ApplicationLatest Server WMI Class
  • SMS_BaselineAssignment Server WMI Class
  • SMS_BootImagePackage Server WMI Class
  • SMS_CIAssignmentBaseClass Server WMI Class
  • SMS_ClientCommunicationConfig Server WMI Class
  • SMS_Collection Server WMI Class
  • SMS_CollectionMember_a Server WMI Class
  • SMS_CombinedDeviceResources Server WMI Class
  • SMS_ConfigurationPolicyAssignment Server WMI Class
  • SMS_ContentPackage Server WMI Class
  • SMS_DeviceSettingPackage Server WMI Class
  • SMS_DistributionPoint Server WMI Class
  • SMS_DistributionPointInfo Server WMI Class
  • SMS_DriverPackage Server WMI Class
  • SMS_EndpointProtectionAgentConfig Server WMI Class
  • SMS_FullCollectionMembership Server WMI Class
  • SMS_G_System_AppClientState Server WMI Class
  • SMS_ImageInformation Server WMI Class
  • SMS_OperatingSystemInstallPackage Server WMI Class
  • SMS_Package Server WMI Class
  • SMS_PackageBaseclass Server WMI Class
  • SMS_Query Server WMI Class
  • SMS_ServiceWindow Server WMI Class
  • SMS_Site Server WMI Class
  • SMS_SoftwareUpdate Server WMI Class
  • SMS_SoftwareUpdatesPackage Server WMI Class
  • SMS_TaskSequencePackage Server WMI Class
  • SMS_TaskSequencePackageReference_Flat Server WMI Class
  • SMS_UpdateGroupAssignment Server WMI Class
  • SMS_UpdatesAssignment Server WMI Class

Hmm, it’s not there.  Then I think to myself, it must be Monday?!

So, I’ve learned over time that it’s not always the case – sometimes the seemingly most simple bits of information you want aren’t readily available for you out of the box.

So, what is a good example of this?  The most recent one I ran into was a request to report on wireless network drivers and versions.  I though for sure it would be included somewhere in Win32_NetworkAdapter or Win32_NetworkAdapterConfiguration or Win32_PnPEntity.  Nope, it’s not there, maybe I’m missing it.

So my next question – where is it?  I then came across a WMI Class called Win32_PNPSignedDriver.  Well, that’s a very interesting WMI Class with lots of good information - including the information I’m looking for – however it contains way more than just network adapters, and to make matters worse, importing the pertinent information into my Configuration Manager 2012 Hardware Inventory didn’t collect anything from this Class no matter how hard I kicked it.

That’s when I came across a blog posting written by Vinay Pamnani, which helpfully pointed out a registry key which contains all the information I needed!

The registry key for network adapter driver information is at HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318. 

As Vinay’s blog posting was created back in Feb 2010, it was clear that it was for Configuration Manager 2007.  Knowing this, it was time to take the information learned from his blog post and try it out in my trusty Configuration Manager 2012 R2 lab.

First, I (of course) made a backup copy of my configuration.mof in ConfigMgr\Inboxes\clifiles.src\hinv.  I then copied the information from Vinay’s Configuration.mof snip (see below) into my clipboard and added a few more entries I found interesting:

[ dynamic,
  provider("RegProv"),
  ClassContext("local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{4D36E972-E325-11CE-BFC1-08002bE10318}")
  ]
  class Win32Reg_NetworkDrivers
  {
    [key]
        string    Index;
    [PropertyContext("DriverDesc")]
        string    DriverDesc;
    [PropertyContext("DriverVersion")]
        string    DriverVersion;
    [PropertyContext("DriverDate")  ]
        string    DriverDate;
    [PropertyContext("ProviderName")]
        string    ProviderName;
    [PropertyContext("*MediaType")  ]
         string    MediaType;
    [PropertyContext("RemoteWakeEnable")  ]
        string    RemoteWakeEnable;
    [PropertyContext("*WakeOnMagicPacket")  ]
        string    WakeOnMagicPacket;
  };

Next, I pasted it into my configuration.mof on my CAS (yes, even at my own home there’s enough politics to cause me to have a CAS).  Next, I simply pasted it between the section at the bottom in between “// Added extensions start” and “//Added extensions end” and saved it, so the final result looked like this:

This change provided my Configuration Manager hierarchy the knowledge about this registry key and all of the information of my interest within the key.  Looking at this key, there are a plethora of other values to collect, but the only ones I added over and above Vinay’s example were: Provider, RemoteWakeEnable, and *WakeOnMagicPacket.  If desired, I could’ve easily gathered additional information from this key such as the wireless roaming aggressiveness settings, whether or not the wireless radio is enabled, preferred wifi channel, PNP Device info - the list goes on.

Next, I copied the information for the SMS_DEF.MOF file, but once again, I added the additional information for ProviderName, RemoteWakeEnable, and WakeOnMagicPacket to let my ConfigMgr site know that I also want it to collect the information stored in these registry values during my client hardware inventories.  All of this will be inserted into the new SQL View it will automatically create named “v_GS_NETWORK_DRIVERS”.

Here’s what I ended up with for my MOF to import into my Hardware Inventory:

#pragma namespace ("\\\\.\\root\\cimv2\\sms")
  [ SMS_Report     (TRUE),
  SMS_Group_Name ("Network Drivers"),
  SMS_Class_ID   ("MICROSOFT|NETWORK_DRIVERS|1.0"),
  Namespace      ("\\\\\\\\localhost\\\\root\\\\cimv2") ]
  class Win32Reg_NetworkDrivers : SMS_Class_Template
  {
    [SMS_Report (TRUE), key ]
        string Index;
    [SMS_Report (TRUE)      ]
        string DriverDesc;
    [SMS_Report (TRUE)      ]
        string DriverVersion;
    [SMS_Report (TRUE)      ]
        string DriverDate;
    [SMS_Report (TRUE)      ]
        string MediaType;
    [SMS_Report (TRUE)      ]
        string ProviderName;
    [SMS_Report (TRUE)      ]
        string RemoteWakeEnable;
    [SMS_Report (TRUE)      ]
        string WakeOnMagicPacket;
  };

Knowing there’s no longer an SMS_DEF.MOF that exists in clifiles.src/hinv on ConfigMgr 2012, I instead pasted it into a new file I created in Notepad and named it something memorable but only slightly witty such as “wifidriversarefun.MOF”.  I went to my Administration/Client Settings and modified my Default Client Settings on my CAS.  Next, I drilled into the Hardware Inventory section of my Default Client Settings (note: you MUST select Default Client Settings) and clicked the “Set Classes” button:

Next, click “Import” and browse to the “wifidriversarefun.MOF” file you saved.

Leave the “Import Summary” option at the default of “Import both hardware inventory classes and hardware inventory class settings”.  Once again click the “Import” button.

I also left all of the class settings checked since I wanted everything that I defined in both my configuration.mof and my imported Hardware Inventory MOF, and clicked OK a couple times.

Next, go to Monitoring->Reporting->Reports and click “Create Report”

The “Create Report Wizard” will appear.  Select “SQL-based Report”, give it a memorable name, and select which folder on your SSRS you want to store it in.  Click “Next", “Next”, “Close”.

Once SQL Report Builder 3.0 appears, select “Table or Matrix”:

And then “Create a Dataset”.  The “New Table or Matrix” wizard appears with your Data Source Connection to your ConfigMgr 12 database.  Click the “Test Connection” to confirm all is well.

If you don’t have the required permissions with your currently logged on account, instead of using your currently logged on credentials, type in the login credentials for an account which has the appropriate permissions to the site database, and click “Next”.

In the “Design a query” wizard, expand dbo –>Views:

Next, expand v_GS_NETWORK_DRIVERS and select the values that you want included in your report; first from v_GS_NETWORK_DRIVERS to get the new Network Adapter Driver information:

Then, select Name0 from the v_GS_System view so that you will also get a computer name included.

Click on “Auto Detect”, and then click the “Add Relationships” button to the right of “Edit Fields”

Single click into the “Left Table”, selecting one of the two tables, then single click into the “Right Table”, and of course select the other view.  Your join can be Inner, Left Outer, Right Outer, or Full Outer, but I’m not going to go into depth on SQL joins today, so you can read more about them here.

Now, click the “Add Field” button:

Under the “Left Join Field”, select “ResourceID”.  Then under the “Right Join Field” column, once again select “ResourceID”.  ResourceID is the field which you should always be familiar with as pretty much every report that contains information about clients has a unique ResourceID value which identifies each client and allows you to join the various views together for reporting purposes.

Now the final result should appear like this:

If all is well, click “Next” to continue, and on the “Arrange fields” step, drag “Name0” to the “Row groups” box, and the rest of the information you want associated with each computer name to the “Values” box” and click “Next”.

Uncheck the “Show subtotals and grand totals” and “Expand/collapse groups” checkboxes.

Select your favorite SSRS style:

Now you should have a nice report showing each of your network adapters and their pertinent driver information, as well as some additionally helpful wake-on-lan information.  You can also customize the column names to something more meaningful as I have below (ie. Name0 –> Computer Name):

Now, if you want to filter it down to only the wireless network adapters, under Datasets,  right-click “DataSet1” and click “Properties”.

Then click “Filters” and click "Add” to add a filter:

In “Expression” field, select “MediaType0”.  Leave the Operator at "=”, and the value of MediaType0 for all wireless adapters happens to be a value of “16”.

Save the report, run it again, and viola, only the wireless network adapters and their driver information will magically appear for each client, along with their driver dates, descriptions, versions and WakeOnLan settings.

Now, for an extra bonus, if you want to be able to click on any client and have it show you some additional Network Adapter information for a specific client, right click in the [Name0] cell, and click “Text Box Properties”

Click “Action” and in the “Change Action Options” section, select the “Go to report” radio button, click “Browse”, and browse to the Hardware – Network Adapter / “Network Adapter information for a specific computer” report.  Under “Use these parameters to run the report”, click “Add”, select “variable” in the Name field, and “[Name0]” in the Value field, and click OK.

Now, run the report and pat yourself on the back for making it to the end of this blog post (and hopefully you even have a working report!)