Purpose

The purpose of this document is to instruct how to run a diagnostic patch scan when you are unable to perform a DPDTrace for a detection issue.

Overview

1. Go to Tools > Options > Logging in your console and set the Logging Levels to "All" and check the "Diagnostic patch scanning" checkbox.
   Note as the message below the Diagnostic option says, you should only turn this option on at the request of Support.

  2. Save your changes and select to restart the service now then close your console, then stop the Ivanti Patch for Windows Servers Console Service.

   3. Go to C:\ProgramData\LANDESK\Shavlik Protect\Logs and delete or move the contents of the directory.

   
  4. Restart the console service from step 2 and then open your console and scan the machine that Support has requested the diagnostic scan for using the scan template that Support specifies. For instance, if the problem patch on the machine is a security patch, you would use the security patch scan template.

   5. Save a screenshot of your scan results (similar to the screenshot above showing the machine name, definition date, scan template, Bulletin ID, and Qnumber of the patch having the issue).

   6. Go to Tools > Options > Logging and uncheck the Diagnostic Patch scanning checkbox and save your changes.

   7. Zip up the contents of the C:\ProgramData\LANDESK\Shavlik Protect\Logs folder.

   8. Send the zipped Logs folder from step 7 and the screenshot from step 5 to Support.

Additional Information

You will still need to obtain Registry Exports from the problem client machine to send to Support along with the Diagnostic Patch Scan or DPDTrace. You will find instructions for obtaining these Registry Exports here Batch File for Obtaining Registry Exports for Detection Related Issues

Affected Products

Ivanti Patch for Windows Servers 9.3

Purpose

This document contains instructions on how to add patches released between specifics dates to a Patch Group using PowerShell and the API feature.

Overview

Basic Instructions:

     1. Download AddPatchesToPatchGroupUsingDateRange.zip from this document. (download link)

     2. Extract the contents of the .zip file to a folder on the console server.

     3. Read Disclaimer.txt.

     4. Open PowerShell as an administrator.

     5. Change directory to the extracted location.

     6. Execute the following to get help. This will provide parameters and instructions on how to use the PowerShell script.

Get-Help .\AddPatchesToPatchGroupUsingDateRange.ps1 -full

Examples:

Add all patches released between two dates.

.\AddPatchesToPatchGroupUsingDateRange.ps1 "Test" "1/1/2018" "1/31/2018" "ServerName\SQLInstance" "MyDatabase"

Add all patches released within the last 30 days.

.\AddPatchesToPatchGroupUsingDateRange.ps1 "Test" ((Get-Date).AddDays(-30)) (Get-Date) "ServerName\SQLInstance" "MyDatabase"

Add security and non-security patches released within the last 30 days

.\AddPatchesToPatchGroupUsingDateRange.ps1 "Test" ((Get-Date).AddDays(-30)) (Get-Date) "ServerName\SQLInstance" "MyDatabase" "0, 1, 4"

Add .NET and Java patches released within the last 30 days

.\AddPatchesToPatchGroupUsingDateRange.ps1 "Test" ((Get-Date).AddDays(-30)) (Get-Date) "ServerName\SQLInstance" "MyDatabase" -productList ".net|Java"

Add all patches except .NET and Java released within the last 30 days

.\AddPatchesToPatchGroupUsingDateRange.ps1 "Test" ((Get-Date).AddDays(-30)) (Get-Date) "ServerName\SQLInstance" "MyDatabase" -productList ".net|Java" -excludeProductList

Additional Information

API Quick Start Guide

Affect Product

Ivanti Patch for Windows Servers

Purpose

This document provides guidance to running a DPDTrace on servers with no internet connectivity or other issues preventing the download of WindowsPatchData.zip data file.  This file is need when using the 9.2 scan engine in the DPDTrace Tool.

Description

You attempt to run a DPDTrace following the instructions from this document:  DPDTrace Logging Tool Used For Patch Detection Issues

The DPDTrace fails to scan the target machine with this error in the ErrorA.txt file:  Could not download file (.\WindowsPatchData.zip) from URI 'http://xml.shavlik.com/data/WindowsPatchData.zip

Cause

The DPDTrace tool is unable to download the WindowsPatchData.zip file from the internet.  This could be caused by no internet connection, firewall, proxy or some other setting/device on your network/server.

