Reusing the same NIC for multiple PXE initiated deployments in System Center Configuration Manger OSD


The solution in the below blog post is now a native feature in ConfigMgr starting in ConfigMgr Current Branch 1610. Please see the below link for further information:

Manage duplicate hardware identifiers

Consider the following scenario. You are using a single USB to Ethernet Adapter to image multiple devices via a ConfigMgr OSD Task Sequence. The USB to Ethernet Adapter is used because the devices lack a built in Ethernet port and ConfigMgr OSD does not support imaging the devices using the built in wireless NIC. As an example we are going to image several Surface Pro 3 devices using the same USB to Ethernet Adapter and started via PXE. This is a common scenario for companies running a dedicated imaging location for new devices before handing them over to their end users. Please note that this scenario could use a device similar to a USB to Ethernet adapter that provides a wired Ethernet connection such as a Surface Pro 3 Docking Station

Consider the below Surface Pro 3 (A) and Surface Pro 3 (B) have to be installed using the same Surface Ethernet Adapter. After the devices are completely installed, they will connect to corporate network via WLAN or a docking station with a built-in Gigabit Ethernet port.

Surface Ethernet Adapter

Sample MAC Address:

Surface Pro 3 (A)


Surface Pro 3 (B)



Example of a classic PXE initiated deployment with unknown computer support enabled 

Log file snippet of SMSPXE.log: This is a boot  attempt of Surface Pro 3 (B) with default Configuration Manager PXE enabled DP and Unknown Computer support enabled. Note that the lookup occurs using both the MAC and SMBIOS GUID (UUID) of the device to try to find a matching existing record. If either MAC or SMBIOS GUID(UUID) is found in the database then the device is "known".

50:1A:C5:FE:AA:8C, 11F6E606-84D1-4E74-AF7C-3B54377D15E3: device is not in the database.

In the above log, the device lookup result did not return a matching record from the database and it treats this device as "unknown".

Once the device PXE boots and enters Windows PE, the device contacts the MP and via Heartbeat Discovery, registers itself as a client with BOTH its SMBIOS GUID (UUID) and MAC Address. A new record is created with the name "unknown".

A closer look at the object in your Configuration Manager console will show that the client has been registered with its SMBIOS GUID (UUID) and MAC Address 

If multiple devices are being imaged at the same time, there may be multiple records with the name "unknown". This may make it hard to figure out which "unknown" record goes with which device. A simple WQL query will help determine what record belongs to which device.

The following WQL Statement will list all Objects Registered via Unknown Computer Support with UUID and MAC. This will make it easier to see the details of the Unknown object:

select SMS_R_System.ResourceId, SMS_R_System.Name, SMS_R_System.SMBIOSGUID, SMS_R_System.MACAddresses, SMS_R_System.AgentName, SMS_R_System.AgentTime from  SMS_R_System where SMS_R_System.Unknown = 1

Sample Query result: The Client is registered with both MAC Address and SMBIOS GUID (UUID)

The following WQL Statement can be used to find all objects with a specific MAC Address registered

select SMS_R_System.ResourceId, SMS_R_System.Name from  SMS_R_System where SMS_R_System.MACAddresses like ##PRM:SMS_R_System.MACAddresses##

The following WQL Statement can be used to find all objects with a specific SMBIOS GUID registered

select SMS_R_System.ResourceId, SMS_R_System.Name from  SMS_R_System where SMS_R_System.SMBIOSGUID like ##PRM:SMS_R_System.SMBIOSGUID##

After creating the above three WQL queries you should have the following queries:

More information about creating queries can be found at How to Create Queries in Configuration Manager.

The problem manifests itself once one device registers itself with the MAC Address of the USB to Ethernet adapter. Once a device registers itself with the MAC address of the USB to Ethernet adapter, that USB to Ethernet adapter cannot be used on additional devices to initiate a PXE boot. In order to use the USB to Ethernet Adapter on another device, you would need to disassociate that USB to Ethernet Adapter from the device that last device that successfully used the USB to Ethernet adapter. This would be done by running Hardware Inventory and Heartbeat Discovery on the device while the USB to Ethernet Adapter is not attached to the device. This additional step adds delays and additional overhead to the imaging process, especially when imaging multiple devices at once. So the question is how to use the same USB to Ethernet Adapter on multiple devices without having to wait for the device that last used the USB to Ethernet Adapter to run Hardware Inventory and Heartbeat Discovery without the USB to Ethernet Adapter attached.


The solution is very easy: Add the MAC Address of the USB to Ethernet Adapter to the list of Mac Addresses to be excluded from Data Discovery. This task has to be done on the Primary Site Server.

