Kevin's tech blog

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.

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!

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.

Click on the New SmartFilter button to begin.

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.

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

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.

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…

packaging…

publishing…

and finally 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.

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:

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

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.

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.

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!

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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).

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.

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

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.

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.

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!

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!

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.

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.

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.

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.

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

Review the certificate that has been created. You can do this in a moment when you acknowledge the message.
Add the certificate to the Trusted Root and Trusted Publishers stores on the WSUS server.
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.

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.

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.

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:

Review the certificate that has been created. You can do this in a moment when you acknowledge the message.
Add the certificate to the Trusted Root and Trusted Publishers stores on the WSUS server.
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. 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.

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.

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.

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 privileges 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.

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

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).

This will be covered in Part 2!

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 Updates Available Pre-ESU MAK Key Installation

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:

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:

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:

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.

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

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:

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.

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.

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.

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:

The mystery of the invisible System Center Configuration Manager update

Since mid-December 2019 I have been trying to update my SCCM lab environment from 1906 to 1910. For the first few weeks of release it was in the early update ring, but no matter how many times I ran the PowerShell script to enable early updating, the update would not appear in the Updates and Servicing node in SCCM.

Oh well, no matter, I thought. Perhaps it’s buggy and has been pulled, or maybe there’s just some odd reason my environment isn’t compatible. I’ll just wait for the general release.

General release comes and goes… and still no update. What’s going on?! I am 100% certain that my Service connection point is set to Online, I have restarted the SMS_EXECUTIVE service so many times, and also restarted the whole server just to be as thorough as possible! I know my server has internet connectivity because the Software update point is happily downloading and applying the January 2020 updates to my servers and clients. And finally, I have checked dmpdownloader.log, CMUpdate.log and hman.log and there are no obvious errors in there to tell me why I’m not seeing the latest update.

(Okay – that paragraph was a overblown way to tell you what you should definitely check if you haven’t already, before you continue to read).

So, what was going on?

Delving a little deeper in the hman.log file, I did find the following two errors:

CServerStatusReporter::DeliverToStatusManager(): ERROR: Cannot deliver status message to SMS_STATUS_MANAGER, could not write the message to varfile E:\Program Files\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\90sna58w.SVF due to a file error: The file or directory is corrupted and unreadable.

Error: Failed to move file E:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\ForwardingMsg\___CABConfigMgr.Update.Manifest.MCM to E:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\CFD\ConfigMgr.Update.Manifest.CAB, Win32 error = 1392

When I attempted to navigate to “E:\Program Files\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs” I got an error message telling me the location was corrupted and unreadable!

Oops – my screenshot shows statmsgs.old. That’s because I already fixed it before posting this article.

I got the same error when I tried to navigate to “E:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\CFD”. I’m not entirely certain how these two locations became corrupted, but thankfully Windows Explorer allowed me to rename them to “statmsgs.old” and “CFD.old” respectively, and then re-create the folders.

Once I restarted the SMS_EXECUTIVE service once more, hman.log finally filled up with information about the new update and the download proceeded. Finally, I have my update!

In all seriousness, this may be a very marginal case and may not be the reason you can’t see the latest update for SCCM. However, it seemed worth documenting; just in case someone else has the same symptom!

I would suggest clicking Check for updates in the Updates and Servicing node and then paying close attention to your hman.log file for any errors similar to the ones I found. Bear in mind that it might be different folders that cause errors for you, so keep an eye out for any errors with files being moved between inboxes.

Anyway, I’m off to go play with new SCCM features…!

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

Update 20/10/2020: Microsoft no longer provides Windows 10 1909 to people via the Media Creation Tool. See this post on how to download Windows 10 Enterprise 20H2 using the Media Creation Tool.

The November 2019 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 1909 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 and change directory to the directory you saved the Media Creation Tool in, and enter the following command:

MediaCreationTool1909.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:

MediaCreationTool1909.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 1909 with French installed and set to the default language, you can use this command:

MediaCreationTool1909.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 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_1909\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).

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

