Download Window 10 Enterprise 2004 with the Media Creation Tool (including en-GB and other language versions)

The May 2020 update to Windows 10 is now available to download using the Media Creation Tool. Using the GUI, you can download the consumer ISO which contains the Home, Professional and Education SKUs of Windows 10.

If you want to download the Enterprise version of Windows 10, but don’t have access to Microsoft VLSC, Visual Studio or Action Pack subscriptions, it is possible to download it using the Media Creation Tool if you know the right command line switches.

To download Windows 10 Enterprise 2004 using the Media Creation Tool, log in with a local administrator account (for some reason it isn’t good enough to run the tool using Run as administrator, you actually do have to be logged in as an administrator) and download the tool. Open a CMD prompt, change directory to the directory you saved the Media Creation Tool in and enter the following command:

MediaCreationTool2004.exe /Eula Accept /Retail /MediaLangCode en-US /MediaArch x64 /MediaEdition Enterprise

When you’re prompted for a product key, you can use the Windows 10 Enterprise KMS client key from this site on Microsoft Docs.

This will download an ISO that contains the various Enterprise SKUs (Enterprise, Enterprise N, Education, Education N, Professional and Professional N) with en-US installed and set to default. If you’d prefer to get en-GB, use the following command:

MediaCreationTool2004.exe /Eula Accept /Retail /MediaLangCode en-GB /MediaArch x64 /MediaEdition Enterprise

This will download an ISO containing the same SKUs as above, but with en-GB installed and set to default.

As far as I can tell, this works for any of the language pack region tags listed on this site. So, for example, to download Windows 10 Enterprise 2004 with French installed and set to the default language, you can use this command:

MediaCreationTool2004.exe /Eula Accept /Retail /MediaLangCode fr-FR /MediaArch x64 /MediaEdition Enterprise

If you don’t specify the /MediaLangCode switch it will default to downloading an ISO with the same language pack as the OS you are running it from.

If you want to download the 32-bit version of Windows 10 Enterprise instead, you should change /MediaArch to x86.

When you have downloaded the ISO, you may unpack it and find that the it does not contain an install.wim, but instead contains install.esd in the sources directory. Depending on what you are doing, you may need the .wim file (for example, if you’re planning to use it with MECM/SCCM). Thankfully obtaining a .wim file from the .esd is quite straightforward using DISM.

Open a CMD prompt and use the following command (changing the path for /WimFile to match where your install.esd file is):

dism.exe /Get-WimInfo /WimFile:C:\Temp\Windows10_2004\sources\install.esd

This will list each of the SKUs in the install.esd file. Make a note of the index of the SKU you want (in my case, I want the Enterprise SKU which is index 3).

DISM Get-WimInfo

Now use the following command to create an install.wim file that contains the SKU you want:

dism.exe /Export-Image /SourceImageFile:C:\Temp\Windows10_2004\sources\install.esd /SourceIndex:3 /DestinationImageFile:C:\Temp\Windows10_2004\sources\install.wim /Compress:max /CheckIntegrity

Make sure the path for /SourceImageFile and /DestinationImageFile are correct for you and change the /SourceIndex to match the index you noted earlier.

DISM Convert ESD

Once that is done you can delete the install.esd file if you want, to save space.

Unfortunately, this version of the Media Creation Tool still has no way to get the LTSC version of Windows 10 Enterprise (as far as I can tell).

Buy Me A Coffee

Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation
Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate
Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings
Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update
Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

With all the configuration done, in this final part of the guide I am going to demonstrate how to patch Google Chrome, Adobe Acrobat Reader DC and Power BI Desktop using Ivanti Patch for SCCM.

Client preparation

For this end-to-end demonstration I have prepared a Windows 10 client running Google Chrome 75 (June 2019), Adobe Acrobat Reader 2019.008.20071 (October 2018) and Power BI Desktop (October 2019 release). I will be aiming to update all three applications using Ivanti.

Publishing the updates

Note: You may have already published Google Chrome while following the instructions in Part 4. If you did, just skim past those bits in this part.

Open the SCCM console and navigate to Software Library > Software Updates > Ivanti Patch. Search for Google Chrome, and then click on the New SmartFilter button. Fill it in with the following details:

Scope: Shared
Filter name: Google Chrome
Match all of the following rules:
Product contains Google Chrome
Is Superseded does not contain Yes

Google Chrome Smart Filter

Click Save.

Next create a smart filter for Adobe Acrobat Reader DC using the following details:

Scope: Shared
Filter name: Adobe Acrobat Reader DC
Match all of the following rules:
Product contains Adobe Acrobat Reader DC
Is Superseded does not contain Yes

Adobe Acrobat Reader DC Smart Filter

Click Save.

Finally, create a smart filter for Power BI Desktop using the following details:

Scope: Shared
Filter name: Power BI Desktop
Match all of the following rules:
Product contains Power BI Desktop
Is Superseded does not contain Yes

Power BI Desktop Smart Filter

Click Save.

With all three smart filters ready to go, click Scheduled Tasks in the ribbon. Create a new scheduled task for Google Chrome with the following details:

Description: Google Chrome
Schedule: Daily, Tuesday, 21:00:00
Publish the updates selected by this filter: Google Chrome (Shared)
Do not add updates to a Software Update group
Schedule the task to run as: Your Ivanti service account

Create Scheduled Task

Click OK to save this task.

Next, create a scheduled task for Adobe Acrobat Reader DC using the following details:

Description: Adobe Acrobat Reader DC
Schedule: Daily, Tuesday, 21:00:00
Publish the updates selected by this filter: Adobe Acrobat Reader DC (Shared)
Do not add updates to a Software Update group
Schedule the task to run as: Your Ivanti service account