This can be done by opening Regedit on the site server and navigating to the following registry key:


followed by editing the registry value of:


This registry key value is a multi-string value that is the placeholder of the list of MAC addresses to be filtered. The registry key holds one MAC address per line in the following format:


All letters in each MAC address must be typed as uppercase letters to match the MAC address that is submitted in a DDR.

Make sure to add a line break at the end of each MAC address list as the cursor below shows:

otherwise you will see the following error message:


More information about this registry key can be found at

Note: By default, this registry key should exist but will be empty

Before adding any MAC addresses to this registry key value, do not forget to remove any existing object registered with those MAC addresses from the ConfigMgr console otherwise the PXE boot will not work. In this example, we would make sure to delete any objects in the ConfigMgr console that were registered with the MAC address of 50:1A:C5:FE:AA:8C.

From now on any new object will register itself ONLY with its SMBIOS GUID (UUID) when using your Ethernet Adapter(s) of choice.

Log file snippet of SMSPXE.log: Boot attempt of Surface Pro 3 (A)

Running the sample query for Unknown Computers from above we can see Surface Pro 3 (A) registered ONLY with its SMBIOS GUID (UUID). It did not register with its MAC address. In the SMSPXE.log we can see that the MAC Address is still visible


Log file snippet of SMSPXE.log: Boot attempt of Surface Pro 3 (B)

Running the sample query from above for Unknown Computers we can see Surface Pro 3 (A) and Surface Pro 3 (B) both registered ONLY with their SMBIOS GUID (UUID). Neither registered with its MAC address. Again in the SMSPXE.log we can see that the MAC Address is still visible.


Known computer support still works the same way, but instead of using MAC Addresses to import records, make sure to import records using the SMBIOS GUID (UUID).

For known computer support, import the new Record using the SMBIOS GUID (UUID) instead of the MAC address. Please note that ConfigMgr may reference the SMBIOS GUID as BIOS GUID or System UUID.

You can obtain the SMBIOS GUID from a device using any of the following methods:

  1. Via the following PowerShell command:get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

    For bare metal devices, this can be done from WinPE if the PowerShell component is added to the WinPE boot image

  2. Via the following command from a command promptwmic csproduct get UUID

    For bare metal devices, this can be done from a command prompt in WinPE

  3. Some devices will display their SMBIOS GUID in the BIOS/Firmeware. For example, on Surface Pro 3, while the device is completely powered off, hold down the Volume Up button followed by pressing the Power button. This will power on the Surface Pro 3 and display the Firmware screen. At the Firmware screen, select Device Information. This will show you the SMBIOS GUID next to the field "System UUID".
  4. The SMBIOS GUID may be displayed in the PXE boot screen, mainly on BIOS based devices

    In the above example PXE boot screen, you can see the SMBIOS GUID next to "GUID:"

  5. By monitoring the SMSPXE.log live via CMTrace while trying to PXE a device, the SMSPXE.log will show the SMBIOS GUID in the following line of the SMSPXE.log:00:15:5D:0A:49:55, 96D3D94F-2340-436A-86FE-31AA37C247E6: device is in the database.


    00:15:5D:0A:49:55, 96D3D94F-2340-436A-86FE-31AA37C247E6: device is not in the database.

To prestage the device and create a Known computer record via the SMBIOSGuid, in the Import Computer Information Wizard, add the record based on its SMBIOS GUID instead of its MAC address as shown below:

Once you complete the Import Computer Information Wizard, a Computer record will be created with the SMBIOS GUID but without the MAC address as shown below:

The Computer object will not have a MAC Address listed until the WLAN Adapter or Network Adapter other than the excluded USB to Ethernet Adapter is inventoried.

Wilhelm Kocher

Senior PFE - EMEA

Frank Rojas

Senior Support Escalation Engineer

This post is provided "AS IS" with no warranties, and confers no rights. The solution is not officially supported. Any support provided by Microsoft regarding this solution may be limited. Microsoft does not guarantee the solution will work in all environments and/or scenarios.

