ConfigMgr OSD taking hours to complete due to LEDBAT misconfiguration

Hi All

I recently had a customer report that their Windows 10 deployment was taking 7+ hours to complete at one of their remote sites. After confirming that the machine was pulling content from it’s local Distribution Point, I started looking at the server itself, which is running Windows Server 2016.

The customer mentioned to me that they had enabled LEDBAT on this Distribution Point via the ConfigMgr console, and had then disabled it after hearing reports of OSD issues at this site.

I came across this article which stated that a misconfiguration of LEDBAT could cause slow download speeds when pulling content from a Distribution Point, so I decided to double check that this wasn’t the case. Instead I found that there were still traces of incorrect LEDBAT configuration on this server even though it had been disabled via the ConfigMgr console.

LEDBAT - ConfigMgr OSD taking hours to complete due to LEDBAT misconfiguration

LEDBAT misconfiguration

After running the following PowerShell command to remove this configuration, and then confirming it no longer existed, build times returned to normal!

Remove-NetTransportFilter -SettingName DatacenterCustom

Note that the Primary Site server has the latest 1806 update rollup installed which has fixes for LEDBAT configuration issues, however I am not sure if it was installed after LEDBAT had been enabled on this Distribution Point.

So if you hear that deployments are taking a long time to complete, check that LEDBAT misconfiguration isn’t causing the problem!

Hope this helps!

Cheers

Sam

ConfigMgr Client installation issues in HTTPS environment

Hi All

I just completed a new SCCM Primary Site installation for a customer who has a requirement of HTTPS communication only.

Symptoms

After installing 1806 and configuring certificates, I started having issues with installing clients. Here are some of the errors I was seeing in ccmsetup.log:

  • Failed to get client version for sending state messages. Error 0x8004100e.
  • Failed to get client certificate for transportation. Error 0x87d00282.
  • There are at least 2 certificates valid for ConfigMgr usage that meet the selection criteria. The ‘Select First Certificate’ registry entry was set to OFF so a certificate cannot be selected.

Failed Client install - ConfigMgr Client installation issues in HTTPS environment

That last point is where I focused my troubleshooting efforts on.

From previous experience, I know that I should check client certificate selection settings to confirm that the client should select the certificate with the longest validity period.

Client Certificate Selection Settings - ConfigMgr Client installation issues in HTTPS environment

This setting is correct and has been for quite some time so I know that the client is ignoring this, or not getting the correct information.

I also know that there are a few switches I can try during installation:

  • CCMFIRSTCERT (Tells SCCM to use the certificate with the longest validity period).
  • CCMCERTID (Tells SCCM to use a specific certificate based on thumbprint).

ccmsetup.exe /UsePKICert /NoCRLCheck CCMFIRSTCERT=1 SMSSITECODE=P01 CCMCERTID=”MY;D29211C57353FB9FB8944AFF6C14770D9AD4D58C”.

Looking at the logs I can see that the switches have been accepted and the client should be doing the right thing, but unfortunately, it still presents the same errors.

Solution

Looking at registry settings from other clients that use HTTPS and are working I can see the following Dword.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security\Select First Certificate = 1.

Select First Certificate - ConfigMgr Client installation issues in HTTPS environment

Manually creating this registry key works and the client is now able to communicate with the MP.

Notes

This is the first site we have seen this issue on, but it is also the first 1806 environment in HTTPS only. it is unclear if the problem is 1806 related or just a one-off for this client

Hope this helps!

Cheers

Liam

ConfigMgr Software Center crashing with “SCClient has stopped working” on Windows 10

During a recent Windows 10 SOE engagement, our customer reported that the ConfigMgr Software Center would crash a few minutes after opening it with the error “SCClient has stopped working”.

SCClient 300x148 - ConfigMgr Software Center crashing with "SCClient has stopped working" on Windows 10

“SCClient has stopped working” would appear several minutes after launching Software Center

Upon investigation it turns out that other applications, such as the PowerShell ISE, were also randomly crashing with the same issue. The Application Event Log pointed towards .NET Runtime, however the issue was only happening on a specific model (the HP EliteDesk 800 G1) – other hardware models running the same Windows 10 SOE were fine.

eventvwr 300x232 - ConfigMgr Software Center crashing with "SCClient has stopped working" on Windows 10

Application log was showing .NET Runtime errors

So it was a hardware specific issue and fortunately it turned out to be a simple solution – the ‘latest’ graphics provided by HP for the Intel HD Graphics 4600 graphics card, which was several years old, was causing the issue. Updating the driver to the latest release from Intel’s website, which had been released in early this year, fixed the problem!

Hope this helps!

Cheers

Sam

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