Category Archives: SCCM Current Branch

SCCM 1806 – Third Party Updates Error 13875

Recently when adding a catalog to the third party software update catalogs in SCCM Current Branch 1806 and trying to synchronize, I encountered the error “Unable to create the subscription. The console failed to download <product> from <URL> because of the error code 13875. For more information, see SmsAdminUI logfile.”

tpa01

The error code 13875 means “Invalid certificate signature“. For more troubleshooting I downloaded the cab file by opening up IE and pasting in the link. Once the cab file was downloaded, I right clicked on the file then properties, clicked Digital Signatures tab:

tpa02

Then here my issue was that the certificate in the signature could not be verified. I clicked on View Certificate to view more details.

tpa03

My issue was that on the client server, it was missing some Trusted Root certificates. After these were installed the third party updates could then be synchronized to SCCM Current Branch 1806 without issues.

tpa04

Advertisements

SCCM 1806 – Third Party Updates

This post will show how you can set up Third Party Updates in SCCM Current Branch 1806 using a catalog from Patch My PC. This is a fresh lab with no certificates or GPO’s configured. We will let SCCM create the Trusted Publisher certificate and take care of it on the clients by configuring the SCCM client settings, and also use the client settings to allow signed updates from an intranet location.

The below set up has the SUP installed on the same server as my Primary Site. My SUP is configured for HTTP mode. SSL must be enabled on the SUP if it is remote. See https://docs.microsoft.com/en-us/sccm/sum/deploy-use/third-party-software-updates for further details.

First thing is to enable third party updates, and then let SCCM manage the certificate.

TPA01

Once this is done, and you sync your software update point, it will then create and install the code signing certificate. You can see this in the wsyncmgr.log

TPA02

If you open up certlm.msc you can also see the WSUS Publishers Self-signed certificate in the WSUS store.

TPA03

You can also see this certificate in the Trusted Publishers store as well.

TPA04

Once the sync has completed, you can see there is now information about the certificate in the third party updates tab of the software update point properties.

TPA05

Next we will configure third party updates in the client settings. Open up the client settings and select the software updates section, then enable third party updates. This will add a local policy to the clients to allow signed updates from an intranet location, and also install the code signing certificate into the trusted publishers store. There is no need for a GPO to do this.

TPA06

If you open gpedit.msc on a machine that has received the new policy, and go to Computer Configuration > Administrative Templates > Windows Components > Windows Update, you will see the “Allow signed updates from an intranet Microsoft update service location” is now enabled.

TPA07

If you doa gpresult /computer you can also see the local policy has set this as well.

TPA08

You can also see that the code signing certificate has been installed.

TPA09

Now we need to add our third party update catalogs. You will see in the SCCM console you can right click on Third Party Software Update Catalogs and add a new catalog. In my example I will be adding some Patch My PC catalogs and then syncing them.

TPA10

Click on View Certificate and then click OK.

TPA12

Once you have viewed the certificate you can click Next.

TPA13

Once you have added the required catalogs, you now have to subscribe to them (the catalogs will synchronize automatically every 7 days)

TPA11

Once the updates have been subscribed to, the catalog will then download. You need to do a sync to import the metadata from the WSUS database into the SCCM database.

TPA14

Once the sync has finished, go back into your SUP properties, click products, and add the product.

TPA15

Another SUP sync needs to be done for the metadata to appear.

TPA16

Once the metadata has appeared from the catalogs we have added, we need to publish them before we can deploy them. You will see the updates download in the SMS_ISVUPDATES_SYNCAGENT.log

TPA17

After the updates have been published and downloaded, we need to do another sync.

TPA18

You can see that the icon has changed from the blue metadata, to green, We can now deploy our third party updates to a collection as normal.

TPA19

On my test client, you can see that it needed some Adobe Acrobat Reader, Google Chrome, and an Oracle Java update.

TPA

The updates have installed correctly. We know that the trusted publisher certificate and the allow signed updates from the intranet settings worked successfully.

TPA21

SCCM Current Branch 1806 – Cloud Management Gateway Improvements

In the recently released version 1806 for SCCM Current Branch there have been a number of improvements to the Cloud Management Gateway (CMG). You might have noticed these in the Technical Previews. More information about  new features can be seen here https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1806

Some of the nice new features for the Cloud Management Gateway:

Download content from a CMG – You can now allow the cloud management gateway to function as a cloud distribution point. This is one less cloud service virtual machine running, which saves costs. You can now right click on your cloud management gateway, view the properties, click settings, and check the box “Allow CMG to function as a cloud distribution point and serve content from Azure storage”

cmg01

Or if you were to deploy a new CMG, you can view the checkbox below.

cmg02

Trusted root certificate isn’t required with Azure AD – In the screenshot above, you will notice that you aren’t required to provide a trusted client root certificate anymore. This isn’t required when you use Azure AD for authentication.

CMG Connection Analyzer – This was in an earlier technical preview release and will help a lot of people. The Connection Analyzer allows you to troubleshoot connecting to your CMG. In the example below I have signed in as an Azure AD user and tested the connection. This was useful after configuring “Use Configuration Manager-generated certificates for HTTP site systems” in the screenshot below. After checking that box, I was able to leave my management point in HTTP mode and allow CMG traffic, and run through the tests to confirm that everything is working fine.

cmg03

Use Configuration Manager-generated certificates for HTTP site systems – As mentioned above, this feature is awesome. After checking the box below on your site server, you can leave your management point in HTTP for cloud management gateway traffic, and not have to worry about installing PKI certificates.