Adobe Acrobat Reader DC Scheduled Task

Click OK to save this task.

Finally, create a scheduled task for Power BI Desktop using these details:

Description: Power BI Desktop
Schedule: Daily, Tuesday, 21:00:00
Publish the updates selected by this filter: Power BI Desktop (Shared)
Do not add updates to a Software Update group
Schedule the task to run as: Your Ivanti service account

Power BI Desktop Scheduled Task

Click OK to save this scheduled task.

Open Windows Task Scheduler and navigate to Task Scheduler Library > Ivanti > Patch and select each scheduled task in turn and click Run in the actions pane on the right. Switch back to Ivanti in the SCCM console and monitor the status column for each of the three products, watching as each one gets packaged and then published.

Once that is done, click Synchronize Software Updates in the ribbon and monitor the wsyncmgr.log file to see when it completes. When it has completed, click on Manage Products in the ribbon and subscribe to all three vendors.

Subscribe to all vendors

Click close, and once again click Synchronize Software Updates. This time the updates will be synchronised with SCCM and will appear in All Software Updates when the sync has completed.

Go to Automatic Deployment Rules and click Create Automatic Deployment Rule in the ribbon. I am going to create a single ADR for all third-party updates; however, you may choose to separate products out as you see fit.

Name the rule All Third-Party Updates and select the collection that contains your clients. Select to have new updates added to an existing Software Update Group each time is runs. On the search criteria screen, select Product and choose Adobe Acrobat Reader DC, Google Chrome and Power BI Desktop. You should also add Superseded and change it to No. Click preview to see the patches that will be gathered by these criteria.

Search criteria

Click Next and select to run the rule on a schedule. Customise the schedule and select that it should run monthly, on the second Wednesday of the month (or, whatever schedule is suitable for your organisations patching policies).

Update schedule

Click OK to accept the schedule and click Next. Decide when you want the updates to become available (typically immediately after they are deployed) and when you want the installation deadline. On the next screen, decide if you want the updates to appear in Software Center or not, and what clients should do when the deadline is reached.

Continue through the wizard, selecting a deployment package to add these updates to (or creating a new one) and finally complete the wizard. If you’re ready to get the patches out right now, select the new ADR and click Run Now.

Back on the client

After leaving this for a few hours to give my client time to run a software update scan, I checked Software Center to see what updates were waiting for me…

Updates in Software Center

Just what I was hoping to see! After clicking Install All and waiting a few minutes, all three updates install and my third-party software on this client is up to date. If I left this configuration in place, next month I would expect to see these patches appear automatically, as the Ivanti scheduled task would run, followed by the Automatic Deployment Rule in SCCM that would deploy them to my client. This is assuming the vendors release new versions of this software by the time the tasks run.

If you have read this whole series, or even just parts of it, I hope this has been useful in helping you implement Ivanti Patch for SCCM or argue the case for it. Products like this make it very easy to patch third-party software using SCCM and it is as important nowadays to patch software from third parties as it is to patch Windows. Sometimes, it is even more important!

 

Buy Me A Coffee

Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation
Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate
Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings
Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update
Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

In Part 4 of this guide we will create the service account that Ivanti will use to run scheduled tasks and publish our first third-party update to into WSUS to deploy with SCCM.

Ivanti Service Account

When you configure third-party updates, Ivanti creates scheduled tasks that need to run under an account with permissions to publish updates into WSUS (we will go over this in the next section). While you can follow the process of publishing third-party updates with your own account, it is not considered good practise. Instead, you should create a service account for Ivanti to use and ensure it only gets the permissions needed to do its job (in line with the principle of least privilege for service accounts).

In this case, the service account will need the following permissions:

  • Log on as a batch job on the server you run Ivanti on*
  • Be a member of the Administrators group on the WSUS server
  • Be a member of the WSUS Administrators group on the WSUS server
  • In SCCM, the account must be a full administrator with the security scope set to all

*This is an important point. The scheduled tasks will be created on the server you run Ivanti on, which may not be your WSUS or SCCM server. This may be okay if you run Ivanti from a management server, or the SCCM itself, that will be on 24/7. However, if you have been running Ivanti from your own workstation up to now, you may need to switch over to a server.

The first 3 requirements can be met by configuring the account in group policy or by manually configuring the account on the servers.

To configure the account as a full administrator with all security scopes in SCCM, open the SCCM console and navigate to Administration > Security > Administrative Users and click Add User or Group in the ribbon. Click Browse and find your Ivanti service account. Click Add and tick Full Administrator from the list of available security roles. Finally, select All instances of the objects that are related to the assigned security roles.

SCCM Full Administrator

Alternatively, you can create a security group in Active Directory and assign that full administrator rights in SCCM in the same way, and then add your regular user accounts and the Ivanti service account to that group.

To test that your service account has all the access it needs, open the SCCM console and navigate to Software Library > Software Updates > Ivanti Patch and click on Settings in the ribbon. Go to the Verify Setup tab and click Launch Configuration Checker. In the testing tool, change the username to the username for your service account and enter the password. Click Start and review the results of the test. If anything comes back as red, review your settings and correct as needed. Hopefully it will all come back green!

Ivanti Service Accont Test

Publishing a third-party update

At last, let’s get a third-party update published into WSUS and deployed with SCCM.

The first thing to do is to create a smart filter for the product you want to patch. This will reduce the large list of available updates down to just the one you need. Ideally you should create smart filters for each product you want to patch, rather than using a single filter for all products. This gives you more granular control over the updates for each product.