Resolution

• Correct the internet connection issue.
• Manually down the WindowsPatchData.zip file from http://xml.shavlik.com/data/WindowsPatchData.zip(right-click save link as) then place the file in the DPDtrace\HF7B folder.

Additional Information

This issue may also be related toDPDTrace Tool Fails To Scan Target Machine With: Could not download file (.\hf7b.xml) from URI 'http://xml.shavlik.com/data/hf7b.xml

Affected Product(s)

DPDTrace Tool: DPDTrace command line logging tool used for patch detection issues

Purpose

This document outlines how to scan and show only specific patches in the results, or how to scan and not include certain patches in the results in Ivanti Patch for Windows Servers..

Symptoms

While scanning, certain patches are offered that are not desired.

Adding Patches to a Patch Group

1. To scan or exclude specific patches, begin by assigning the desired patches to a Patch Group. Navigate to View > Patches.

2. Locate the specific patch by searching or filtering.

3. Right click on the patch, chooseAdd to Patch Group, then choosing New Patch Group.

4. The patch a has been added to the Patch Groups tab below the search window.

5. Next create a newPatch Scan Template.

Selecting to Include the patches in your patch group (specifically scan for)

1. In thePatch Scan Templatewindow, enter aNameandDescriptionto identify the scan template. UnderBaseline or Exceptions, select Baseline and check your Patch Group.
2. Scan using theScan Templatecreated. Results will only show those patches included in thePatch Group.

Selecting to Exclude the patches in your patch group

1. In thePatch Scan Templatewindow, enter aNameandDescriptionto identify the scan template. UnderBaseline or Exceptions, select Exceptions and check your Patch Group.

     2. Scan using theScan Templatecreated. Results willexcludethose patches in thePatch Group.

Related Articles

How To: Include or Exclude Specific Patches in Scan Results in Shavlik Protect

Additional Information

Important 9.2 Upgrade Information: Review Your Patch Scan Templates And Patch Groups

Affected Product

Ivanti Patch for Windows Servers 9.3.X

Purpose

This documents details how to identify and resolve the error "An error (1332) occurred while enumerating the group membership. The members SID could not be resolved.

Cause

A member (domain user) of the local Administrators group may have been deleted from Active Directory and the account name could not be enumerated.

Solution

On the local machine, delete all domain members that do not exist in Active Directory from the following groups:

• Administrators
• CCS Service Accounts
• ESM

Additional Information

The Microsoft tool PsGetsid allows you to translate SIDs to their display name and vice versa. It works on builtin accounts, domain accounts, and local accounts. PsGetsid can be downloaded here: PsGetSid - Windows Sysinternals | Microsoft Docs

Affected Products

Ivanti Patch for SCCM

Purpose

This documents details how to disable Automatic Updates in Windows 10 build 1709 through a GPO

Solution

Steps for single computer:

1. Click Start, and then click Run.

2. Type gpedit.msc, and then click OK.

3. Expand Computer Configuration.

4. Right-click Administrative Templates, and then click Add/Remove Templates.

5. Click Add, click Wuau.admin the Windows\Inf folder, and then click Open.

6. Click Close.

7. Under Computer Configuration, expand Administrative Templates, expand Windows Components, and then expand Windows Update.

8. To view the policy settings, double-click the Configure Automatic Updatespolicy.

9. To turn on Automatic Updates, click Enabled or to turn off select Disabled

Steps for multiple computers:

1. From the server, click the "Start" button and select "Programs" > "Administrative Tools" > "Active Directory Users and Computers."

2. Right-click the domain name whose settings you want to change and select "Properties." Select the "Group Policy" tab.

3. Highlight the domain policy you wish to modify, which will typically be the default group policy, and then click the "Edit" button.

4. The Group Policy Object Editor will now be open. In the left window, navigate to "Computer Configuration" > "Administrative Templates" > "Windows Components" > "Windows Update."

5. In the main frame, double-click the option "Configure Automatic Updates."

6. Select "Disabled" to turn off automatic updates.

Affected Products

Windows 10 Build 1709

Disclaimer

Please read this disclaimer before using this tool:  LANDESK Share IT Disclaimer

Description

