ConfigMgr CB 1702 Unknown Computer Support reports ‘there are no task sequences available to this computer’

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.

smstslog1 - ConfigMgr CB 1702 Unknown Computer Support reports 'there are no task sequences available to this computer'

‘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

select * from UnknownSystem_DISC
UnknownSystemUID - ConfigMgr CB 1702 Unknown Computer Support reports 'there are no task sequences available to this computer'

Obtain the SMSUID for the x64 Unknown Computer object

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

select * from System_DISC where SMS_Unique_Identifier0 like '32c7eedc-1497-4fe3-b3ad-6cb5b55b2bb3'

We can see that another computer object has this SMSUID!

VN DP1HTZ1 - ConfigMgr CB 1702 Unknown Computer Support reports 'there are no task sequences available to this computer'

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

https://support.microsoft.com/en-au/help/4019926/update-rollup-for-system-center-configuration-manager-current-branch-v

Hope this helps!

Sam

Microsoft security updates you need to deploy now

Microsoft issued for what was described as the “worst Windows remote code exec (execution exploit) in recent memory.” The severe vulnerability in Windows Defender allows an attacker to take over an entire machine without  any user interaction.

Hours after this out-of-band emergency patch, Microsoft released its monthly “Patch Tuesday” updates.

The remote code execution flaw (assigned as CVE-2017-0290 by Microsoft in its security advisory) could allow an attacker to remotely execute malicious code and take over an entire machine.

May’s updates also include three other zero-day fixes. It’s important that you update your Windows machines as soon as you can.

Other Zero-day fixes

The first vulnerability (CVE-2017-0261) is a remote code bug that affects Microsoft Office. With this exploit, an attacker can send or trick victims into viewing a poisoned graphics file to take over their machines. Microsoft stated that they have received reports of limited targeted attacks using this flaw.

The next vulnerability (CVE-2017-0263) is an elevation of privilege flaw that allows any logged-in user to take control of a machine by running a specially crafted application. According to Microsoft, this flaw was exploited in the wild.

The third vulnerability (CVE-2017-0222) is another remote code execution weakness, this time in Internet Explorer. This flaw can be triggered with a specially crafted website causing Internet Explorer to improperly access objects in memory. Microsoft stated that this issue was also exploited in the wild.

 

WannaCry ransomware & SecurityUpdate for Microsoft Windows SMB Server (4013389)

wannacry

WannaCry ransomware outbreak as of 13/05/2017

For organisations around the world that have been hit with the WannaCry ransomware,  its leveraging a flaw in Microsoft’s Windows SMB service. The critical vulnerability was patched by Microsoft on March 14, MS17-010.

Uninstalling the Windows ADK 8.1 causes adksetup.exe to crash

During a recent ConfigMgr 1511 to 1606 site upgrade, we updated the Windows ADK for Windows 10 from version 1511 to version 1607 prior to upgrading the Primary Site server. Prior to performing this change, we found that the Windows ADK 8.1 was still installed on the Primary Site server and decided to uninstall it as only the Windows ADK for Windows 10 1607 is required.

During the removal process of the Windows ADK for Windows 8.1, adksetup.exe crashed during the uninstall of the Windows Preinstallation Environment component.

Windows ADK

Examining event viewer on the server showed the faulting application.

Event Viewer

Additionally, examining the ADK logs in the logged on user’s temp folder showed that the adksetup.exe errored with ‘failed to plan dependency actions to unregister package’

adklog 1024x230 - Uninstalling the Windows ADK 8.1 causes adksetup.exe to crash

Fortunately, the solution was fairly straight forward; reinstalling the Windows ADK 8.1 caused all installed components to re-register and after the process completed, we were able to successfully uninstall it!

Cheers

Sam

ConfigMgr 1511 Prerequisite Check errors with “Check for incompatible collection references”

During a recent ConfigMgr 2012 R2 to ConfigMgr 1511 Primary Site upgrade, the setup prerequisite check returned an error stating to “Check for incompatible collection references”

SCCM Prereq CheckExamining ConfigMgrPrereq.log showed that there was collection mismatch dependency for the “Application Catalog” collection.

SCCM Prereq Check 2

SCCM Prereq Check 2

Reviewing this user collection in the ConfigMgr console showed that it had the All Systems collection (which is a device collection) as the limiting collection. So this mismatch in collection types was causing the issue and I suspect this had been created via an incorrectly configured PowerShell script.

SCCM Prereq Check 3

SCCM Prereq Check 3

Fortunately the fix was simple and after changing the limiting collection to All Users, the error disappeared from the prerequisite check and the upgrade completed successfully!

Cheers

Sam

Unable to open Microsoft Edge in Windows 10

I had an issue for a customer this week where Microsoft Edge had suddenly disappeared from their machine.

Running the Get-AppxPackage PowerShell cmdlet confirmed that the universal application was still installed on the machine:

Get-AppxPackage | where Name -like *MicrosoftEdge*

msedge 1 - Unable to open Microsoft Edge in Windows 10

So Microsoft Edge was still on the machine and fortunately PowerShell came to the rescue.

Get-AppXPackage -AllUsers -Name Microsoft.MicrosoftEdge | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" -Verbose}

msedge 2 1024x249 - Unable to open Microsoft Edge in Windows 10

This successfully reinstalled Microsoft Edge and restored it’s functionality!

Cheers

Sam