Let’s create one for Google Chrome. Start by opening the SCCM console and navigating to Software Library > Software Updates > Ivanti Patch. In the search bar, search for Google Chrome and scroll down to until you find the Google Chrome updates.

Searching for Google Chrome Updates

Click on the New SmartFilter button to begin.

New SmartFilter

In the Select scope section, be sure to click Shared. This will store this smart filter in the database and make it visible to anyone else who administers Ivanti. Give the filter a name such a Google Chrome and change the rule matching from any to all.

In the rule, change the first field to Product and ensure the next rule is set to contains. Enter the value Google Chrome in final field. Then click + Add rule and this time set the first field to Is Superseded, the second field should be Does not contain and the final field should be Yes.

Google Chrome Smart Filter

This creates a smart filter that will find updates for Google Chrome that are not superseded. Click Save and the results will be displayed.

Google Chrome Smart Filter Results

Now that the smart filter has been created, click on Scheduled Tasks in the ribbon. Using scheduled tasks, new updates that match the results of the smart filter can be published on a regular schedule. Click Create new task and give it a name, such as Google Chrome. Choose what schedule you would like this task to run. Bear in mind that this is the schedule that new updates will be published into WSUS, not the schedule that they will be deployed to users. That will be handled by an Automatic Deployment Rule in SCCM later. I would recommend making these run once a week in the evening (perhaps on a Tuesday so the latest third-party updates get published into WSUS at the same time as new Microsoft updates on Patch Tuesday).

Tick Publish the updates selected by this filter and select your Google Chrome filter from the drop down list. You do not need to add the updates to a Software Update Group as that will also be handled later by the Automatic Deployment Rule. Finally, make the task run as a Different user by selecting the radio button and enter the credentials for your Ivanti service account.

Create Scheduled Task

Click OK to save this new task. Now open Task Scheduler (the Windows one) and expand Task Scheduler Library > Ivanti > Patch. You will see the task listed here! Select the task and click run to test that it is working. When it is running, quickly switch back to the Ivanti Patch interface in SCCM and select your Google Chrome smart filter. Watch as the status updates to downloading…

Downloading

packaging…

Packaging

publishing…

Publishing

and finally published.

Published

Next you need to synchronise the updates between WSUS and SCCM. This is done by clicking Synchronise Software Updates in the ribbon. The progress of this can be monitored using the wsyncmgr.log file on the SCCM server.

When the sync is complete, you need to subscribe to this product in SCCM. This only needs to be done the first time you sync after adding a new product. In the ribbon, click Manage Products and select the vendor – Google Inc in this case. Click Subscribe and wait for the status to change to Subscribed.

Subscribe to vendor

Once that is done, close the Manage Products window. Now synchronise the updates once again and wait for it to complete. If you are keeping an eye on wsyncmgr.log you should see the following lines about new patches being sync’d:

wsyncmgr.log

Great! Now you can go to the All Software Updates node and search for Google Chrome. These two patches should appear.

Google Chrome in All Software Updates

Now that the Google Chrome updates are in SCCM, all you need to do is follow the same process you would for a Windows update. Create an Automatic Deployment Rule and a schedule to deploy this to clients. Let’s create a new ADR for Google Chrome, to publish the updates on the second Wednesday of every month (the day after the Second Tuesday patches are released by Microsoft).

In the SCCM console go to Software Library > Software Updates > Automatic Deployment Rules. Click Create Automatic Deployment Rule and give it a name such as Google Chrome Monthly Updates. Specify a collection that contains your clients, and make sure the rule adds updates to an existing Software Update Group each time it runs. Click Next and Next again.

On the filters list, tick Product and Superseded. For Product, select Google Chrome among the list of products and for Superseded select No. Click Preview to see a list of updates that the ADR will deploy.

Deploying Google Chrome with ADR

Click Next and select to run the rule on a schedule. Customise the schedule and select that it should run monthly, on the second Wednesday of the month.

Update schedule

Click OK to accept the schedule and click Next. Decide when you want the updates to become available (typically immediately after they are deployed) and when you want the installation deadline. On the next screen, decide if you want the updates to appear in Software Center or not, and what clients should do when the deadline is reached.

Continue through the wizard, selecting a deployment package to add these updates to (or creating a new one) and finally complete the wizard. If you’re ready to get the patches out right now, select the new ADR and click Run Now. This should cause the Google Chrome updates to be added to the Software Update Group and the Deployment Package, and any clients in the collection you targeted while creating the ADR should receive the update soon!

You are now ready to deploy third-party updates to clients in your organisation. In the final part of this guide we will patch Google Chrome, Adobe Reader DC and Power BI Desktop using Ivanti on a client currently running out of date versions of each of them!

 

Buy Me A Coffee

Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation
Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate
Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings
Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update
Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

In Part 3 of this guide we will go through each tab in the Ivanti settings window to get everything configured as needed. Open the SCCM console and go to Software Library > Software Updates > Ivanti Patch. The Settings Window may appear on its own, but if it does not, click on Settings in the ribbon to open it.

Shared Settings

Ivanti Patch for SCCM works in two modes: User mode and shared mode. As explained by Ivanti in the Shared Settings tab, by default all settings and scheduled tasks created within Ivanti are unique per user per machine. This means they will only appear for a for the administrator who created them, on the machine they created them on. Not ideal for larger companies with many administrators! Thankfully, Ivanti also allows settings to be stored in a database, and then as long as every administrator configures Shared Settings and selects the same database, they will all see the same view.

I will assume you want to use Shared Settings. So, tick Shared Settings and select a SQL database to store the settings in. I just use the SCCM database – Ivanti simply adds a new table and it does not interfere with SCCM. If you do not wish to do that, you can simply create a new database on the same SQL instance that runs the SCCM database. Click Test server connection to ensure the connection can be made.