We created a GUI tool to simplify diagnostic scanning to troubleshoot patch scan issues.

The DPDTrace GUI interface requires .Net 2.0 or greater to work.

How to use the DPDTrace GUI

1. Download the latest version of the DPDTrace GUI. Download Link
2. Extract the DPDTrace.zip to the desktop of the machine you will scan from.  This can be on a server remote to the target machine or on the target machine itself.  Support may specify where to scan from depending on the issue being diagnosed.
3. Open the DPDTrace GUI by double-clicking DPDTraceGUI.exe from the extracted folder.

     4. Choose Local to scan the local machine. The IP address or the Machine Name of the local machine will automatically populate.

     5. Choose Remote to scan a remote machine. You will need to provide a valid Machine Name or IP Address to scan.

     6. Enter a username with administrator access to the target machine.

          a. The format must be DomainName\UserName or MachineName\UserName depending on how you are authenticating to the target machine.

     7. Enter a valid Password. You can choose to un-check the Hide option if you wish to see your password for troubleshooting purposes.

Protect Version: (Protect Customers)

     8. Choose the Protect scan engine version to be used during the scan.

          a. The GUI defaults to 9.2.5112 and 9.3.4510, it is OK to leave the default selection and often a good idea since it provides cross engine version data..

OEM Version: (OEM partners)

     9. Choose the OEM scan engine version to be used during the scan.

Patch Type:

     10. Choose Patch Type to be used during the scan.

          a. We highly suggest leaving the defaults of Security Patches and Non-Security Patches selected unless a support tech requests a change.

     11. Click Run to start the scan.

     12. You will see Command Prompt popups and popups for the Rename HF.Log utility during the scan process.  Do not close either these.

     13. All popup windows will close and a new popup will occur once the scan is complete.  Click OK.

     14. The scan diagnostic is complete and all of the trace logs, scan outputs and registry exports have been zipped to this folder:  C:\Users\UserName\Desktop\DPDTrace\SendToSupport

          a. The zip file will be named HFCLi_YearMonthDay.zip

     15. Provide this zip files to support!  If you have any issues attaching this zip to the case, please let the support tech know so they can provide you with more options.

Additional Information

A command line DPDTrace tool can be used by customers who cannot run this GUI version:  DPDTrace command line logging tool used for patch detection issues

Purpose

This document outlines how to resolve an issue where "Ivanti Patch" is not accessible in the SCCM console.  Access fails with the error "Failed to connect to specified WSUS server: The server could not be contacted."

Symptoms

When you open Ivanti Patch for SCCM you receive the error "Failed to connect to specified WSUS server: The server could not be contacted."

The "Ivanti Patch.log" shows the error below.

Solution

• You will need to completely remove the Patch for SCCM add-on using the steps below (not just uninstall).

       How to Completely Remove Patch for SCCM

• Then reinstall the application using the most recent version found here.

Affected Product

Ivanti Patch for SCCM 2.x

Purpose

This document walks you through completely removing the Ivanti Patch for SCCM or Shavlik Patch for SCCM add-on.

Backup your custom private filters

• Your filters will be in one of two locations.

                   Version 2.4+ location: C:\Users\<your user>\Ivanti\Patch\SmartFilters.xml

                   Version 2.3 location: C:\Users\<your user>\Shavlik\Shavlik Patch\SmartFilters.xml

• Copy the SmartFilters.xml file to another location.

Uninstall the Add-on

• Uninstall the add-on through Programs and Features
• Delete the following locations if they exist
  • C:\Users\<your user>\Shavlik\Shavlik Patch
  • or C:\Users\<your user>\Ivanti\Patch
  • and
    • C:\ProgramData\Shavlik\Shavlik Patch
    • Or C:\ProgramData\Ivanti\Patch
      

• Back up the registry
• Delete the following registry keys
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S 1 5 18\Components\2D4D8347E52FE94518115A91BD9F5D3F
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S 1 5 18\Components\A04FF52B0811B3A4CB9490DE731F14AF

Related Articles

Ivanti Patch for SCCM: Root element is missing.

Affected Products

Ivanti Patch for SCCM

Shavlik Patch for SCCM

Purpose

This document covers the minimum account privilege requirements for using the Patch for Windows SQL database.

Description

