Software updates that breaks your OS deployment process

From time to time Microsoft releases updates that requires multiple reboots. This would normally not be an issue for a device. But if you are deploying operating systems with ConfigMgr these updates will break your deployment process because the task sequence cannot handle more than a single reboot. To work around that issue you need to exclude a bunch of updates deployed to your OS deployment collections.

All the update should be documented by Microsoft in KB2894518 http://support.microsoft.com/kb/2894518 However, the June 2014 updates also included an update that requires multiple reboots, but it is not yet documented in KB2894518.

Currently the updates that you need to exclude are:

2862330 MS13-081: Description of the security update for 2862330: October 8, 2013

2771431 A servicing stack update is available for Windows 8 and Windows Server 2012

2871777 A servicing stack update is available for Windows RT, Windows 8, and Windows Server 2012: September 2013

2821895 A servicing stack update is available for Windows RT and Windows 8: June 2013

2545698 Text in some core fonts appears blurred in Internet Explorer 9 on a computer that is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2

2529073 Binary files in some USB drivers are not updated after you install Windows 7 SP1 or Windows Server 2008 R2 SP1

2871690 Microsoft security advisory: Update to revoke noncompliant UEFI boot loader modules

2965788 Description of the security update for Remote Desktop Security Release for Windows: June 10, 2014

2984976 This Remote Desktop Protocol (RDP) 8.0 update enables the Remote Desktop Connection client to perform restricted administration logons. It also enables the Remote Desktop Service that is running the RDP 8.0 host to perform restricted administration: October 20, 2014

Posted in Operating System Deployment | Leave a comment

Unable to PXE boot unknown computer after TFTP transfer error

You might have seen screens like this when PXE booting.

PXEError

It can be quite annoying, especially if it was an unknown computer running from a required task sequence deployment. When this happens you will not be able to PXE boot the computer again, there are to possible scenarios why:

Scenario 1:

Sometimes SCCM creates an Unknown computer object which can be deleted as described in Lars Lohmann Blem’s blog here.

Scenario 2:

At other times the computer object is not created in SCCM and you will not be able to PXE boot it Again, Lars Lohmann Blem also describes the issue on his blog here.

I guess scenario 1 is pretty obvious, delete the Unknown computer object and your computer will PXE boot again.

Scenario 2 is a bit more complicated. I created a small SQL query to list the computers that are unknown but is denied PXE due to the “Last PXE Advertisement” flag.

Run the following query on the SCCM database

select * from LastPXEAdvertisement
left outer join v_R_System
on LastPXEAdvertisement.SMBIOS_GUID = v_R_System.SMBIOS_GUID0
WHERE v_R_System.SMBIOS_GUID0 IS null

You will probably find your computers BIOS GUID and MAC address in the returned data. If you are up for it, delete the row and you should be able to PXE boot the computer Again.

IMPORTANT: This is probably not supported by Microsoft

To delete a row use the following:

This query will list the row you want to delete, it is always a good idea to verify that it is the correct row before actually deleting it. The query should return the row you want to delete.

select * FROM <SCCM DATABASE NAME>.dbo.LastPXEAdvertisement
WHERE SMBIOS_GUID = '<COMPUTER BIOS GUID>'

To delete the row use the following

DELETE FROM <SCCM DATABASE NAME>.dbo.LastPXEAdvertisement
WHERE SMBIOS_GUID = '<COMPUTER BIOS GUID>'

This will verify that the row has been deleted, should return 0 rows

select * FROM <SCCM DATABASE NAME>.dbo.LastPXEAdvertisement
WHERE SMBIOS_GUID = '<COMPUTER BIOS GUID>'

 

 

 

Posted in Operating System Deployment, SCCM 2012 | Leave a comment

Extending the hardware inventory in ConfigMgr 2012

From time to time I need to extend the hardware inventory collected from servers and clients. In this post I’ll try to explain how to configure the hardware inventory to pick up data from a registry key.

I created the following key on a Lab computer for testing purposes.

[HKEY_LOCAL_MACHINE\SOFTWARE\TheSheep]

“What does the sheep say”=”baaaaaaaaaaah”

To create the mof extention I usually use this awesome tool: http://myitforum.com/cs2/files/folders/proddocs/entry152945.aspx

The mof ended up looking like this (note: This is not the default output from the tool)

 #pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("TheSheep", NOFAIL)
[DYNPROPS]
Class TheSheep
{
[key] string Name;
String Value;
};

[DYNPROPS]
Instance of TheSheep
{
Name="What does the sheep say";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\TheSheep|What does the sheep say"),Dynamic,Provider("RegPropProv")] Value;
};

Download the configuration.mof file to a test computer. The file is located in <ConfigMgr install directory>\inboxes\clifiles.src\hinv) on your primary site server, add the mof extension to the bottom of the configuration.mof file.

//========================
// Added extensions start
//========================

<MOF EXTENTION GOES HERE>

//========================
// Added extensions end
//========================

Compile the configuration.mof file on your test computer by opening an elevated command prompt and typing:

Mofcomp.exe <Path to configuration.mof>

In the SCCM console go to your client policies and select hardware inventory, then click the Set Classes button.

Click the add button

Connect to the test computer where you just compiled your custom configuration.mof file.
Then select the class you would like to pick up with your hardware inventory. Click ok to save your changes
.

Go to your test computer with the custom configuration.mof then run the following from the ConfigMgr agent:

  1. Machine policy retrieval and evaluation cycle
  2. Run Hardware inventory cycle

Look in the InventoryAgent.log to see if your new class is beeing picked up by the hardware inventory cycle.

When the inventory process has finished look in the dataldr.log on your primary site server to see if the inventory data was successfully uploaded.

You should now see your custom class in the resource Explorer for your test computer