Configure Shared Settings

Click Save connection and Ivanti will begin to create the new table. You will get a message asking you to confirm that it is okay for Ivanti to update the database. Click Update.

Confirm update

After a moment you should get a message informing you the database was successfully updated.

Database Operation Successful

Click OK and read and confirm the next notice informing you that certain settings should be re-verified (we’ll be doing this as we continue through the Ivanti settings).

WSUS Server

The majority of work here has already been done in Part 2, however you should make sure that the WSUS server hostname and port are still set (click Test connection to make sure that it’s still working) and also just double check the certificate details are what you expect. One final thing that is worth doing, is setting a timestamp server. The advantage to signing the updates with a timestamp is that even after the certificate expires, updates signed by it when it was valid will continue to be trusted. If the timestamp server is not set, once the certificate expires, everything signed by it will no longer be trusted.

You can use any number of freely available timestamp servers that can be found online. I use the one provided by DigiCert, which is http://timestamp.digicert.com. Enter this (or any other of your choosing) and click Test. After a moment you should get a message informing you that it is a valid RFC 3161 timestamp server.

Timestamp Server

Proxy

You may have already been to this tab to configure a proxy, as you may not have been able to complete previous parts of this guide without giving Ivanti access to the internet! By default, Ivanti will use the same proxy settings that are configured in Internet Explorer. If your proxy requires authenticated access, tick Use proxy and enter the username and password required for access.

If you are not certain about needing a proxy, Ivanti offers a quick test to see if it can access the internet. Click Do I need proxy information? and Ivanti will test and let you know.

Proxy test

License

Click Enter / refresh license key. If you have already purchased your license, make sure that activation mode is set to Product license, and copy and paste your activation key into the field, and then click Add. In the activation method section select Online and click Activate online now (configure a proxy if that is needed to reach the internet).

If you are testing this product you can select Trial mode as the activation mode, and then click Activate online now (configure a proxy if that is needed to reach the internet). After a moment a green tick should appear informing you that the activation has completed successfully.

Activate Trial Mode

You will get 2 months from now to test Ivanti Patch for SCCM. You can test with up to 50 clients and can patch up to 5 products.

License Details

Languages

Like WSUS, Ivanti offers some updates in multiple languages. You can choose to either download updates in all available languages, use the same languages that are configured in WSUS, or select which languages you want. I think it makes the most sense to use the same languages that you use in WSUS.

Language Selection

Catalogs

Catalogs are the list of updates that are available from a provider. By default, the Ivanti catalog will be ticked as active, as this is part of what you are paying for with Ivanti. You can optionally search online for additional catalogs to add if you wish, however most of these are not free. For now, let’s just stick with the Ivanti catalog, so no changes need to be made in this tab.

Verify Setup

Now you can verify that everything you have configured is working. Click on Launch Configuration Checker and check that the WSUS server name and port are correct. Make sure your user account is entered correctly and enter your password. If a username and password are required to access the internet through the proxy, tick Use proxy and enter the username and password.

With that all set, click Start! All going well, you will see every test pass. If some do not, correct whatever is wrong and re-run the test.

Ivanti Configuration Checker

About

Nothing to configure in here, but the Finish button lights up when you click on this tab. Click Finish to save all your configuration and close the settings window.

Tune in for Part 4 where the fun stuff finally begins. We will create a service account that will be used by Ivanti to publish updates on a schedule and publish the first third-party update into WSUS and SCCM.

 

Buy Me A Coffee

Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation
Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate
Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings
Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update
Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

Part 2 of this guide is a pretty beefy one, as we prepare a code signing certificate for WSUS to use to sign the third-party patches. If you are going to use your own internal PKI, you must also be using WSUS over SSL, which I also explain how to configure in the first half of this part. If you are not going to use an internal PKI and just want to use a self-signed certificate, skip down to the second half of this page. At the end of this page there is one more setting that must be configured in GPO – don’t miss it!

In order to follow the steps in this part of the guide, your account needs to be a member of the WSUS Administrators group on your WSUS server.

Code signing using your internal PKI to generate a certificate

This guide assumes you already have a functional internal PKI powered by Active Directory Certificate Services. If your internal PKI is powered by a different PKI provider, you will need to follow guidance from them (or another blogger!) If you do not have an internal PKI, you should consider implementing one, or use the next section of this blog post to use a self-signed certificate.

First things first. In order to import a certificate from your internal PKI to WSUS, you must connect to WSUS over SSL. This is because you will be sending a private key from Ivanti to WSUS, and if this was captured in transit by a bad guy it could be used to sign code that would be trusted by all clients in your organisation. If you already have an internal PKI up and running, you may have already configured this. However, as it is not a requirement for using WSUS (or using WSUS with SCCM) it is also possible that you have not. These next few paragraphs explain how to configure WSUS over SSL (if you have already configured this, skip ahead a bit).

Log on to your WSUS server and open IIS Manager (or open IIS Manager on a management server and connect to your WSUS server). Select the server name on the left and find the Server Certificates icon among the sea of icons on the right. Double click on it, and then select Create Domain Certificate from the list of Actions. Fill in the information (make sure the common name is the name of the WSUS server).

Distinguished Name Properties

Click Next. On the next screen, click select and chose your issuing certificate authority. Give it a friendly name such as WSUS SSL Certificate. Click Finish and a certificate should be issued and added to the list of available server certificates.