Below are the privileges (roles) required within SQL for a user in possible scenarios:

Database Creation:
New installations of the Patch for Windows database require an account that has at least the DB_Creator role.

If the account has nothing else but DB_Creator it will give the account the proper rights when it creates the database.  So for situations where you have a DBA involved you can have them add a windows user to SQL with DB_Creator, Patch for Windows can create the database, then after completion the DBA can remove DB_Creator from that user.

Console User:
Any Patch for Windows user must have the following roles assigned for the Patch for Windows database to use the product:

db_datareader

db_datawriter

STCatalogUpdate

STExec

This must be configured for each user who will authenticate with the Patch for Windows database. 

Upgrade Rights:
When we upgrade the product there are typically schema changes to the DB.  These changes require additional rights that are not required for day to day usage of the product.  Ensure that you are using an account with this level of rights, otherwise the DB upgrade will fail.

To successfully perform an upgrade of the Patch for Windows database the following roles will be required:

db_securityadmin

db_ddladmin

Example of how you would see this in SQL Server Management Studio. In this example, the console database is named Protect:

Additional Information

More information from the Patch for Windows product documentation:

SQL Server Pre-Installation Notes

SQL Server Post-Installation Notes

The ability to check these privileges will require a DBA or the use of SQL Server Management Studio.

Affected Product(s)

Ivanti Patch for Windows

Purpose

This article provides a list of URLs that may be required to download catalog content and patches when using Shavlik Patch for Microsoft System Center and Ivanti Patch for SCCM.

Description

The following URLs may be used to download updates and must allowed through firewalls, proxies and web filters.

Additional Information

• license.shavlik.com is required for activation the license on the product.
• If using the Shavlik Patch plugin with SCCM or Ivanti Patch for SCCM, you may also want to review the following for certificate site requirements:  Certificate verification sites to allow for Shavlik Patch
• To obtain the IP for vendor sites you can ping the vendor site or contact the vendor to obtain this information. It may be easier to create an exception for an entire domain rather than entering all specific URLs, you can usually do so by entering the exception in this format: *.domain.com.

Affected Product(s)

Ivanti Patch for SCCM

Shavlik Patch for Microsoft System Center

Overview

This document provides a list of required URL addresses for Shavlik Protect and Ivanti Patch for Windows Servers to allow:

• Patch executable download.
• Patch content definition download.
• Online license activation or license refresh.
  
• Home page RSS feed.
  
• Product check for update.
  

URL List

The following URLs may be used to download updates and must allowed through firewalls, proxies and web filters:

Additional Information

• To obtain the IP for vendor sites you can ping the vendor site or contact the vendor to obtain this information. We are unable to provide a list of IP addresses due to the varied dynamic IP addresses being used by the vendors. It may be easier to create an exception for an entire domain rather than entering all specific URLs, you can usually do so by entering the exception in this format:
  • *.domain.com.

Affected Product

Ivanti Patch for Windows Servers

Purpose

This document outlines the steps necessary to ensure that Ivanti Patch for Windows can make use of TLS 1.2 when TLS 1.0 and TLS 1.1 are disabled.

Symptoms

When TLS 1.0 and TLS 1.1 are disabled, the Deployment Tracker will remain stuck at "Scheduled" or Executing".

Cause

The target machine has a process to send status updates back to the console. If TLS 1.2 isn't properly configured on the client machines and the protect console, these updates will fail to reach the console.

Resolution

1. SQL Server needs to be updated per https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server 
   
2. Follow Microsoft recommendations outlined here: Microsoft Security Advisory 2960358
   
3. For machines running Windows 7, 2K8R2, or 2K12, follow the instructions in https://support.microsoft.com/en-us/kb/3140245 to create the needed registry key and then install patch MSWU-1964.

Registry changes will need to be made to both client machines, and to the Ivanti Patch for Windows console.

Additional Info

This document explains how to deploy registry changes via group policy: https://technet.microsoft.com/en-us/library/cc753092(v=ws.11).aspx

Affected Product(s)

Ivanti Patch for Windows 9.3+

Symptoms

• Agents attempting to patch machines fail.
• The agents are unable to find and download the .MSU patch files from HTTP-configured distribution servers.
• On the UI of the target machine in the Patch tab, you see the error:
  
  Cannot download patch