dism.exe /Export-Image /SourceImageFile:C:\Temp\Windows10_1909\sources\install.esd /SourceIndex:3 /DestinationImageFile:C:\Temp\Windows10_1909\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.

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

Unfortunately, I have found no way to get the LTSC version, or older versions of Windows 10 using this tool.

An error occurred while retrieving policy for this computer (0x80004005) when PXE booting from a USB stick

You may have run into the following error when you use a USB stick to PXE boot your device in preparation for running an SCCM Task Sequence:

However, other devices that you PXE boot from the network are working fine. What’s going on?

It could be a number of fairly quick things to troubleshoot, such as checking that the time and date on the device are the same as on the SCCM server and checking whether or not the device is already in SCCM (and therefore may not be receiving advertisements for Task Sequences).

If neither of those work, you’ll need to check the SMSTS.log file on the device. This can exist in a number of different places, however if the Task Sequence has not even begun, you should find it in X:\Windows\temp\SMSTSLog\smsts.log.

Let’s say you open the log file and you see the following error messages:

At first glance this would suggest that there is an issue with the time or date on the device being incorrect, and you should definitely double check whether or not that is the case. However, if you are certain it is not the problem, there is one other thing it might be that is not obvious at all from the error messages.

When you go through the Create Task Sequence Media Wizard to create the USB PXE image, one of the steps requires you to specify the start and end date for the self-signed certificate that is used for HTTP communication:

Create Task Sequence Media Wizard - Self-Signed Certificate

By default this is set to one year, and if you attempt to PXE boot from a USB stick using this image after the certificate expiration date, you will receive the error “An error occurred while retrieving policy for this computer (0x80004005)” and your SMSTS.log file will contain the errors in the screenshot above.

To solve this issue, go through the Create Task Sequence Media Wizard once again to generate a new image with a certificate that is in date. Perhaps also consider increasing the validity period of the certificate from one year to three.

Using Enterprise Mode in Microsoft Edge and Internet Explorer 11

Enterprise Mode is a feature that shipped in Internet Explorer 11 for Windows 10, and was also introduced to Internet Explorer 11 in Windows 7 and 8.1 in April 2014 that should be seriously considered by any organisation still hoping to complete their Windows 10 migrations before end of support in January 2020, but are worried that their older web applications may not work in the latest version of Internet Explorer.

Enterprise Mode has two functions depending on which browser you are using; In Microsoft Edge it can be used to automatically redirect certain website to IE11 (Edge itself does not do any compatibility rendering, it simply shifts you over to IE11 to do that). In IE11, it can be used to open specified sites in certain document modes or in IE8 or IE7 Enterprise Mode which offers greater emulation of those browsers.

To start, you must enable Enterprise Mode in both Edge and IE11 separately. Yes, there are two places in Group Policy where you have to enable this feature to fully utilise it.

For Microsoft Edge:
Computer Configuration > Policies > Administrative Templates > Windows Components > Microsoft Edge > Configure the Enterprise Mode Site List

For Internet Explorer 11:
Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Use the Enterprise Mode IE website list

When you have enabled them, you are also required to enter a path where your site list can be found. This can either be a URL (if you have an internal web server to host it) or a file share location (such as \\fileserver.domain.com\SiteList\sitelist.xml).

To create your site list, start by downloading the Enterprise Mode Site List Manager tool. That is assuming you are working with Windows 10 clients. If you are working with Windows 7 or 8.1 clients, download this tool instead. Once you’ve installed it you are given an easy interface to generate a valid XML file for the site list. Just for fun, let’s take my site and configure Edge to open it in IE11, and IE11 to render it in IE8 compatibility mode:

Let’s see what that looks like in the resulting XML:

A few things to take away from this:

1) The site list is on version 2. This matters because if this does not increment each time you make a change, Edge and IE11 will not honour the change.
2) The site URL is just the main domain and does not include the https:// or any subdomains. In this case, any URL containing kevinstreet.co.uk will redirect to IE11 (for example, https://reallyoldapp.kevinstreet.co.uk or https://kevinstreet.co.uk/reallyoldapp will redirect to IE11). If you only want a specific subdomain to redirect to IE11 then you should specify that subdomain.
3) The selected compatibility is IE8 Enterprise Mode.
4) The site will be opened in IE11. If a user tries to open it in Microsoft Edge, IE11 will automatically open and navigate to the page.