Now expand Sites on the left and select WSUS Administration. Click on Bindings in the list of Actions on the right, select https and click Edit. On the SSL certificate drop down select the certificate you just issued and click OK. Click Close to close the Site Bindings window. Now expand the WSUS Administration site and select ApiRemoting30. Double click on the SSL Settings icon and tick Require SSL. Click Apply on the right. Repeat that that process for the following directories: ApiRemoting30, ClientWebService, DssAuthWebService, ServerSyncWebService and SimpleAuthWebService.

Require SSL on WSUS Directories

Open an administrative CMD prompt and change the directory to C:\Program Files\Update Services\Tools using the following command:

cd "C:\Program Files\Update Services\Tools"

Execute the following command to tell WSUS to start using SSL (replacing WSUS_SERVER with the fully qualified domain name of your WSUS server):

WSUSUtil.exe configuressl WSUS_SERVER 

Configure WSUS SSL

Finally, restart the WSUS Service to make sure these settings are effective. To test that it is working, open the WSUS Management Console and make sure you can connect (you should now be connecting to it on the SSL port, 8531).

Okay, now onto the work for the WSUS code signing certificate.

On a management server, open an MMC window and load the Certificate Authority snap-in. Connect to your issuing CA and expand the certificate authority so that you can select Certificate Templates.

Issuing Certificate Authority

Right click on Certificate Templates and click Manage. This will open the Certificate Templates Console. Highlight the Code Signing template and right click and select Duplicate Template.

Code Signing Template

This will allow you to modify the properties of the new Code Signing template that we are creating. Go to the General tab and give it a name; something like WSUS Code Signing or a similarly descriptive name will do nicely. You should also change the validity period from the default of 1 year to something a little more reasonable, like 3 years. You may wish to keep the validity period short, but just bear in mind that the shorter it is, the more often you will need to generate a new one. Remember that all clients must trust the new certificate before the old one expires!

WSUS Code Signing Template

Head over to the Request Handling tab and tick Allow private key to be exported. We need this so that we can import this certificate into WSUS a bit later. Go to the Subject Name tab and select Supply in the request (rather than the default to build from Active Directory information). Finally, go to the Security tab and make sure the correct user(s) have Read and Enrol permissions. This will depend on how your environment is set up. If you have a WSUS Administrators group, or a SCCM Administrators group, or even just a group for your team, you should add this group here and assign it Read and Enrol permissions. Alternatively, you can add individual accounts, such as your own, and assign these permissions. Whatever the case, if you are responsible for this piece of work, make sure you have permissions to Read and Enrol certificates from this template!

That’s all the changes we need to make, so click OK and close the Certificate Templates Console. Back in the Certificate Authority MMC, right click on Certificate Templates again and select New > Certificate Template to Issue. Find the WSUS Code Signing template among the list, select it and click OK. This template will now appear among your list of available certificate templates!

WSUS Code Signing Template Available

Next up is enrolling a code signing certificate for WSUS using this template. You can do this from any workstation connected to your domain. Open MMC and load the Certificates snap-in. Select My user account and click Finish. Expand Certificates – Current user and right click on Personal and select All Tasks > Request New Certificate. Click Next, and Next again to see the list of certificates that are available from Active Directory Certificate Services. You should see the WSUS Code Signing certificate template amongst the list, along with a message informing you that more information is required.

Certificate Enrollment

Tick the WSUS Code Signing template and then click on the More information is required link. Change the Subject name from Full DN to Common name and give it a value that describes what this certificate is being used for. Something similar to the name of the template, like WSUS Code Signing Certificate. Click Add to add this common name to the certificate. Although not mandatory, you can also go to the General tab and give the certificate a Friendly name and description (these are what will appear when you view this certificate in the Certificates snap-in in MMC). I went ahead and used the same value as I used for the common name here.

Certificate Properties

That’s all that needs to be configured here, so click OK to close the Certificate Properties window. Click Enroll, and then click Finish. Now expand Personal and click on Certificates, and you should see the newly enrolled certificate on the right, with the friendly name you set (if you did).

Now that the certificate has been enrolled, we need to export it so that we can use it in WSUS and deploy it out to workstations. Right click on the certificate and select All Tasks > Export. Click Next, and select Yes, export the private key. Click Next again, and Next again, and give the exported certificate a password. Make sure this password is strong! You do not want bad guys to have the ability to sign code using a certificate that all of your workstations will trust. Click Next again and give this certificate a name such as WSUSCodeSigningCertificate.pfx. Click Next again and Finish to complete the export.

If you want, you can delete this certificate from your personal certificate store. It no longer needs to be there now that you have exported it.

Next we need to import this certificate into WSUS so that it can be used to sign the third-party update that Ivanti provides.

Switch over to the management server where you have access to the SCCM console and installed Ivanti Patch for SCCM in Part 1 of this guide. Navigate to Software Library > Software Updates and click on Ivanti Patch. The Settings window should automatically appear once again – if it does not, simply click Settings in the ribbon. Go to the WSUS Server tab and enter the hostname of your WSUS server (in my case this is the same as my WSUS server) and the port number it is available on (this is likely 8531 if you are configured for WSUS over SSL, which you have to be). Click Test Connection to ensure the details you entered are correct.  Hopefully you will get a message informing you the connection to your WSUS server was successful. Click OK to accept the message.

Test SSL WSUS Server Connection

Under WSUS signing certificate, click Import. Select the certificate you exported earlier and enter the password you assigned it and click OK. The certificate will be imported into WSUS and you will get a message informing you of the next steps you need to take.

Actions you must take

So, here’s what we need to do next:

  1. Review the certificate that has been created. You can do this in a moment when you acknowledge the message.
  2. Add the certificate to the Trusted Root and Trusted Publishers stores on the WSUS server.
  3. Add the certificate to the Trusted Publishers store on every workstation you want to install third-party updates.