Cause

This issue caused by the IIS MIME type extension for MSU not being configured correctly.

Resolution

To resolve this issue, configure the MIME Type extension for MSU on the IIS Server.

Note: If you are not using the vCenter vProtect Console patch repository, support for configuration of the the HTTP/HTTPS distribution server is not provided by VMware.

• On Windows 2003 server:
  1. On the core server, launch Internet Information Services Manager.
  2. Navigate to the Default Web Site.
  3. Right-click the Default Web Site and select Properties.
  4. Click the HTTP Headers tab, then click MIME Types.
  5. Click New.
  6. Enter MSU for the file extension, and application/octet-stream for the MIME Type.
  7. Restart IIS by clicking Start> Run and entering iisreset.
     
     
• On Windows 2008 Server:
  1. On the core server, Launch Internet Information Services Manager.
  2. Navigate to the Default Web Site and select it.
  3. Double-click MIME Types in the middle panel.
  4. Click Add.
  5. Enter MSU for the file extension, and application/octet-stream for the MIME Type.
  6. Restart IIS by clicking Start> Run and entering iisreset.

Products

Shavlik NetChk Protect

Shavlik NetChk vProtect

Product Versions

Shavlik NetChk Protect 7.8.1340

Shavlik NetChk Protect 7.8.1388

Shavlik NetChk Protect 7.8.1392

Shavlik NetChk vProtect 7.8.1340

Shavlik NetChk vProtect 7.8.1388

Shavlik NetChk vProtect 7.8.1392

Symptoms

1) Updates published using Patch for SCCM are not showing up in 'All Software Updates' within the SCCM console.

2) When you are about to publish updates via Patch for SCCM, you see a message listed; "Some of the selected updates may not synchronize."

'Click for details' will show a list of updates you are attempting to publish that 'may not synchronize with the current Software Update Point configuration.'

Cause

There are two possible causes.

1) You have not performed synchronization with the WSUS server.

2) In System Center 2012 R2 Configuration Manager you need to update your Software Update Point to ensure you're syncing required vendors and locally published packages.

Resolution

There are two possible resolutions.

1) You need to ensure you've successfully performed synchronization with the WSUS server.

You may just need to perform the sync, or there may be a problem during the synchronization process that is causing the failure.

Refer to the wsyncmgr.log from C:\Program Files\Microsoft Configuration Manager\Logs.

Log on to the WSUS server, go to Admin Tools > Windows Server Update Services. Expand the WSUS server, then click on Synchronizations. You should be able to see a history of synchronizations here. (It may take quite some time to load.)

2) In System Center 2012 R2 Configuration Manager you need to update your Software Update Point to ensure you're syncing required vendors and locally published packages.

To check this:

• Within the System Center Configuration Manager console:
  • Go to Administration
  • Expand Site Configuration
    • Click Sites
    • Right click on your primary site > Configure Site Components > Software Update Point
      
  • Go to the Products tab.
    • Ensure to put a tick next to any newly added products and Local Publisher.
    • While in here it's worth double checking what you have set up under Classifications, Languages, Sync Settings, and Sync schedule as well.
      
    • Perform synchronization with WSUS again.

Additional Information

See the following Microsoft articles for additional information about SUP (Software Update Point):

About the Software Update Point

How to Configure the Software Update Point

Affected Product(s)

Ivanti Patch for SCCM

Overview

These documents provides information about the End of Life policy for legacy Shavlik products, VMware branded versions of the same product lines and legacy Shavlik and HEAT OEM products that are now a part of the Ivanti family. The Ivanti Product Support Policy applies to the products released under the Shavlik or HEAT brand name. The Shavlik Product Support Policy applies to the products released under the Shavlik and VMware brand names. All dates presented in this document are in the ISO developed international format. This format uses a numerical date system as follows: YYYY-MM-DD where YYYY is the year, MM the month and DD the day. The information contained herein is believed to be accurate as of the date of publication, but updates and revisions may be posted periodically and without notice.

Legacy Shavlik products, VMware branded versions of the same product lines:

End of Life Information for Products Powered by Shavlik

Legacy Shavlik and HEAT OEM products that are now a part of the Ivanti family:

End-of-Life Information for OEM Products Powered by Shavlik and HEAT

