Purpose

The purpose of this document is to resolve the issue where the Windows 10 machines will fail to scan even though Remote Registry has been enabled previously.

Symptoms

Even after enabling the Remote Registry service on Windows 10 client machines, machines fail to scan with Error 501.

Cause

Windows 10 will disable the Remote Registry service by default when the computer is in idle and the service is not being used causing agentless scans to fail.

Resolution

1. On the client machine, open up your registry editor by typing regedit in the start menu and hitting enter.
2. Make the following modification in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RemoteRegistry:

• Name: DisableIdleStop
• Type: REG_DWORD
• Data: 1

Affected Product(s)

Ivanti Patch for Windows Servers 9.3

Ivanti Security Controls

Hello,

I'm new to the Patch for Windows product, but I'm liking it. I'm deploying software to new endpoint devices with Ivanti Automation and use the Ivanti Patch for Windows connector in Automation. The problem I run into is that when I install multiple endpoint devices at once the run book tasks which run on the single Patch for Windows console wait on each other to finish.

The question I have how do people manage unattended patch deployment during the unattended installation of endpoint devices?

Thank you in advance.

Kind regard,

Tom

Hi All,

Hoping someone has came across this before and is fairly straight forward. I work for an MSP and run Ivanti on a number of estates of which this specific problem has shown on a number of them so its not isolated to 1 installation.

I try to run scheduled tasks where possible but randomly come across this problem,

ISSUE:

Schedule: 4x Recurring Scans, 4th sat of the Month @ 07:15:00, All Scans have an immediate Staging and Deployment Set.

Scan Results: Scan's show as run but come back with Zero results and Displaying IncompleteResults

Logging:

The only Console Logging error I can see is the following: ST.TaskHost

2018-11-24T07:15:21.2083434Z 0008 E WorkItemCatalogDataDownload.cs:112|Error: File not downloaded: WindowsPatchData.zip

Error reason: The process cannot access the file because it is being used by another process.: http://content.ivanti.com/data/WindowsPatchData.zip

Could this be an Error Due to 4 Jobs running at the same time conflicting with each other?

Any insights or additional information would be greatly appreciated.

i have not been able to isolate this to any singular cause.

Malachy

Morning All,

Wondering if any one has came across the following error:

E PatchRescanEngine.cs:199|Patch scan failed (80004005)

This was pulled out of T.EnginSeHost.managed.SYSTEM@NT AUTHORITY.log

Noticing this as a single scheduled job was run over night out of 15+ machines in the group only 2 where scanned then this erroer was dropped in the log,

unable to come across any details on this.

Thanks

Malachy

I have a vCenter server that has both Servers and Clients.  I would like to be able to partition these out in Shavlik but have it do it automatically like using Organizational Unit.  Does anyone have any recommendation for me?  I know I can manually assign the computers to machine groups or leave them all in a single machine group but neither are what I want to do. 

Organizational Units seem to work OK, but I lose the functionality that having them in as vmware machines allows.

TIA for any help you can provide.

Good morning all,

We had a non-agent based job scheduled for 3:30AM this morning that appears to have started more towards 5:00AM. This caused late reboots and interrupted an important system this morning. What log would I check to best  discover the reason for the delay??

Thanks,

Tom Petrosinelli

Purpose

This document will show you how to run/schedule the "Console Clean Up" ITScript to clean up your Patch Repository

The Patch Repository location is the path listed under "Patch download directory" in the Downloads tab under Tools > Operations (Tools > Options in 9.3)

The default location is C:\ProgramData\LANDesk\Shavlik Protect\Console\Patches

Symptoms

Your patch repository is taking up too much storage space storing old patches you no longer need

Steps

Go to Manage > ITScripts, and when it is done updating, close the pop-up if it did not close automatically

Under the "Maintenance" category, highlight "Console Clean Up" and click "Approve"

Then go to Tools > "Run console ITScripts"

The values listed are in Days (the default value for both is 180 days) - if you want to modify a value, double-click on the parameter you want to change (patchAge/deploymentAge) and enter the desired value

When finished, press "Continue" to proceed to the scheduling options

Click "Run" to run immediately, or select the scheduling options you want and click "Schedule" (the "Run" button changes to "Schedule" when you select scheduling options)

Affected Product(s)

Shavlik Protect 9.2

Ivanti Patch for Windows  Servers 9.3

Hi there

We got a problem on several servers 2008 R2