Okay let’s get on with these tasks. The first, to review the certificate, can be done immediately after you click OK. The certificate details will be displayed in the Current certificate section, and you can click View certificate to bring up the full details for this certificate. It will be valid for 3 years if you took my advice earlier, or whatever you set the validity period to. Remember to set a reminder in your calendar to generate a new certificate nearer the time this one will expire, with enough time to deploy it out to all of your clients!

To do the second action, click Export under WSUS signing certificate and save the certificate somewhere, giving it a name such as WSUSCodeSigningCertificate.cer (this is different from WSUSCodeSigningCertificate.pfx as it does not contain the private key). Next, log on to your WSUS server and open MMC and load the Certificates snap-in. Select Computer account, click next and then Finish. Expand Certificates (Local Computer) and right click on Trusted Root Certification Authorities and select All Tasks > Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Place all certificates in the following store is selected, with Trusted Root Certification Authorities being the selected store. Click Next and then Finish and then click OK to close the success message. Expand Trusted Root Certification Authorities > Certificates and check to see your WSUS code signing certificate is listed.

Trusted Root Certification Authorities

You need to repeat these steps to also import the certificate into the Trusted Publishers store.

Finally, this same certificate must be added to the Trusted Publishers store of every client you want to install third-party updates on. The simplest way to do this is to deploy it with Group Policy. Open the Group Policy Editor and select the most appropriate GPO to add this too or create a new one. It must apply to machine objects and must be high enough in your Active Directory OU hierarchy to apply to every device you want installing these updates. In the Group Policy Editor window, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and select Trusted Publishers. Right click on Trusted Publishers and select Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Trusted Publishers is the selected store. Click Next and then Finish and click OK to the success message. You should see your WSUS code signing certificate listed on the right.

Deploy certificate to Trusted Publishers

Close the Group Policy Editor. Test that this is working by finding a client and updating Group Policy on it. Open the Certificates MMC add-in and check in Trusted Publishers to see if it’s been deployed to it.

Code signing using an Ivanti-generated self-signed certificate

If you do not have an internal PKI up and running, Ivanti offers you a very simple way to generate a self-signed certificate, which it will import into WSUS for you. Once that is done, you must distribute the certificate to every workstation you want to install third-party updates.

Open the SCCM console on the server that you installed Ivanti on in Part 1 of this guide and navigate to Software Library > Software Updates and click on Ivanti Patch. The Settings window should automatically appear once again – if it does not, simply click Settings in the ribbon. Go to the WSUS Server tab and enter the hostname of your WSUS server (in my case this is the same as my WSUS server) and the port number it is available on. Click Test Connection to ensure the details you entered are correct.  Hopefully you will get a message informing you the connection to your WSUS server was successful. Click OK to accept the message.

Test WSUS Server Connection

Under WSUS signing certificate, click Create a self-signed certificate, and read the message that instructs you on the actions you must take next. They are:

  1. Review the certificate that has been created. You can do this in a moment when you acknowledge the message.
  2. Add the certificate to the Trusted Root and Trusted Publishers stores on the WSUS server.
  3. Add the certificate to the Trusted Publishers store on every workstation you want to install third-party updates.

Actions you must take

Okay let’s get on with these tasks. The first, to review the certificate, can be done immediately after you click OK. The certificate details will be displayed in the Current certificate section, and you can click View certificate to bring up the full details for this certificate. Note that it has a 5 year life and will have to be renewed before that expiration date. If this certificate expires before you have renewed it and deployed the updated certificate, clients will no longer install the third-party updates.

To do the second action, click Export under WSUS signing certificate and save the certificate somewhere, giving it a descriptive name such as WSUSCodeSigningCertificate.cer. Next, log on to your WSUS server and open MMC and load the Certificates snap-in. Select Computer account, click next and then Finish. Expand Certificates (Local Computer) and right click on Trusted Root Certification Authorities and select All Tasks > Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Place all certificates in the follow store is selected, with Trusted Root Certification Authorities being the selected store. Click Next and then Finish and then click OK to close the success message. Expand Trusted Root Certification Authorities > Certificates and check to see that WSUS Publishers Self-signed is listed.

Trusted Root Certification Authorities

You need to repeat these steps to also import the certificate into the Trusted Publishers store.

Finally, this same certificate must be added to the Trusted Publishers store of every client you want to install third-party updates on. The simplest way to do this is to deploy it with Group Policy. Open the Group Policy Editor and select the most appropriate GPO to add this too or create a new one. It must apply to machine objects and must be high enough in your Active Directory OU hierarchy to apply to every device you want installing these updates. In the Group Policy Editor window, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and select Trusted Publishers. Right click on Trusted Publishers and select Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Trusted Publishers is the selected store. Click Next and then Finish and click OK to the success message. You should see the WSUS Publishers Self-signed listed on the right.

Deploy certificate to Trusted Publishers

Close the Group Policy Editor. Test that this is working by finding a client and updating Group Policy on it. Open the Certificates MMC add-in and check in Trusted Publishers to see if it’s been deployed to it.

Configurating Windows Update on clients to install updates not signed by Microsoft

By default, the Windows Update client will only install updates signed by Microsoft. To configure it to install updates signed by other Trusted Publishers you must configure a setting in GPO. Select the GPO you will use to deploy this setting and in the Group Policy Editor window, navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update and find the setting Allow signed updates from an intranet Microsoft update service location. Open it and set it to Enabled.

Phew! That was a lot of work… in Part 3 we will be configuring the rest of the settings for Ivanti Patch for SCCM.

 

Buy Me A Coffee

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation
Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate
Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings
Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update
Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