cmg04

Once the checkbox above is enabled, you will see that you can enable CMG traffic on your management point in the screenshot below.

cmg05

If you also open IIS manager, you will see on the https binding that the SMS Role SSL Certificate is now selected. If you remove this certificate or change it, you will notice that the test in the Connection Analyzer above called Testing the CMG channel for management point will fail.

cmg06

You will also find a nice Cloud Management dashboard in the Monitoring node to find some stats.

cmg07

PXE – RequestMPKeyInformation: Send() failed.

I recently applied a hotfix to my SCCM Current Branch environment. When attempting to PXE boot a machine, the smspxe.log reported:

RequestMPKeyInformation: Send() failed.
PXE::MP_InitializeTransport failed; 0x80004005
PXE::MP_ReportStatus failed; 0x80070490
PXE::CPolicyProvider::InitializePerformanceCounters failed; 0x80070002
PXE::MP_LookupDevice failed; 0x80070490

PXE01

I first tried unchecking the PXE option on the distribution point to remove Windows Deployment Services and then re-enabling PXE support on the distribution point. This was the same issue.  After troubleshooting more I tried to open up http://fqdn/sms_mp/.sms_aut?mplist in IE and it displayed a 403.4 Forbidden Access error. My management point is not set to use HTTPS.

I checked the IIS logs on my management point and saw consistent 403.4 forbidden access on directories such as SMS_MP and ccm_system. In IIS on those virtual direcories, I checked the SSL Settings and noticed they were set to “Require SSL”. This is strange because my management point is in HTTP.

The fix was to uninstall the management point and then reinstall it. Keep an eye on MPSetup.log in your SCCM site server logs for when the MP has uninstalled and then re-add the role.

PXE started working again without any errors.

PXE – Not Serviced no advertisements found

When at a new client site (SCCM Current Branch 1706) and trying to PXE boot a machine by importing the client MAC address into a collection where the task sequence is deployed, the smspxe.log was showing:

,  : Not Serviced
,  : device is in the database
,  : no advertisements found

The device was in the database because I imported it as I am not using Unknown Computer support. There was an advertisement targeted to the MAC address as I deployed my task sequence to the collection which the client was a member of.

The actual issue was that the Boot Image was not distributed to the PXE server as it was a new boot image. Once the boot image was distributed the client could PXE boot without issues.

If you run into this issue, check in the console in Monitoring\Distribution Status\Content Status and make sure the Boot Image is on the PXE enabled DP’s that you are using.

Customize Software Center – SCCM 1710

Since Microsoft released SCCM Current Branch 1710, you can now add enterprise branding elements and choose to hide certain tabs in Software Center. This example will show how you can customize Software Center by deploying new custom client settings, and the user experience in a Windows 10 machine.

In the Administration section of the SCCM console, select Client Settings. You can choose to use the Default Client Settings, but I would recommend creating some new custom client settings for any tests, as the Default Client Settings apply to all machines.

custom01

Give the custom client settings a name, and select Software Center. Once you check the Software Center box, you will see the settings now appear on the top left.

custom02

I have selected Yes next to the arrow, given my company name, and also selected a custom colour scheme, and uploaded a company logo. Note that the maximum dimensions are 100×400 for the logo, and it cannot be larger than 750kb in size. Here you can also choose to hide any tabs you wish.

custom03

I will now deploy the custom settings to a collection, and then initiate a machine policy evaluation on my test client. After a few minutes, open Software Center and you will notice the new changes.

custom04

custom05

This is what my new Software Center looks like. I have not chosen to hide any tabs, but I have selected the custom image on the top left, given the company name (Nhogarth.net) and chosen the custom blue colour.

custom06

 

 

Co-management – Enabling Co-management SCCM 1710

This post will show how you can enable co-management in SCCM 1710 and how to automatically enroll a Windows 10 1709 machine into Intune (Intune standalone) when it is currently managed by SCCM 1710.

Prerequisites:

  • Configuration Manager version 1710 or later
  • Azure AD
  • EMS or Intune license for all users
  • Azure AD automatic enrollment enabled
  • Intune subscription (MDM authority in Intune set to Intune)

Suggested readings:
Co-management for Windows 10 devices
Enable Windows 10 automatic enrollment
How to configure hybrid Azure Active Directory joined devices

In portal.azure.com then Azure Active Directory, Mobility (MDM and MAM), Microsoft Intune, I have set my MDM user scope to All for automatic Intune enrollment for Windows.

intunecomgmt-17

In the SCCM console, in Administration, expand Cloud Services, right click on Co-management to create a new co-management policy.

intunecomgmt-02

Sign in with the Intune account

intunecomgmt-03

I have set automatic enrollment in Intune to pilot.

intunecomgmt-04

Configure the workloads.

intunecomgmt-05

I have created a collection called Comanagement Pilot. I have added my test Windows 10 1709 machine managed by SCCM 17010 into this collection.

intunecomgmt-06

intunecomgmt-07

You can check the Monitoring node and look for the CoMgmtSettingsPilot status. You can see my test machine WIN10MDT has successfully had the co-management policy applied.

intunecomgmt-16

Previously in the Azure Active Directory then Devices blade in portal.azure.com you can see that my Windows 10 1709 machine is Hybrid Azure AD joined but the MDM was set to none.

intunecomgmt-19

Once the policy was applied above, you can see the machine has changed from None under MDM, to Microsoft Intune.

intunecomgmt-18