Purpose

To outline the process for deploying Windows 10 build upgrades in Patch for Windows Servers (PWS) - build upgrades up through build 1809 are currently supported.

Deployment of Windows 10 build 1511, 1607, 1703, 1709, 1803, or 1809 applies to systems with a Windows 10 OS already installed. The deployment will not work for systems with an OS previous to Windows 10.

Description

What considerations must be taken into account prior to deploying Windows 10 build upgrades?

• Encryption such as BitLocker must be disabled for the deployment to be successful.  The machine must be able to fully reboot on its own to complete the deployment properly.
• The deployment of the Windows 10 build upgrade is effectively a full operating system install, which includes all of the potential risks of a traditional OS upgrade. This can include, but are not limited to:
  • Blue screens (BSOD)
  • Data loss
  • Loss of existing settings
  • Program incompatibility
• Driver incompatibility can cause the update to fail. The Windows 10 app can help find some of these problematic drivers. If this is not available on the endpoint, see here for assistance.
• There are multiple versions of the 1511 ISOs. Older versions are more likely to cause blue screens, or otherwise fail. It is strongly recommended to use the most recent published version of the ISO.
  • The first release ISOs from November 2015 caused a BSOD or install failures on a number of systems. The install will then revert the machine to RTM. None of the defective ISO files made the machine unusable.
• Both the endpoint receiving the update and the console deploying it need to have sufficient hard drive space.
  • The PWS console needs to have at least 5GB  free to download the ISO
  • The endpoint that is receiving the update needs to have at least 10GB free, but 20GB is recommended
• When patching from a unpatched RTM version of Windows 10 to 1607, our internal QA found that there is a high chance of a BSOD occurring and the update reverting to the RTM state. This can be avoided by fully patching the Windows 10 RTM machine, rebooting, and then applying the 1607 update.
• This deployment method only works to upgrade an existing Windows 10 installation.  PWS cannot upgrade an older OS to Windows 10 (e.g., Windows 7 > Windows 10).

Step 1: Obtain the ISO

• The most recently published ISO that is needed for the build upgrade deployment can be found in two places, depending on which edition needs to be deployed:
  • For Home and Pro endpoints, download the Media Creation Tool from Microsoft Tech Bench and follow the directions under "Using the tool to create installation media". Select the option to download the ISO file. "Windows 10" is the Edition for Windows 10 Professional, "Windows 10 Home Single Language" is the Edition for Windows 10 Home. This will download the most recent ISO available.

• For Enterprise and Education, obtain the correct ISO from MSDN or Microsoft Volume Licensing
  

Step 2: Prepare the ISO

• The ISO must be renamed to match the Shavlik naming scheme which includes the OS architecture, the edition, locale (if not en-us), and version. See below for examples:
  • Windows10x64Enterprise1703.iso
  • Windows10x64Enterprise1709.iso
  • Windows10x64Professional1709.iso
  • Windows10x86Education1709.iso
  • Windows10x64ProfessionalN1709.iso
  • Windows10x64Enterprise1803.iso
  • Windows10x64Professional1803.iso
  • Windows10x64Enterprise1809.iso
  • Windows10x64Professional1809.iso
• To find out exactly which naming scheme to use, scan the endpoint that will be receiving the update with the PWS console or you can look up the update in View > Patches. Under "Bulletin Details", the File Name will show what the ISO needs to be renamed to. See below for an example:

• The renamed ISO must now be placed in the patch repository on the PWS console. The default location for this is: "C:\ProgramData\LANDESK\Shavlik Protect\Console\Patches", but you can find where your patch repository location is set in Tools > Options > Downloads.
• For customers using distribution servers or agent-based patching, move the renamed ISO to the according Patch Store location
  

Step 3: Deploy the ISO

• Perform a patch scan of the desired machines. Once the scan is complete, go to the scan results and expand the Service Pack Missing list. For example:

• Select the 1809 (or 1511/1607/1703/1709/1803 depending on which version is being deployed) option to deploy the update (do not select TH2). If the TH2 option is selected, or if the necessary ISO file for the build you are pushing is not named correctly or is not placed in the Patch Store, then errors will occur. For example:

• The PWS deployment will verify different aspects of the deployment before staging it on the endpoint. It will verify that:
  • The language of the ISO dropped into that Patch Store matches the language of the endpoint's OS
  • The remote registry setting is saved
  • The status of the built-in Admin account (enabled or disabled) is saved
  • The endpoint receives all necessary scripts and files for the deployment
• The deployment of one of these updates can take up to and possibly longer than 3 hours. During this time the endpoint will boot to an installation environment after the ISO is successfully staged. PWS has no way of interacting with this environment. If something goes wrong, the Windows 10 installer will attempt to roll back to the previous OS state, but this is not guaranteed.
• Once the deployment has been initiated, PWS will show the screen below. Since the deployment of these updates boots into a OS install environment, PWS cannot get any feedback from it. If the description field returns 0, then all pre-deployment checks have passed and the target machine has rebooted into the OS install environment.

Step 4: Verifying the Deployment was Successful

• Once the endpoint has finished the install, use the console to re-scan the target. If the update deployment was successful, the re-scan will not show any missing service packs. See image below:

• The 1511/1607/1703/1709/1803/1809 deployment can also be verified by going to the target and running the "winver" command. The "About Windows" pop up should show Version 1511, 1607, 1703, 1709, 1803, or 1809 depending on which was deployed.

Affected Products

Ivanti Patch for Windows Servers 9.3.x

Purpose

The purpose of this document is to discuss how to resolve an error when opening the Ivanti Patch for SCCM plugin that states 'In order to use Ivanti Patch for SCCM, Full Write privileges are required on the WMI namespace root/SMS/site_xyz and its sub-namespaces'.

Symptoms

WMI permissions to the namespace is being denied for the logged on user.

Access denied Ivanti Patch 11/23/2018 12:08:58 PM 1 (0x0001)

In order to use Ivanti Patch for SCCM, Full Write privileges are required on the WMI namespace root/SMS/site_xyz and its sub-namespaces. Ivanti Patch 11/23/2018 12:09:16 PM 1 (0x0001)

Resolution

1. Open a run window (Win+R), and run wmimgmt.msc

2. Right-click on WMI Control (Local), then click on Properties.

3. Once Properties has loaded, click on the Security tab.

4. Expand Root, then expand SMS. Under SMS, the site_xyz folder should be listed. Highlight the site_xyz space.

5. Click Security. In the Security for ROOT\SMS\sote_xyz window, click Add.

6. In window, type in the desired username, hit Check Names to verify the account. Then click OK.

7. Once added, check the box for Full Write under Permissions. This will add the Partial Write and Provider Write permissions as well. Click Apply to save changes.

Affected Product

Ivanti Patch for SCCM 2.4+

Purpose

This procedure shows how to deploy a certificate to multiple computers by using the Active Directory Domain Services and Group Policy Object (GPO). This procedure is useful each time a certificate needs to be pushed to clients.

For example, when you need to push a WSUS self-signed or CA-signed certificate to all of your clients before they can trust the published third party packages.

Steps

1. Open the Group Policy Management Console.
2. Find an existing or create a new GPO that contain the certificate settings. Ensure that the GPO is associated with the domain, site, or organizational unit whose users you want affected by the policy.
3. Right click the GPO, and then select Edit.The Group Policy Management Editor opens, and displays the current contents of the policy object.
4. In the navigation pane, open Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Publishers.
5. Click the Action menu, and then click Import.
6. Follow the instructions in the Certificate Import Wizard to find and import the certificate.
7. If the certificate is self-signed, and cannot be traced back to a certificate that is in the Trusted Root Certification Authorities certificate store, then you must also copy the certificate to that store. In the navigation pane, click Trusted Root Certification Authorities, and then repeat steps 5 and 6 to install a copy of the certificate to that store.

Affected Product(s)

• All WSUS versions
• All SCCM versions

Symptoms

When performing a scan you get Error Code 830, unable to connect to the virtual server.

Cause

When scanning a virtual machine VMware Tools need to be installed and on a supported version.

Resolution

• Install or update VMware Tools, and then refresh the ESXI Hypervisor in your machine group so it shows the VMware Tools current or supported. Run the scan again.

Or

• Update the password for the credentials you are using for the vsphere/hypervisor in the console.

Product

Patch for Windows Servers 9.X