Patch Tuesday is a term well known by most sysadmins to describe the monthly drop of patches by Microsoft and other vendors for their software and most organisations have some process in place to make sure Windows, Office and other Microsoft products receive these updates via SCCM or WSUS.

However, this leaves out the large number of other products that are frequently used by businesses, from various versions of Java, Google Chrome / Firefox and Adobe Acrobat to simple utility applications like Zoom or 7-Zip. These applications often have just as many issues as Windows and it is just as important to keep these up to date. Updating these manually every month, by updating the deployment packages in SCCM or through other means is a very time-consuming process, which is why it is better to have an automated process for these applications.

Ivanti Patch for SCCM provides a solution that integrates right into the SCCM console and can be used to automatically publish third-party application updates into WSUS for you, allowing you to use familiar SCCM tools such as Automatic Deployment Rules, Deployment Packages and Software Update Groups to manage the updates and decide on the schedule that your clients receive them.

This guide is written for use in a production environment; however, it can easily be tailored for use in a lab or test environment. Once installed, Ivanti Patch for SCCM can be used for 2 months in trial mode before a license must be applied.

Planning

Before you start raising your purchase order and installing the SCCM console plugin, you should first consider a few things. First and foremost, does Ivanti provide updates for some of the key software used in your organisation? Ivanti publishes a list of supported products that can be found here: List of Ivanti Supported Products. You should review this list and ensure there are enough products there that you use to make it worthwhile.

You will also need to know how many clients you intend to patch with Ivanti, as licensing is provided per client and the number must be specified when purchasing. The cost per seat may depend on your reseller and what rate they can negotiate for you; plus, any multi-year licensing discounts you may be able to get. Speak to your preferred reseller to find out what rates you can get.

There are some user access and service account considerations as well. During this guide you will need to be a member of the WSUS Administrators group on your WSUS server, and have permission to write to the SCCM database as Ivanti will be creating a new table in there as part of its configuration. You will also need to create a service account that has Logon as a batch job privilages on your management server, and is also an Administrator and WSUS Administrator on the WSUS server.  This will be used to run Ivanti scheduled tasks. More on this in Part 4.

There will also be a code signing certificate that must be generated and imported into the Trusted Publishers store on every client you want to be able to install these third-party updates. You have two choices, you can either use a self-signed certificate that Ivanti will generate for you, or you can use an internal PKI to create one. If you use a certificate from your internal PKI, you will also need to configure WSUS over SSL. In either case GPO is the preferred means to deploy it to your clients. This is fully covered in Part 2 of the guide.

Finally, you must enable the setting Allow signed updates from an intranet Microsoft update service location in GPO. This will also be covered in Part 2.

Installation

Installing Ivanti Patch for SCCM is a fairly simple process that we will cover here. In this guide I will be installing Ivanti on a management server that has full network access to my SCCM and SQL server (the same server, in my case). You can either install it directly on the your SCCM server, or on any other management server as long as it has the SCCM console installed and has adequate access to the SCCM, WSUS and SQL servers.

Start by downloading the Ivanti Patch for SCCM installer, which can be found here.

There are a few pre-requisites that must also be installed, if they are not already.  They are:

Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019 (x86 and x64)
Microsoft .NET Framework 4.8

Installing these may require a reboot and this reboot should be completed before installing Ivanti Patch for SCCM.

Okay, let’s install Ivanti. Double click the installer executable, accept the license terms and click Install. Note: If any of those pre-requisites are not installed, or the reboot not done, you will now be prompted to complete them before the installation can continue.

Ivanti Patch for SCCM Installation

And just like that… it’s done! Click Finish to complete the installation.

Ivanti Patch for SCCM Installation Complete

Now open your SCCM console and navigate to Software Library > Software Updates. You will see a couple of new nodes added: Ivanti Patch and Published Third-Party Updates. If you click on Ivanti Patch, the Ivanti Patch for SCCM settings window will appear. For now, click Cancel. We will return to this, but first you need to decide whether you will be using a self-signed code signing certificate, or one generated from your internal PKI (if you have one).

Ivanti Patch for SCCM first load

This will be covered in Part 2!

 

Buy Me A Coffee

Applying your Extended Security Updates (ESU) MAK to Windows 7 with SCCM

Over the last couple of years, the main focus of IT within many medium to large organisations has been migrating their users from Windows 7 to Windows 10. As of January 14th, 2020, Windows 7 is no longer receiving the monthly security updates it has been receiving since it was released 10 years ago. This means that any organisation with Windows 7 clients still in use is at an ever-increasing risk of attackers using this weaker link to compromise their network.

For organisations willing to pay, Microsoft is offering an additional 3 years of support for Windows 7 through their Extended Security Updates (ESU) program. If you are enrolled in this program you will be provided a MAK to install on the Windows 7 clients that you wish to continue receiving updates on (good for as many seats as you have paid for). Part 1 of this guide will go through the process of verifying the key you have is working by manually installing it on a Windows 7 device and installing the ESU test update Microsoft published. Part 2 will go through the process of deploying the key using SCCM.

A few other notes about this:

The ESU MAK you receive will be good for Windows 7 Professional, Enterprise and Ultimate (there are no separate SKUs for each edition of Windows). It will also work on both x86 and x64 versions of Windows 7.

Your existing Windows 7 updating mechanism will continue to work once you have activated the ESU MAK on the client. Whether you use SCCM, WSUS or simply allow devices to go out directly to the internet for updates, you do not need to make any changes. The updates will continue to be downloaded post January 2020 and will appear in Software Center or in the Windows Update control panel applet if the ESU MAK has been applied to that device.

