Archive for May, 2013

After the “Update for System Center Endpoint Protection 2012 Client – KB2831316”  was released back in April and the SCEP 2012 version was updated from 4.1.522.0 to every client we deployed always had to install the KB2831316 after it was deployed to get the updated version.

So today I decided to install “KB2828233 – An anti-malware platform update for stand-alone System Center 2012 Endpoint Protection Service Pack 1 clients is available from Microsoft Update” that fixes this problem since it will update the client files on the site server to the newest version;


when a client is deployed now it will have version of SCEP 2012 installed directly.

After the update was installed on my site server and the distribution point was updated, I decided to re-deploy a computer to verify that it worked. So this was when the “fun” began, when the Task Sequence reach the “Setup Windows and ConfigMgr” step, the Task Sequence fails and the sccm client will not install. I tried 2 more times with the exact same result. So what is happening?

I logon to the machine to take a look at the ccmsetup.log (located here; C:\Windows\ccmsetup\Logs) and there I see what the problem is;

File ‘C:\Windows\ccmsetup\SCEPInstall.exe’ with hash ‘495B488FFCEE7C2D682AC6ABFC62D7F9CCB15E22911BA2B76C41307343E617CC’ from manifest doesn’t match with the file hash ‘EEBF8FBE6920D51B2728DE6303457F25DE302C1E3A5742ED175D281CAEC276BD’ ccmsetup 5/24/2013 2:37:53 PM 6940 (0x1B1C)

I did a quick search online and found the following post on the Technet Forums; SCEPinstall.exe fails hash check after KB2828233 Hotfix

So I checked my ccmsetup.xml (found inside the file in the Client folder) file to see if this was it;

<Item FileName="SCEPInstall.exe" FileHash="495B488FFCEE7C2D682AC6ABFC62D7F9CCB15E22911BA2B76C41307343E617CC" KeepAfterExit="true">
<Applicability Platform="ALL" OS="ALL"/>  
<Discovery Type="File" Identifier="%windir%\ccmsetup\SCEPInstall.exe" VerifyHash="true">
<Property Name="Version" Operator="&gt;=">4.1.522.0</Property>
<Installation Order="17" InstallationType="NONE"/>

The file in my Client folder is the following and check the dates;


So I decide to try the fix from the forum post and uninstalls the KB2828233 hotfix and then I rename the file in the Client folder to ccmsetup.bak and install the KB2828233 hotfix again, after the installation a new is created. (Note the date on this file in the screenshot below)


I check the ccmsetup.xml again inside this newly created file and this is now what I see;

<Item FileName="SCEPInstall.exe" FileHash="EEBF8FBE6920D51B2728DE6303457F25DE302C1E3A5742ED175D281CAEC276BD" KeepAfterExit="true">
<Applicability Platform="ALL" OS="ALL"/>
<Discovery Type="File" Identifier="%windir%\ccmsetup\SCEPInstall.exe" VerifyHash="true">
<Property Name="Version" Operator="&gt;="></Property>
<Installation Order="17" InstallationType="NONE"/>

As you see the FileHash and Version is now updated to the correct values.

So I update the Client Package so it sends the new bits to the distribution point and starts a new OSD, and now everything completes successfully and the SCEP 2012 version installed is version

The reason that this happened in the first place is described in the article and this is why the dates on the files are important;

We installed SCCM 2012 SP1 PRIOR to the refreshed source code that contained the updated version of microsoftpolicyplatformsetup.msi, so we had already installed “KB2801987 – Installation error 0x800b0101: System Center 2012 Configuration Manager Service Pack 1 client” on the site server to fix this problem; this hotfix update the date on the file to 11.01.2013, so then when I installed KB2828233, the was not updated since it had a newer date than the one in the hotfix. You see this after I re-install the hotfix after renaming to .bak and the is installed from the hotfix, the date now is 20.12.2012 and contains the correct Hash for SCEPInstall.exe.

Spent a lot of time with this issue before I figured it out so hopefully this will assist someone else getting this issue too and a big thank you to William Bracken who posted the solution on the Technet Forums.

I’m currently working on a Configuration Manager 2012 SP1 deployment for a customer and they wanted to be able to take out reports on warranty information on their Lenovo machines. I did a search to see what’s out there, but could not find anything for Lenovo machines that actually stored the Warranty Information in SCCM. I however found a lot of reports that would include a link to the Lenovo website so you could go out and check warranty information for that specific computer, but that’s not what we wanted, we wanted to be able to generate reports based of data stored in SCCM.

I found a nice blog post that Eric Schloss wrote that does the exact ting I want for HP machines. So we ended up creating a script based on the script in the article above, but modified it to use the Lenovo Warranty website and the information needed for Lenovo machines.

There is one thing to be aware of before we begin. This process is dependent on the output from a Lenovo web site. If Lenovo updates the format of the output from the site, it could affect the processing of the data.

To describe the process of how this works in short:

  1. Run the script on the computer to pull the warranty information and store it in the registry (We included the script to run in the Task Sequence when we deploy machines, but you could also run this as an application or program to already installed computers)
  2. Modify Configuration.mof and add the Hardware Inventory Classes
  3. Create a report that uses the information collected through Hardware Inventory

You can download the script here;

The script logs its results to C:\Windows\Temp\WarrantyInfo.log


And the information is stored in the registry.


To extend the inventory of the registry, there is a great tool (RegKeyToMOFv31.exe) to download from here

Start the tool and select the registry keys you would like to add to the inventory.

Copy the syntax from the tool and paste into the “Added extensions” section of the configuration.mof located on the SCCM primary server install directory\Microsoft Configuration Manager\inboxes\clifiles.src\hinv (make a copy of the original file before you edit and save it).

Select the “to import in Admin/Agent settings….” tab of the tool and save the information to a .mof file.

After that go to the SCCM console, Administration -> Client Settings -> Hardware Inventory -> Set Classes and then click Import..

Select the file you just created and verify that the new classes are added.

Run a hardware inventory action on a client and verify that the new registry values are added to the inventory.


Now that the information is added to the inventory you can start to create reports that leverage this information, below is a basic report to give you an idea of what this could look like;


Update 1:

I’ve been contacted regarding the script that Eric Schloss have on his site for HP machines on his site, because that script is not working anymore. The reason for that is that HP has changed the Warranty lookup website since that article was published.

So I’ve also made a updated script for HP machines available that you can grab here;

Update 2:

I’ve also been asked if I could share the sample report from the posting, so I’ve made the query available for download here; ReportQuery.txt

This is a bit modified from the sample included in the original post and here is a screenshot for that. (The modification will make it easier to create pie-charts etc.

You’ll need to update the query to match your tables/views for this query to work, this is the name of the view used for Warranty Information in my setup so you must change this to match your setup; dbo.v_GS_WarrantyInformation0

The code will provide you with the table and then you can use information from there to build pie-charts etc.