Jump to content

Recommended Posts

Hi everyone. I'm hoping someone out there can assist. Sorry for the length post but my aim is to provide as much information as possible to eliminate any of the common gotchas.

ConfigMgr is 1702 with latest Hotfix

I've spent the better part of two weeks trying to figure out why OSD has all of a suddenly stopped working. It seems to have happened around the same we upgraded our last DC from server 2012 to 2016 (swing migration) and raised the domain fictional level from 2012 to 2016. From the many hours spent doing google kung fu, ConfigMrg should not have any issues working in 2016 etc. DNS, DHCP AD are all reporting healthy with the usual couple of things that we can ignore from the BPA (Best Practices Analyzer).

How we do OSD:

We exclusively image Unknown Computers and have done so for many years (Since 2012 R2). We do not image our machines using deployments to any other collection. We delete the computer from the SCCM DB when we need to re-image. This works well for us in our environment. :-) All Task Sequences are deployed to the Unknown Computer collection. We are using ADK 1703 (the most recent one with all bug fixes) and boot boot x86 and x64 boot images are distributed and enabled but we only use the x64 boot image.

The issue:

Machines can successfully PXE Boot into WinPE, all machines no matter make, model, physical or virtual) all get an IP address and we can ping the ConfigMrg server without any issues. Once a computer gets into WinPE the screen goes blank and the computer reboots straight away.

Actions taken so far:

Common gotchas I have checked:

  • Checked the date and time are correct on the client
  • Made sure to delete any unknown computers or any references to the machines I have been using for testing or imaging in general
  • Thinking that it might possibly be a Boot Image/PXE related issue I followed a couple of very detailed guides online and removed the PXE role from the Distributions Points by:
    • Unticking it from each DP, deleting the files in the Windows Temp folder, deleting the RemoteInstall folder, removing the Boot images from DP's, the usual reboots, checking logs, re-enabling the PXE roll on DP's rebuilding the Boot images, deploying the boot images, enabling the both x86 and x64 boot images, making sure that my Task Sequences were referencing the newly created boot images.
  • I then booted a machine up (in this case a test VM) and pressed F8, I ran cmtrace and opened up X:Windows\Temp\SMSTSLog\smsts.log. 
    Then I found this error message:

There are no task sequences available to this computer.. Please ensure you have at least one task sequence advertised to this computer.
Unspecified error (Error: 80004005; Source: Windows)    TSPxe    12/07/2017 12:28:40 PM    1284 (0x0504)

  • So I thought perhaps my Task Sequence deployments themselves might have some issue on the DP's. I tried redeploying the task sequences and creating a brad new Task Sequence to test and I still got the same error.
  • I checked the boundary groups and Active Directory Sites and Services and everything looks fine. I tried initiating a discovery of everything possible.

Here is an example screen capture video of the issue we are experiencing:

Looking forward to any comments below!


Share this post

Link to post
Share on other sites

Hi Grudd,

I found the solution to my problem over on my post on the SCCM Subreddit page!: The logs didn't show any issues anyway :-(

Thanks to Padgo I found one entry in the x64 area that was the culprit! So I deleted it and now everything works!
What is strange about this is we have the most current 1702 Hotfix Rollup (KB4019926) applied which is supposed to fixed this issue... I'm doing some more investigation and testing to see if the issue reoccurs.

To fix it, I had to run a couple of SQL queries to find a stuck record in the ConfigMrg database and then delete it.

In the meantime, here are the screenshots and steps I followed:

Disclaimer: Cation should always be exercised when editing the SCCM/ConfigMrg database directly and you should always have a working backup regardless of these steps. I am not responsible for any damage that may caused when doing these steps!

Finding the ID's of the Unknown Computers (x86 & x64):
(You need to copy value from the SMS_Unique_Identifier0 field for each record and run it for each Unknown computer type (x86 & x64)



This is the entry (the culprit) that I found (this will be different/unique in every environment )
Copy the value as mentioned about and run it against each value and see if you get a result. If you get a result, it means that you have a stuck record. if not than it might be a more common problem/gotcha as i mentioned in my original post above.


In my case I did have a returned vaule so I went about deleting it. This is how I deleted the entry:


Note: its worth running the select unknown machines (built in) query as shown here at the top of this image to confirm that everything is still in order.



I will continue to test by imaging a handful of machines and try deleting them afterwards to see if the issue still occurs.
As for why it happened, I'm not exactly sure but when I checked with the other guys in my department, apparently that machine went flat during imaging (laptop).
This has been an excellent learning curve and I will document this one in length in case it happens again in the future.


  • Like 1

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...