Share via

Delete Behavior for Devices in ConfigMgr 2012

  • Article

I can already hear you saying it to yourself – delete behavior? Well that’s pretty simple. Deleting a device , well, deletes it!  Yes it does but there are actually some interesting details about how this works that are different in ConfigMgr 2012 and worth understanding for academic reasons and specifically when working with OSD and PXE.

An example is the best way to explain.

Assume a device has been imaged using a required deployment delivered through PXE boot in the past. The screenshot below shows the device along with the record indicating that it has been previously imaged as a result of a required PXE deployment.

clip_image002

Now it is time to reimage that device. In preparation for doing so the device is deleted from the ConfigMgr All Systems collection, either manually or through automation, but the previous PXE Deployment was NOT cleared because simply deleting it from the console is assumed to also cause any residual detail such as previous PXE deployments to also be cleared. Whether the deletion is done manually of through automation the image below confirms that the device is, indeed, removed. This means that the device has been deleted from ConfigMgr (just being Mr. Obvious here).

image

So, the device WAS deleted from the console but it was NOT actually deleted. It was simply marked as Decommissioned in the database, as shown.

clip_image005

Note: If the details of the associated view (v_r_System) are reviewed then the ‘deleted’ system will not show up but it is clearly still in the database.

The REAL deletion will happen when the Delete Aged Discovery maintenance task runs. This task is configured to run by default weekly and will cleanup entries that are greater than 90 days old. Where needed it is common to adjust the deletion interval and frequency consistent with the needs of your environment.

OK, great! So it sounds like the only repercussion of this change is that Decommissioned entries will remain in the database for up to 90 days by default? And because they are decommissioned they won’t show up in the ConfigMgr console so are not subject to management and won’t be able to be acted upon by ConfigMgr administrators? Correct to both. OK, so what’s the big deal? One thing. Remember that the system in question was imaged by a required PXE deployment. Now it’s time to re-image that system and it’s already deleted from the console. A common first step in such a scenario is to import it back into ConfigMgr.  And, it’s not uncommon to use the same system name and MAC address information. Using the Import Computer Wizard the machine is added back to ConfigMgr and the same name as previous was used.

clip_image007

With the import finished it’s time to PXE boot the system to begin the re-image process. But no matter how long you wait or how many times you try you get the same result, the system won’t PXE boot.

clip_image008

What’s going on? The reason the system fails to PXE boot is because it doesn’t find any ‘active’ deployments available to it.  So why is that?  The answer is found if we go back to the newly imported machine and look at the Clear Required PXE Deployments option. When we deleted the device from the console we have already discussed that it wasn’t truly deleted.  So, when the device is again imported into ConfigMgr, the newly added information for the device is again associated to the old information that is actually still in the database and the historical PXE boot data associated with the original device becomes associated with the newly imported device since the same MAC information was used. Note that the key here is the MAC information. If the device was imported again with a different name but with the same MAC information then the association to old data would still happen.

The solution? Make sure that before the device is deleted that an extra step is taken to Clear Required PXE Deployments as well.

Comments

  • Anonymous
    October 14, 2013
    Very well explained :-)

  • Anonymous
    January 08, 2014
    Was that behaviour different in SCCM 2007 ?

  • Anonymous
    May 20, 2014
    Thanks, this one opened up my eyes at what was the problem at the customer i'm at. Luckily they had a tool for cleaning SCCM duplicates that could be used to perform the fix here on site. Since i lack permissions to tinker in SCCM directly.