One of our customers is having an issue with ConfigMgr Current Branch 1702 where the Task Sequence engine is reporting ‘there are no task sequences available to this computer’ when using Unknown Computer Support.

‘There are no task sequences available to this computer’ when using Unknown Computer Support

According to this post on Reddit, Microsoft is aware of a known bug in 1702 where the SMSUID of the x64 Unknown Computer object is assigned to another computer object, rather than it generating a new SMSUID.

We can verify that this is the case in SQL by running the following commands

[sql]select * from UnknownSystem_DISC[/sql]

Obtain the SMSUID for the x64 Unknown Computer object

We can then run the following query to locate the computer object using this SMSUID.

[sql]select * from System_DISC where SMS_Unique_Identifier0 like ’32c7eedc-1497-4fe3-b3ad-6cb5b55b2bb3′[/sql]

We can see that another computer object has this SMSUID!

This computer object has the x64 Unknown Computer SMSUID

Therefore we receive ‘there are no task sequences available to this computer’ as the Task Sequence engine processing assigned Task Sequence deployments for that machine.

The post includes a permanent fix and states that Microsoft will be releasing a hotfix for 1702 to address this issue which I recommend waiting for. For now we have a few options:

1. Pre-stage the computer object (using Import-CMComputerInformation cmdlet) so that we’re building using known objects only
2. Delete the computer object that has the same SMSUID as the x64 Unknown Computer object, delete SMSCFG.ini on the machine and restart ccmexec to generate a new SMSUID.

Update 07/06/2017

Microsoft have fixed this issue in an update rollup released for ConfigMgr CB 1702

Update 29/10/2020

We’ve had one of our customers report that this issue has resurfaced, however they’re running release 1910. So just a heads up that this issue might still appear from time to time!

Hope this helps!


Published On: May 25th, 2017 / Categories: ConfigMgr, Notes from the field /


  1. Michael Smith 16 June, 2017 at 12:05 pm - Reply

    Hi there – I just applied this update rollup yesterday, and only now am I experiencing this issue with unknown computer support. Any suggestions?

  2. Syparon 22 June, 2017 at 4:58 pm - Reply

    Great article thx !

  3. StarTrekFace 28 June, 2017 at 7:32 am - Reply

    Around two weeks after applying the 1702 update rollup referenced above (4019926) I saw this issue for the first time today after I used the Back button during OSD. I suspect the issue was not resolved in 4019926.

    I used your Option #2 to ‘fix’ this and told everyone to not use the Back button anymore. Seems to be working okay for now.

    • Vladimir 26 July, 2017 at 9:21 pm - Reply

      Have same issue, 4019926 installed but after using the back button for the first time its now screwed up.
      moreover running the ” select * from System_DISC where SMS_Unique_Identifier0 like ‘%SMSUID%’ ” gives me the name of the machines that have SMSUID, but …. if i delete the machine from SCCM Console … the record is still there ffs.

      Should I be doing the “Delete the computer object that has the same SMSUID as the x64 Unknown Computer object” in some special way ?

      • Sam Lewis 27 July, 2017 at 10:56 am - Reply

        Deleting the object from the console should result in the object deletion from the database. Alternatively you could use PowerShell to do this, something like ‘Remove-CMDevice -ResourceID (Get-CMDevice | where Name -eq ‘ ‘).ResourceID -Force’

        Did you update your boot images after applying the fix? I haven’t seen the issue return after doing this.

  4. Lane 20 July, 2017 at 5:03 am - Reply

    This was HUGE! I came across this article yesterday and skipped it thinking it didn’t apply to our particular issue. After going through every article on Googles first page, SCCM sub-Reddit, and more, I finally came across this article again but this time with the intention of following it. After running the discovery task, it turns out there was a duplicate GUID of a machine that had previously been imaged and deployed that was conflicting with our unknown computers collection. Once I deleted the duplicate record, deleted the smsconfg.ini, I am now able to image! Thank you so much for this article!

    • Sam Lewis 20 July, 2017 at 7:38 am - Reply

      No worries! Don’t forget to update your boot images after applying the fix!

  5. Pedro Roeseler 5 August, 2017 at 12:16 am - Reply

    Hi everyone.

    Just to add that I had a similar problem but step #2 was not enough. I also needed to delete the conflicting machine from the SQL table, like demonstrated here:

    Hope it helps someone.


    • Sam Lewis 5 August, 2017 at 8:21 am - Reply

      Thanks Pedro!

  6. Bryan Dam 27 October, 2017 at 12:08 am - Reply

    Below is a WQL query that can be used to detect this issue. If any results are found, you have a problem.
    Also, don’t forget to re-create your boot images after the hotfix … I missed that one.

    Select SMS_R_System.ResourceID, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier
    From SMS_R_System
    Join SMS_R_UnknownSystem
    On SMS_R_System.SMSUniqueIdentifier = SMS_R_UnknownSystem.SMSUniqueIdentifier

  7. Deepak Rai 2 July, 2020 at 12:30 pm - Reply

    This is very good information and saved me a lot of time. Thank you so much.

Leave A Comment

Subscribe to Receive the Latest Updates

Get our latest recommendations, advice and offers direct to your inbox.

We won’t share your details – but you can read more in our Privacy Policy.