Comments (17)

  1. Eddie Thrace says:

    Thanks Frank. You've saved me a lot of headaches with this. Why is it not part of the official Configuration Manager documentation?

  2. Frank Rojas says:

    The feature that allows the filtering of MAC addresses for hardware inventory was not added originally to address the problem of reusing one NIC on multiple PCs. We recently came across the feature described in KB816051 and theorized that it may also help
    us with this scenario. We tested and confirmed it did resolve the issue. We decided to write this blog article until official documentation can be produced. We have filed a Design Change Request (DCR) asking that this feature be officially included in the
    product to resolve this issue, possibly through a GUI option in the ConfigMgr console.

  3. Thomas Frederiksen says:

    I cannot get this to work with PXE.
    We are prestaging all machines with a hostname and UUID.

    I added a new Surface USB to Ethernet Adapter's mac-address to the registry key, and then started PXE-booting the first pc. After imaging the first pc i plugged the USB to Ethernet Adapter into a second Surface Pro 3, but this time it won't PXE boot.
    The SMSPXE.log simply says:
    C0:33:5E:73:40:84, CE54E753-569F-E1B2-D951-6375CCAF54F5: device is in the database.
    C0:33:5E:73:40:84, CE54E753-569F-E1B2-D951-6375CCAF54F5: no advertisements found

    Using the queries in this article i can see that the MAC-address C0:33:5E:73:40:84 is not listed anywhere in SCCM. But the CE54E753-569F-E1B2-D951-6375CCAF54F5 UUID is listed on the prestaged machine that i'm trying to PXE boot. If i then try to plug another
    unused USB to Ethernet Adapter into the Surface Pro 3, then it PXE boots just fine.

    So it seems the MAC-address is cached or saved somewhere that the query does not reveal as i am still not able to use the same adapter/mac-address on two different machines.

    I also looked at the details of the first machine i imaged, and the MAC-address is not listed, only the UUID.

    Does anyone have clue how to fix this?

  4. Hi Thomas,

    you prestage your machine using Import Computer Information Wizard. Is the new created record already member of the collection where you have deployed your task sequence to? Are you importing the new record to All Systems or direct to the target collection?
    From a workflow perspective every record must be member of All Systems before the record will appear in another collection which has at minimum a limit to All Systems. This might be just a timing issue you are facing. If you right click the new record can
    you see the deployment listed before you try the PXE boot?

    The log file indicates that the device is found but no deployments (advertisements) are available for the system.

    I hope this helps!

  5. Thomas Frederiksen says:

    Yes the created record is in both All Systems and in the target collection. And yes the deployment is listed on the object.

    This is not a timing issue as i have been trying this over several days. Each time if i use an unused USB to Ethernet Adapter to PXE boot the Surface Pro 3, then it PXE boots just fine, and the log shows that it finds the advertisement. If i then reset the
    PXE flag and try again with a USB to Ethernet Adapter that was previously used to PXE boot another Surface Pro 3 (and where the MAC-address have been added to the ExcludeMACaddress registry key) it fails and the log shows that there was no advertisements found.
    This is without any changes made in SCCM.

    It is just like the ExcludeMACaddress key was not set. But when i look in SCCM i can see the effect of the ExcludeMACaddress key, as the MAC-address is not listed anywhere i SCCM.
    So i can confirm that the registry key works, the problem is that it does not work when PXE booting as the adapter can still only be used for the pc that PXE booted with the adapter the first time.

  6. Hi again,

    the only cache I have in mind right now that might have influence would be on the PXE enabled DP which caches PXE boot attempts. You can quickly clear this cache if you restart WDS Service or if you change the cache time as described in Another question: Inside the SMSPXE.LOG you should see above the log entry "device is in the database" an entry "ItemKey=" which tells us the
    devices Resource ID. Does the Resource ID match your record that you have created? I think this document "PXE Boot and System Center 2012 Configuration Manager" can help you to find the issue.


  7. Thomas Frederiksen says:

    Hi Wilhelm

    Restarting the WDS service does not solve the problem.
    The ItemKey in the logfile shows the correct Resource ID of the prestaged record in SCCM. So it is the correct record it finds in SCCM, but for some reason does not see the advertisement when using a used adapter even though the MAC address is not in the SCCM
    database as it was been excluded by the registry key.

    When restarting the WDS service i noticed the following in the SMSPXE.log:
    Cannot read the registry value of MACIgnoreListFile (00000000)
    MAC Ignore List Filename in registry is empty

    Does this have anything to do with the ExcludeMACAddress key not being read by WDS, or is this normal?

  8. Hi Thomas,

    the purpose of "ExcludeMACAddress" registry key is to not respond to PXE boot requests from devices with a MAC address listed. More information you can find at What I forgot to mention is to stop WDS Service, delete the file content of folder RemoteInstallSMSTemp
    and start the service again. I do not know your SQL skills, but in the PXE Boot document mentioned before you can find 2 stored Procedures which you can run as test to get the same output as the SMSPXE boot lookup result should be.


  9. Frank Rojas says:

    It sounds to me like another record already exists in the DB for that device. Did you check for records not only with that MAC address, but also with that SMBIOS GUID?

  10. Thomas Frederiksen says:

    Hi Will

    I have now tried to stop the WDS service, remove the content of the RemoteInstallSMSTemp folder and started the WDS service again. Sadly the issue is still the same.
    I have then tried to run the Stored Procedures specified in the PXE Boot document to see what it returns.
    The first one (exec NBS_LookupPXEDevice N'CE54E753-569F-E1B2-D951-6375CCAF54F5',N'C0:33:5E:73:40:84') correctly returns ItemKey=16778531, Unknown=0 as described in the document.
    This itemkey is the Resource ID of the prestaged object in SCCM.

    But, then when running "exec NBS_GetPXEBootAction N'16778531',N'2046820352',N'CE54E753-569F-E1B2-D951-6375CCAF54F5',N'C0:33:5E:73:40:84',N'dkvjlvir088.vejle.intern'" SQL doesn't return anything!
    If i change the MAC-address in the query to ANYTHING else than that specific MAC-address (of the already used adapter) then it correctly returns the advertisement.
    So it seems like SCCM rejects this specific MAC-address for some reason even though your SCCM query does not find any objects with this MAC-address.

    If i lookup this specific MAC-Address using the SCCM query specified in your blog, then it does not find any objects with this MAC-Address (as it is excluded through the "ExcludeMACAddress" registry key.
    If i check for the UUID/SMBIOS GUID using the SCCM query specified in this blog, only one object is returned – the prestaged computer.

    1. Andrew Blackham says:

      I thought I might chime in with the reason that no results are returned. This is because even though the MAC address is not registered against the machine entry (as documented when using ExcludeMACAddress) it is registered against the LastPXEAdvertisement which does record the MAC address. Thus when NBS_GetPXEBootAction is called it does not return anything because the MAC address has previously PXE booted.

  11. NeighborGeek says:

    I’d like a little bit of clarification, if possible. The article suggests using this registry key for Unknown Computer scenarios, but that this key is not necessary in Known Computer scenarios, such as when pre-staging a computer in Configmgr.

    If a computer is pre-staged with only the GUID, and not a MAC address, and then pxe booted using a usb ethernet adapter, doesn’t the MAC of that adapter end up being discovered and associated with client in configmgr?

    If I then move the usb adapter to another computer pre-staged by GUID only, and try to pxe boot, will configmgr see that this is a different computer, matching using the GUID and not the MAC?

    Lastly, in the comments, Wilhelm says “the purpose of “ExcludeMACAddress” registry key is to not respond to PXE boot requests from devices with a MAC address listed.” In the link he provided for more info, it appears to say that if a MAC is on the Exclude list, pxe boots attempts from that MAC will be refused. Why is it that, after adding a MAC to this list, configmgr is not refusing to pxe boot unknown clients matching that MAC? It seems as if the “purpose of ExcludeMACAddress” and supporting documentation are in direct conflict with the behavior described here when using the same excludemacaddress key. Am I misunderstanding something?

    1. Frank Rojas says:

      You are correct – the problem could also happen if you are prestaging PCs with the SMBIOS GUID. It is not necessarily limited to just unknown computers. Unfortunately even if you stage using SMBIOS GUID the issue may still occur, so you may still need to use the ExcludeMacAddress registry key and add in your shared dongles.

      Regarding Will’s comment, I think it is just a type and he meant to say “MACIgnoreListFile”, not “ExcludeMacAddress”.

  12. Nalin says:

    HI Gents,

    Thanks for this as the information is really helpful. Could you please consider an improvement on this to help us stressed out people trying to deploy hundreds of these devices ? The above is good for the odd individual deployment. Is there a way to import the devices in to SCCM using their wireless addresses and still use the Ethernet to usb adapters after adding them to the reg-key ?


    1. Frank Rojas says:

      I’m not quite sure what your ask is. The solution is for SHARED dongles. Normally you would not have hundreds of such devices. You would only have few shared across many devices and used only for the purpose of imaging PCs. Using wireless is not currently possible because WinPE does not have a wireless stack, but I don’t know how this would help you if you are still using a USB Ethernet adapter.

  13. Frank Rojas says:

    FYI, this is a feature that is being implemented directly in the ConfigMgr console and is already available in the Technical Preview versions. Please see the following UserVoice item

  14. NoDowt says:

    We took the even easier (but slightly risky) way out & just deploy our PXE OSD deployments to all systems + unknown systems. We have a password on the PXE boot to avoid accidents if boot order gets mixed up on a system.

Skip to main content