With the site populated with sites (presumably not actually with my site!) and the site list XML saved to the location you specified in the GPO, open Microsoft Edge and test browsing to the site you specified. It may not work immediately! Edge takes approximately 60 seconds from the time it is opened to check for a new version of the site list and apply it (as does IE11).

Super handy tip: If you want to confirm that your site list is working, in both Edge and IE11, type about:compat in the URL to get a list of websites and their prescribed behaviour. You even get a Force update button to speed up the process of updating the site list. Very useful if you are in the process of adding sites and want to quickly test that your configuration is working.

Once you’re sure both Edge and IE11 are using the latest version of the site list, retry browsing to a URL you specified. In Edge, it should automatically open in IE11 and open in the specified compatibility mode.

Gosh my site looks pretty bad being rendered as if it was open in Internet Explorer 8!

As you can see from the image above, the site has loaded in Enterprise Mode (this is clear because the of the little blue icon that appears next to the URL). This icon only appears when you select Enterprise Mode as a compatibility mode, it does not appear if you select a document mode. You can still confirm that it has worked by browsing to the site and pressing F12 to open the Developer Tools, then selecting the Emulation tab. In here you will see that the Document mode and Browser profile are configured as you specified in the site list.

Bonus cool stuff: Google Chrome also has a version of this, called Legacy Browser Support. This is particularly cool because you can configure it with Group Policy and it can use the same site list as Edge and IE11, so no need to maintain separate lists! Click here to learn more about Google Chrome Legacy Browser Support for Windows.

Making iSBEM and Jet Reports work in Windows 10

This may be quite a niche post, but if it helps just one person overcome a “run-time error 5” whenever they try to run one of the iSBEM databases or an “Access Denied”¹ error when trying to run a report powered by Jet Reports then it’s worth it!

In Windows 10 the built-in antimalware solution, Windows Defender, has a feature known as Windows Defender Exploit Guard. You can read up about this feature in more detail here, but one of its features in particular, the attack surface reduction rules, can sometimes prevent certain behaviour working in Microsoft Office applications.

Looking more closely at the attack surface reduction rules, you can see that a few of them are tailored specifically at Microsoft Office applications. In my experience the rule “Block all Office applications from creating child processes” can prevent the external processes needed by iSBEM and Jet Reports from running, which causes the errors mentioned above. You can quite easily check if this is the case by attempting to run an iSBEM database or Jet Report and getting the error, then open the Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational and looking for any warning or error level events that indicate that Windows Defender blocked the process from running.

If you do find the block event in the Event Viewer, you can create an exclusion to prevent it from being blocked. This can either be done in Group Policy or PowerShell. Open Group Policy editor and navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Defender Antivirus > Windows Defender Exploit Guard > Attack Surface Reduction. In here, one of the policies that can be configured is “Exclude files and paths from Attack Surface Reduction rules”, and you can use this to add your exclusions. You can use wildcards and environment variables to ensure the exclusions you add will work regardless of where they apply (for more details on that see this article). Try to make your exclusions as specific as possible so that you still get as much protection from Windows Defender Exploit Guard as possible!

If you wish to add exclusions using PowerShell, you should use the following command:

Add-MpPreference -AttackSurfaceReductionOnlyExclusions "Path to exclude"

For example, to unblock the iSBEM database you may use the following exclusion:

Add-MpPreference -AttackSurfaceReductionOnlyExclusions "%SYSTEMDRIVE%\NCM\iSBEM_v5.6.a\iSBEM_v5.6.a.mdb"

With that in place, test running the database again and continue to monitor the logs in Event Viewer until all blocks have been identified and exclusions created.

¹Of course an error like Access Denied isn’t necessarily being caused by Windows Defender, it could actually be a permission issue.

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: