SCCM OSD PXE problems with USB Adapters

A rather annoying issue I have come across with PXE imaging on PC’s with a USB adapter is a conflict with duplicate MAC as the adapter itself has a MAC address and does not pass through from the PC itself. If you look into the SMSPXE.log this will reveal the issue

Manage duplicate hardware identifiers

Providing a list of hardware identifiers that Configuration Manager ignores for the purpose of PXE boot and client registration, helps to address two common issues.

  1. Many new devices, like the Surface Pro 3, do not include an onboard Ethernet port. Technicians use a USB-to-Ethernet adapter to establish a wired connection for purposes of operating system deployment. However, these adapters are often shared due to cost and general usability. Because the MAC address of this adapter is used to identify the device, reusing the adapter becomes problematic without additional administrator actions between each deployment. To reuse the adapter in this scenario, exclude its MAC address.
  2. While the SMBIOS attribute should be unique, some specialty hardware devices have duplicate identifiers. Exclude this duplicate identifier and rely on the unique MAC address of each device.

To add hardware identifiers for Configuration Manager to ignore

  1. In the Configuration Manager console, go to Administration > Overview > Site Configuration > Sites.
  2. On the Home tab, in the Sites group, choose Hierarchy Settings.
  3. On the Client Approval and Conflicting Records tab, choose Add in the Duplicate hardware identifiers section to add new hardware identifiers.

SCCM Cannot Disable Peer-Cache

SCCM peer cache was introduced in 1610 as a pre-release future and eventually made it into production.

As there was quite limited documentation around the feature at the time, there have been several eager admins who have likely  enabled this without understanding how it works and the consequences.

5

After disabling the feature in client settings, clients started to remove from the Super Peers list however not all.

To check the Super Peers list you will need go to the SQL database your SCCM instance is hosted on.

Select * from SuperPeers

Symptoms

The symptoms you will are slow OS deployement, slow applications download (Downloading stuck 0% for a while) from Software Center, or even when deploying updates.

CAS.log reported a long download locations list before the SCCM was even considered, so the server still reports these sources as active peer cache clients.

2

DataTransferService.log then reports a bunch of errors, because the feature is disabled on clients and content can’t be reached, then the client waits a bunch of seconds and proceeds with the next download location.

3

During OS deployment I noticed that placing a computer on the same subnet as the SCCM distribution point, it is considered first in the list, so the issue is … work-arounded?

4

Causes

I didn’t understand at first if this was BranchCache or PeerCache related. I tried a lot of things: re-enabling the feature then disable it again, changed my boundaries and boundary groups so that they are managed by IP address range, removed the “Allow clients to share content[…]” from applications (which is BranchCache related).

https://blogs.technet.microsoft.com/umairkhan/2017/06/12/configmgr-1702-the-case-of-unexplained-client-peer-cache-not-getting-disabled-even-after-disabling-it-via-client-settings/

This is the exact case. Read it, because this is gold. Even the introduction and myth-busting about BranchCache and PeerCache is worth a read.

The setting is disabled on computers, but the site server is not aware. Apparently there’s an issue when the client sends back a state message stating  to the site server, I’m not a superpeer, remove me from the list.

Verifying the WMI informations on a “guilty” computer (one of those appearing in CAS.LOG) with WMI Explorer

6

The setting is consistent with the deployed client settings. So the computer knows.

Let’s see if the client is in the “SuperPeers” table on the DB

Select * from System_DISC where Name0 like ‘ComputerName_still_in_Superpeer_list’

get the ItemKey from there, and

Select * from SuperPeers where ResourceID = ‘ItemKey’

7

8

So the client is still a SuperPeer for SCCM, and the same ResourceID also appears in SuperPeerContentMap for every application or package it is (was) able to distribute.

Select * from SuperPeerContentMap where ResourceID = ‘ItemKey’

9

So, how do we get rid of this data (which is now complete garbage, since I disabled the setting globally) ?

The Fix

As always make a backup of your database before running these commands. This will delete all the table information for Peer Cache information.

delete from SuperPeerContentMap

delete from SuperPeers

Test again from your clients to verify that everything now works!