Weird Issue with Device Reimage - DELL Alienware Aurora Devices

[coolsport00]

Hey gang -

We just got new DELL Alienware gaming devices to disperse to high schools for gaming sports. Had to tweak things in our OSD Task Sequencing to get these to image properly due to having 2 disks (1 PCIe and 1 HDD; they were 'backwards' as far as Disk 0 & Disk 1 goes. Disk 0 is the HDD and we need the OS deployed on the PCIe). Anyway, got that sorted ok. Was able to get these imaged and settings deployed fine. But, one thing happened during my OSD testing. I can get these devices imaged, but when reimaging (which, will need to happen come next school yr), to be able to reimage, I have to delete the Alienware device from Config Manager. If I don't, after getting into the Windows PE for imaging, I enter all the settings and the computer just reboots and goes back into the OS...it doesn't 'see' the Task Sequence for OSD. I spent a wk researching why this was & found nothing. I can reimage any and all other device types (from HP to Lenovo to other DELLs) just fine without having to delete them from SCCM. Just these Alienware devices require deletion. The smsts log has no error in it to even troubleshoot why. Any of you all have any ideas why this behavior occurs?

Thanks in advance.

Shane (@coolsport00)

[anyweb]

it's protection, if you want to re-image the same device just re-deploy the same task sequence to it (in another collection for example), <OR> if you don't care about the history of the device, delete the device record in ConfigMgr Assets and Compliance and try again

[coolsport00]

Hey there "anyweb"...thanks for again for the response! Respectfully, I don't believe that is the case (protection), as I can reimage any and all other devices without issue or having to delete devices before doing so. There has to be a concrete reason for this. And it isn't "duplicate device" issue obviously since these devices are new, as I've seen in some posts while researching on this. Sure, I can delete the device out so I can reimage, but I shouldn't have to, like I don't have to for all other devices. It's annoying  

And, let me be a bit more detailed. We use UI++ with our boot imaging. A former co-worker set this up. I'm not completely clear on how it works, tbh. From what I can tell, it's just used in the PE part of OSD since it's set up in the Customization tab of the Boot Image; then, regular SCCM Task Sequencing takes over during OSD. When performing an OSD, I can get into the UI++ PE ok. I select my options and provide credentials to image, then when I hit Ok to begin, the dekstop just reboots. It doesn't start the Task Sequencing. In looking at the log again, I see a couple statements of interest -> "Provided preferred deployment NK120015 is not found among the available deployment"; also, "There are no task sequences available to this computer. Please ensure you have at least one task sequence deployed to this computer." ...and there obviously is a TS available. Then another msg -> "Failed to run from PXE in WinPE.... Exiting with return code 0x80004005". So maybe it seems for reimaging, a TS can't be found for the devices; yet, initial imaging it can? That's weird. I attached the smsts.log file for review, if interested.

Thanks again.

Cheers!

smsts-alienware-18oct.log

[anyweb]

if you look at your task sequence and click on the deployments tab, check what collections is it deployed to,

if your computer isn't in one of those collections then it won't see the task sequence, if your computer is in a collection targeted by the task sequence them and has been imaged before it won't re run the task sequence unless it's re-deployed to that device or the device deleted

regarding the front end you are using, it's probably trying to run a deployment using direct membership (adding a device record to a collection that the task sequence is deployed to), can you confirm that ? if so, verify if your computers record is in that collection (or not...)

[coolsport00]

After re-reviewing the log file earlier, I had the same thought regarding the Collection it uses. But, I have some confusion here. The new devices are obviously not in SCCM & thus not in a Collection initially, yet are able to image fine. But, after the image is deployed, the devices are in SCCM (SCCM client does get installed) but not in a Collection. This may be the issue. I agree with you though...I do think somehow, based off what the log is saying, a Collection..or the lack thereof for the devices...is what the issue is. The Task Sequence is assigned to a custom Collection called "OSD - All Sytems (Excluding Servers)". Keep in mind, I didn't create, design, or administer our SCCM environment until a few mos ago. I'm still learning it all. I wish my former co-worker didn't institue UI++ into the mix, adding a layer of complexity I don't think was needed. But, it is what it is. Anyway, this Collection includes some of the System Collections - All Systems, All Unknowns, and 1 Direct computer (not sure what it is; then, it excludes MACs and Servers.

[coolsport00]

Sorry for the delayed response "anyweb". I looked further into the Collections and the one assigned to the TS. These new systems, after the initial image, do indeed get added to the Collection which is assigned to the TS. So, I'm now stuck again. I am now leaning towards believing the issue has something to do with the disks in these devices. The 2 disks, a HDD and PCIe, are "backwards" as far as disk numbering go. Disk 0 is the HDD and Disk 1 is the PCIe and the PCIe is where we have the OS getting installed. Of course, we configured that to occur in the TS on initial install. But, in looking further at the logs, I'm noticing references to "disk D: drive" being referenced. That is the only thing different between all my other computers and these new ones. I think I'll just give up messing with it and simply delete the devices from SCCM whenever we need to image them, or maybe I'll create bootable media for them. Again..thanks for chiming in.

Cheers!

Edited December 10, 2021 by coolsport00

[anyweb]

this shouldn't cause the devices to 'not' get task sequence policy, which is essentially what is happening, i don't know enough about how your environment is setup to give conclusive proof, you could for example have some pre-start command that is running to add the computer into the collection(s) needed for UI++,. that would require further investigation from you, and maybe that pre-start (if there is one) is getting confused on these Dell computers.