the server have never been patched by ivanti before, only scanned, so here is the problem, when a scheduled job i executed,  the deployment tracker is showing executed 0 of 39  status "Deployment initializing"  and then nothing happens, it don`t create the C:\windows\Propatches   as well.  and no log entry as well

any suggestions for this problem

I am going to stand up a second console for our second data center.  We currently have a dedicated DB server and another server with with the patch installed on it.  The patch server acts as a distribution server also.

I found instructions for creating central and remote consoles.   If I turn our current Patch Server into a Central Console can I still run patch jobs from it?  Or do I need to add two new servers?

A new central console server
A new remote console server
Turn the current patch server into one of the console servers

Notice 12/06/2018

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 Patch Store location.
  
  • You cannot deploy ISO service packs with Cloud agents unless they are configured to download from a Distribution Server.

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

Symptoms

When running a batch file as part of a Custom Action, the deployment hangs and never completes.

Cause

When Patch for Windows Servers (PWS) builds a deployment, it creates a batch file that is copied to the target machine. This batch file contains all the information related to that deployment, including what patches should run and with what switches. It also includes any Custom Actions that the user defined. This batch file will be referred to as the PWS Generated Batch. When the PWS Generated Batch executes, it initiates each task sequentially going through the list (one task must finish before the next can begin). When the PWS Generated Batch calls the user's custom batch file, the PWS Generated Batch waits for the user's custom batch file to return an exit code to indicate it is done. If the user's custom batch file is not accessed with an appropriate command, it will not return the necessary exit code for the PWS Generated Batch to continue through its pending actions.

Solution

If the Custom Action batch file is going to run an action that following actions are dependent on (example: batch file stops a service so a custom action can run a .exe), then utilize the CALL command.
The call command will allow the custom batch file to return an exit code to the PWS Generated Batch so it can continue on its jobs, once the custom batch file finishes.

Example:

Call %PATHTOFIXES%stop_services.bat

If the Custom Action batch file is going to present the end user with information that should stay open (example: a custom message that the batch file shows), then utilize the START command.
The Start command will begin the custom batch file, and once it has started, the PWS Generated Batch will continue without waiting for the custom batch file to close.

Example:

Start %PATHTOFIXES%show_warning.bat

These are CMD commands, not Ivanti custom commands. More info on CMD commands here: An A-Z Index of the Windows CMD command line | SS64.com

Related Documents

Custom Action - Using the Null Patch

Affected Product(s)

Ivanti Patch for Windows Servers 9.x

Ivanti Security Controls

Hi there,

is there a plan to add Citrix Workspace App to the product catalogue? This will replace the Citrix Receiver in the future and is used by some customers.

Regards

Alex

Any idea on how to troubleshoot this kind of issue.

The problem is cannot telnet 5120 from console to agentless machine.

But as per network team all port is all open.

Do I need to manually configure to open the port 5120 on the target machine?

I have just recently (today) taken over patching for an organization; the process at this point is something of a mess. I have done patching in other environments such as SCCM with WSUS/SCUP and back when Shavlik was a stand alone product, but am looking to quickly become acquainted with Ivanti. I have been looking for both best practice guides and step-by-step deep dives on configuring a Rollout Project (correct term?) for patching. I found a webinar from May of 2018 discussing best practices, but it is pretty high level. If anyone can point me to a link for documents (specifically the latter) I would be most grateful. I have until Sunday to get the system down, improve the process, and prepare patches for this organization's servers

When a user installs Chrome and does not have admin rights, the user is prompted and is allowed to install Chrome to c:\users\username\appdata\local\Google\Chrome\Application.  It appears that Patch for Windows does not see these Chrome installs and therefore doesn't patch them.  Is this something that can be fixed?  Thanks.  Paul

Path : C:\Users\wsatgk\AppData\Local\Google\Chrome\Application

  Installed version : 69.0.3497.100

  Fixed version : 71.0.3578.80

Ivanti patch for windows servers allows to configure emails on machine group, machine and deployment template settings when deploying patches.

Most of these email configurations only work on agentless deployment. Does any of these settings work on agent-based deployment?

Purpose

The Protect Cloud synchronization feature enables your agents to check in and receive policy updates from the cloud. This allows you to manage agents on machines that are not able to communicate directly with the console. This feature also provides you with the ability to install a Shavlik Protect Agent using the cloud.

Agents that are configured to use Protect Cloud will have two check-in options: they can continue to check in with the Shavlik Protect console, but they will also be capable of checking in and receiving policy updates via the cloud. This is particularly useful for disconnected agent machines that are away from the corporate network and unable to contact the console for updates. As long as an agent machine has Internet access, it will be able to send results and get updates using the cloud.

The following diagram illustrates the two agent check-in options:

FAQ

1) How does the cloud work?

The console makes changes to agent policies and syncs to the Protect Cloud server. The  Protect Cloud server is where Protect Cloud agents check in since they can't talk to the console. All patches that are needed are downloaded straight from the vendor's website.

2) How does a traveling worker get updates?

The cloud agent on the traveling worker's machine will first try to establish communication with the Protect Console in the domain even if its VPN. If that communication is not established, it will next try to connect to the Protect Cloud server and look for any updates to the policy. If there are updates, the policy change will be made to the Protect Cloud agent and if there are new patches they are downloaded straight from the vendor.

3) Is any activity from the Protect Cloud agent sent back to the console for reporting?

Yes, results will be sent back to the main Shavlik Protect Console, however it will take longer for those results to show up since there are more steps with the sync.

4) Will installing the Protect Cloud agent on a target machine take up another license seat?

No, since the machine was already used as a target machine either by being doing an agentless scan or if there was already an agent installed, it won't take up another license seat.

5) Does it cost more to use Protect Cloud?

No, this service does not cost any extra even if you are using Shavlik Protect Standard or Shavlik Protect Advanced. All you have to do is register your account by going into the Shavlik Protect Console and clicking on Tools > Operations > Protext Sync Cloud > Create a Protect Cloud account.

6) Can you initiate a scan from the console to the target machine through Protect Cloud?

No, you can only make changes to the Agent Policy and schedule the scan through that policy. The Protect Cloud agent is treated just like an agent on a target machine connected to the Protect Console and has all the same properties, except that instead of directly communicating to the Protect Console, it is instead communicating with the Protect Cloud server.

You can allow a user to initiate a task on their own. For more instructions on how to do this, please see the following article: Initiating a Task with an Off-Network Protect Cloud Agent

7) Is all the traffic encrypted between Console to Cloud and Cloud to Agent?

Yes, the Console and Agent talk to the Cloud so neither has to open an inbound port.  The Protect Cloud acts as the proxy between the two.  Communication between console\cloud and agent\cloud is HTTPS web service calls using a token to provide mutual authentication.  All policy and result data is encrypted so only the console and the agent can decrypt.  The Cloud cannot decrypt your data only ensure delivery to authorized agents\console.  All data is encrypted in transit and at rest.  Results are picked up every 15 minutes so there is only a small windows of the results data being at rest before the console picks it up.

8) How often does the Shavlik Protect Console synchronize with  Protect Cloud servers?

Every 15 minutes. This can be manually updated if the user needs a full sync by going into the Shavlik Protect Console and clicking on Tools > Operations > Protect Sync Cloud > Force full update now button.

9) Can I uninstall Protect Cloud agent but keep the Shavlik Protect agent still on the target machine without having to completely uninstall and reinstall the agent?

Yes, just go to the Shavlik Protect Console and change the Policy to not sync with Protect Cloud and update the policy on the target machine.

Affected Products

Patch for Windows Server 9.3+

I have a 2 domain network that is using Ivanti P4WS, on one of the domains most of the clients have recently stopped checking in to my Ivanti server, even manual check ins fail.  If I try to repush or reinstall the agent, it gets to 67% ("waiting for agent check-in") and eventually fails.

In either scenario, when I look in the STDispatch.log file, I am constantly seeing:

Authenticode.cpp:100 Verifying signature of C:\Program Files (x86)\LANDESK\Shavlik Protect Agent\STAgentUpdater.exe with CWinTrustVerifier,

followed by:

WinTrustVerifier.cpp:270 Certificate verification failed with error: -214676748.

CommandLineTask.cpp:473 Invalid executable 'C:\Program Files (x86)\LANDESK\Shavlik Protect Agent\STAgentUpdater.exe'. Application is not trusted by any OS signer.

I checked the properties of STAgentUpdater.exe, looked at the digital signatures, and verified the cert path was valid (the DigiCert Assured ID Root CA cert and the DigiCert SHA2 Assured ID Code Signing CA cert are both present and show up as OK when checking the digital signature path).  I've tried putting one of the computers in a separate OU to block all GPOs, and also tried putting it on the other domain where the agents are checking in fine, and either way the same errors keep occurring.  I've fully uninstalled the agent and all components, removed registry keys, and verified certificates are removed from the local machine cert store.

Disclaimer

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

Description

The DPDTrace tool provides diagnostic scan output for troubleshooting Windows patch detection issues.

How to use the DPDTrace GUI

1. Download the latest version of the DPDTrace GUI.  Download Here
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: (Ivanti Customers)

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

OEM Version: (OEM/SDK Partners/Customers)

     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 file to support!  It will not pass through email filtration, so please attach it directly to your case on the support portal using the Add Attachment button.
           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

Last build 9.3.4510 (9.3 Update 1) was released 10/02/2017. When is anew build or version coming out? Whats new features or fixed bugs will be included?