This guide will be assuming your clients will be internet connected when you activate the ESU MAK. If that is not the case you may need to use the Volume Activation Management Tool as detailed in Microsoft’s blog post on this subject.

Part 1 – Manually installing your ESU MAK on a Windows 7 device

Before you start deploying this to every Windows 7 device still in use, you may want to install it on one device to prove that it is valid, and to test that your updates delivery mechanism is working. Microsoft published a test update that doesn’t do anything to the device but does use the same logic to detect whether or not a valid ESU MAK has been installed. You can use this to test the end to end process before the first real patches come out in February. This update is KB4528069.

To start, check for new updates on your Windows 7 device and verify that you do not see KB4528069 in the list of available updates:

List of available updates before the ESU MAK key has been applied

Open an administrative CMD prompt and type slmgr.vbs /dlv. This will bring up a window that shows your current licensing situation, and it is likely to look something like this:

License Info Before ESU MAK key applied

Next you need to install your ESU MAK. To do this, enter the command slmgr.vbs /ipk ABCDE-FGHIJ-KLMNO-PQRST-UVWXY, replacing this made-up key with your key. You should get a success message that looks like this:

ESU MAK Key Install Success

If you do not get a success message, it may be because Windows 7 does not recognise the key. This is because support for these ESU MAK keys was only introduced in the September 2019 and October 2019 monthly updates for Windows 7 (which in turn require the SHA-2 code signing support update released in March 2019). If you have an issue installing your key, ensure that these are installed and try again.

Once you have successfully installed the key you can verify that Windows has accepted it by once again using the command slmgr.vbs /dlv. This time you should see this:

License Info After Installing ESU MAK Key

As you can see it has not yet been activated. To activate it, you will need the Activation ID for the ESU SKU, which you can see here is “77db037b-95c3-48d7-a3ab-a9c6d41093e0”. In fact, Microsoft has already published what these will be for all 3 years of the ESU program, because they will be the same for everyone:

ESU Program ESU SKU (or Activation) ID
Windows 7 SP1 (Client)  
Year 1 77db037b-95c3-48d7-a3ab-a9c6d41093e0
Year 2 0e00c25d-8795-4fb7-9572-3803d91b6880
Year 3 4220f546-f522-46df-8202-4d07afd26454
Windows Server 2008/R2 (Server)
Year 1 553673ed-6ddf-419c-a153-b760283472fd
Year 2 04fa0286-fa74-401e-bbe9-fbfbb158010d
Year 3 16c08c85-0c8b-4009-9b2b-f1f7319e45f9

Table taken from https://techcommunity.microsoft.com/t5/windows-it-pro-blog/how-to-get-extended-security-updates-for-eligible-windows/ba-p/917807

To activate the key, use the command slmgr.vbs -ato 77db037b-95c3-48d7-a3ab-a9c6d41093e0. You should get a window pop up to tell you the activation has been successful.

ESU MAK Key Activating Success

Now you can run slmgr.vbs /dlv one last time to see the final state of your licensing:

License Info After Activating

This time the License Status shows as Licensed!

Now it is time to test that KB4528069 will appear and install on this device. Start another scan for patches and allow some time for the scan to complete. After a while, open Software Center or Windows Updates and you should see the following:

List Of Updates After ESU MAK Key Activation

Install it and confirm that your ESU updates are working as expected.

Part 2 – Deploying your Windows 7 ESU MAK to multiple devices using SCCM

Once you have confirmed your key is working, you no doubt want to install it on all remaining Windows 7 devices in your estate. The easiest way to do this is with a simple batch script deployed via SCCM.

First of all, if you do not already have one, create a collection that contains the Windows 7 devices you wish to install the ESU MAK on. If you simply want to create a collection that automatically contains any Windows 7 device connected to your SCCM, you can use the following query:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like '%Workstation 6.1%' ORDER BY SMS_R_SYSTEM.ResourceID

Next create a batch script containing the following commands:

@echo off
cscript //B "%windir%\system32\slmgr.vbs" /ipk ABCDE-FGHIJ-KLMNO-PQRST-UVWXY
cscript //B "%windir%\system32\slmgr.vbs" /ato 77db037b-95c3-48d7-a3ab-a9c6d41093e0

Once again replace the made-up key here with your ESU MAK.

Batch Script For Activating ESU MAK

Copy this script to a network location that is accessible by SCCM.

In the SCCM console, go to Software Library > Packages and in the ribbon click Create Package.  Fill in fields such as Name, Description and tick “This package contains source files” and enter the network location where you put the batch script.

ESU MAK Package Creation 1

On the next screen select “Standard program”, and on the next screen give the Program a name. The command line should be cmd /c activate_windows7esu.cmd and in the Run drop down menu you should select Hidden. This will ensure that when this runs on the client, the user does not see the CMD box appear (however briefly). Make sure the name of the script matches what you called it.

ESU MAK Package Creation 2

You can complete the rest of the wizard by clicking Next and Finish. Once created, distribute this package to your Distribution Points, and finally deploy it to the collection containing Windows 7 devices. When deploying, ensure you make it a Required deployment, set the Assignment schedule to “As soon as possible” and in the User Experience section make sure that Software installation is allowed outside of maintenance windows. This will allow the script to run as soon as possible on your Windows 7 devices.

Hopefully this will get you well on your way to continuing to receive Windows 7 updates over the next few months, and fingers crossed you’re not far from eliminating Windows 7 from your estate completely!

Bonus fun: What happens if you try to install the test update, KB4528069, on a Windows 7 device that you have not activated your ESU MAK on? It simply fails to install:

KB4528069 Fails to Install

 

 

Buy Me A Coffee