We currently are using agents on our desktops and manage all our servers as "agentless".
A question that came up recently to a very time sensitive high availability set of servers, is how resource intensive are security patch scans on the systems in a machine group? There is a concern that running scans throughout the day while these systems are needed could cause a theoretical slowdown. Let me know your thoughts and experiences!!
Running Ivanti Patch for Windows v9.3.0 Build 4510 with the database running on SQL 2008. We are wanting to move just the database to a new SQL 2014 server. Will this version of Ivanti P4W run fine with that version of SQL, or do we need to run the database in a different compatibility mode on the server?
Hi
Does Ivanti Patch for windows 9.3.0 Build 4440 support Server 2016 Core 1803
We seem to be getting results sometime and not others.
Found a few conflicting articles about this.
Jan 25 2018
May 4 2018
Ivanti 9.3 - Agentless Server 2016 Core and Server 2016 Nano Support
And if not what time frame are we looking at for support ?
We are currently looking to build about 30 Core servers?
Thanks
Steve
Message was edited by: Steve Mills
This document will explain how to set up Shavlik Protect Agents to automatically deploy service packs
1) Open your Agent Policy you would like to add the service pack task to or create a new agent policy by going to New > Agent Policy.
2) Click on the Patch Tab and then click on Add a Patch Task....
3) Name the new Patch Task. (Example: Service Pack Deployment)
4) Select a schedule that you would like the service pack to be scanned for and deployed. For the purpose of this article, we are choosing to use a schedule to automate the installation of service packs. You can leave the Use Schedule box unchecked and perform the service pack deployment manually through the agent in Machine View. More on that here: http://help.shavlik.com/Protect/onlinehelp/92/ENU/EN/Managing_Your_Agents.htm
5) Click on the Scan and Deploy Options tab (In Protect 9.1, this is in the drop down menu).
6) Choose a Patch Scan Template.
7) Select a Deployment Template.
Since service packs always require a reboot, we recommend to use the Agent Standard template, but if the machine is unable to be rebooted after Service Pack deployment, please be sure to use or create one that has a no reboot after post deployment.
8) You can choose whether to deploy patches at this time as well. For the purposes of this article, I have chosen not to include patches in my deployment and to only deploy service packs if they are missing.
Follow the notes below for more options and what the available options mean:
Deploy service packs | If you want the agent to be able to automatically deploy service packs that are identified as missing by the patch scan, enable this check box. When the agents perform a service pack deployment they will deploy only those service packs that are:
Service Pack Deployment Process If an agent machine is missing multiple service packs, only one service pack will be installed at a time. The patch task will begin by initiating the download of all missing service packs. Operating system service packs are downloaded at a higher priority, but whichever service pack gets downloaded first is the one that is first installed. After the service pack is successfully installed, the machine is restarted, rescanned, and the process is repeated until all service packs are deployed or until the daily limit is reached [see theLimit deployments (per day) option]. In addition, each patch task is allotted a 60 minute window to complete the download > install > restart > rescan process. (This is part of a two hour total maintenance window that is allocated for downloading missing service packs and patches.) Only those service packs that are successfully downloaded during this 60 minute window will be installed by the active patch task. If the patch task cannot finish downloading all missing service packs during the 60 minute window, the remaining service packs will be identified, downloaded, and installed the next time the patch task is run. The downloads occur in the background using idle bandwidth not being used by other applications. Foreground tasks such as Web browsing are not affected by the service pack download process. If an agent machine becomes disconnected from the network during a file download, the process will be suspended and will automatically resume where it left off when the network is available again. This technique is called checkpoint/restart and is extremely useful for machines that are frequently disconnected. |
9) Click Save and Update Agents button. If this is an agent policy already installed on target machines, then the target machines will check-in at this time if able to receive the new policy change. If this is a new Agent Policy, you will need to assign the policy manually. For more information on that process, consult the following: http://help.shavlik.com/Protect/onlinehelp/92/ENU/EN/Managing_Your_Agents.htm
10) At the next scheduled time for scan and deployment that you selected in Step 4, is when the service packs will be scanned for and deployed.
Scheduling and deploying service packs automatically is currently only available with a Shavlik Protect Agent. Agentless service pack deployment must be done manually.
For instructions on how to deploy a service pack agentlessly, follow this article: How To: Deploy a Service Pack to Multiple Machines
For guidelines on service pack deployment, consult the following article: Shavlik Protect Agentless Service Pack Deployment Guidelines
Protect 9.x
Ivanti Patch for Windows Servers 9.3
The head of IT wants a metric on how long it takes us to deploy critical and security patches after their release by the vendor. I dug through the canned reports and there was good info, but nothing that I saw that answered this question (unless I just missed it, which is very possible). Is there a way to pull this info from the tool?
This document provides a high level overview of how credentials work in Patch for Windows.
There are several sections to this article, each pertaining to agentless operations in Patch for Windows.
A more in depth explanation, as well as how Agents use credentials and helpful visuals, is available here: How Credentials Work in Patch for Windows
Scanning
When performing operations, Patch for Windows will attempt to authenticate to each machine using a variety of credentials and will do so using the following strategy:
Example: If machine-level credentials are not available but group-level credentials are available, the program will use the group-level credentials.
If neither of these credentials work, the scans and the power management tasks will fail.
One suggestion is to make your default credentials the same as the account credentials you typically use to log on to the program. This will eliminate problems that may occur if you forget to assign credentials.
Deployment
While scanning in Patch for Windows utilizes a failover sequence, but deployments do not.
If no credentials are available, or they fail, the deployment fails. Deployments will not attempt to use CLOUC or default credentials. Because of this, it's possible to scan successfully, but receive an access denied error upon deployment.
If you supply bad Individual Machine’s Lower Panel Credentials, it will fail over to CLOUC to get the machine resolution, but it will fail to copy the files over during the installation. The file copy happens in the Console Service and will use the Individual Machine’s Lower Panel Credentials.
Scheduled Scans
When scheduling a scan, Patch for Windows requires a "Scheduler Credential". This credential is not set in the Credentials Manager, but under Manage > Scheduled Console Tasks.
The scan uses the credentials associated to Scheduler Credential, not your currently logged on user or default credential
This credential is the identity Patch for Windows will assume to kick off the scan. As such, it must be a local Administrator, and it must be allowed to run scans under User Role Assignment.
This credential needs to be set while logged in as the user specified.
-Example: If the credential is domain\user1, then domain\user1 needs to log in to the Patch for Windows server, open the console, create the credentials, and assign them.
Scheduled Deployment
Scheduled Deployments will use credentials in the same manner as normal deployments.
Agent Installs From the Console
Currently Logged On Under Credentials (CLOUC) will be used if all those are not defined, and the copying of the files to the target will fail, because it is done in the Console service and it will use the credentials assigned to the machine)
Multiple Patch for Windows Administrators
When multiple users are given Administrator access to Patch for Windows, there are some considerations to take into account regarding credentials:
Additional Information
One particular part of credentials many people have issues with is Scheduled Scans. This is because scheduled scans are a scheduled console task, and require the scheduler credential to be properly set.
Of course, people want to know why things must be set the way they are. Here's the technical background behind why:
For more detailed information regarding credentials in Patch for Windows, please see How Credentials Work in Patch for Windows .
Patch for Windows 9.x
Protect 9.2
This document is meant to provide a full overview of how credentials are entered, used, and work within the Patch for Windows product.
The home page, machine groups and favorites can be used to initiate actions, patch scans, asset scans, power management, and to execute scripts. When performing these actions, Patch for Windows will attempt to authenticate to each machine using a variety of credentials and will do so using the following strategy:
Example: If machine-level credentials are not available but group-level credentials are available, the program will use the group-level credentials.
If neither of these credentials work, the scans and the power management tasks will fail.
One suggestion is to make your default credentials the same as the account credentials you typically use to log on to the program. This will eliminate problems that may occur if you forget to assign credentials.
When using a machine group to push install the Patch for Windows Agent service to connected target machines, the credentials used by the program follows the same strategy as above with one major exception -- integrated credentials will not be used. So the agent installation must be successful using machine-level, group-level, default, or explicitly supplied credentials.
When initiating a scan, a patch deployment or a power management action from Machine View or Scan View, the program will attempt to authenticate to the target machines using a variety of credentials and will do so using the following strategy:
Any manually or automatically assigned managed machine credentials (see the To Individual Machines in a Machine Group section in Supply Credentials for Machines (used if the scan credentials are invalid or missing, for example, if an agent performed the scan rather than the console)
Note: Integrated credentials will not work for deployments to offline virtual machines or for re-scans.
If neither of these credentials work then the action will fail.
When using Machine View or Scan View to push install the Patch for Windows Agent service to connected target machines, the credentials used by the program follows the same strategy as immediately above with one major exception -- integrated credentials will not be used. So the agent installation must be successful using managed machine credentials, default credentials, or explicitly supplied credentials.
The home page, machine groups and favorites can be used to initiate patch scans, asset scans, and power management actions and to execute scripts. When performing these actions, Patch for Windows will attempt to authenticate to each offline hosted virtual machine using the browse credentials.
When initiating a scan, a patch deployment or a power management action from Machine View or Scan View, the credentials that will be used to authenticate to an offline virtual machine depends on the power state of the machine when it was initially scanned.
If a machine was originally scanned in offline mode
The program will attempt to authenticate using the browse credentials.
If a machine was originally scanned in online mode
The program will attempt to authenticate using a variety of credentials and will do so using the following strategy:
If the following are available, try to authenticate using the credential with the highest precedence, where the precedence order is as follows:
The administrator credential from the machine group. If the administrator credential exists but fails, the default credentials will not be tried.
Default Credentials (used if the scan credentials are invalid or missing (for example, if an agent performed the scan rather than the console))
Note: Integrated credentials will not work for deployments to offline virtual machines or for re-scans.
If none of these credentials work then the action will fail.
The Define Credential dialog can be accessed anywhere a credential is used within the Patch for Windows interface (for example, from a machine group, from the Credentials Manager, etc.). It is used to specify a new user name and password pair that collectively define one credential. The credential is stored with strong encryption techniques. Only the administrator that creates the credential will be able to decrypt the credential and access it from within the program. If you elect to share the credential, however, it will be made available to other administrators as well as to Patch for Windows service components.
Note: Credentials may be automatically defined for you during a product upgrade or when importing a machine group. Any credentials that are found during these processes are preserved and will be assigned friendly names according to their usage. The term Discovery filter is the friendly name assigned by the program to a machine group credential that it identifies during an upgrade or import process. Feel free to change the name to something that more closely reflects the usage of the credential in your organization.
Name this credential so it can be used elsewhere | Provide a friendly name for this credential that describes exactly where it should be used. |
User name | Type a user name that has access to the machine(s). When specifying the user name:
|
Password | Type the password for the user. |
Verify password | Retype the password to verify you specified it correctly. |
Share this with background tasks, agents, and other features | If enabled, this credential will be available to all Patch for Windows administrators and can be used to specify credentials for service components within the program. The service components within Patch for Windows that require a shared credential include the following:
Why is it necessary to share a credential? Credentials are encrypted, so you must share a credential so that the service components can decrypt and access it when needed. Example: If you select Tools > Options > Proxy and attempt to assign Service credentials, only shared credentials are available for selection. The service must have a copy of the credential in order to decrypt it. Note: It is recommended that you create a service account to perform these service functions rather than using a domain administrator account. See Potential Security Implications When Sharing Credentials for more information. |
Note: Browse credentials are slightly different from the scan credentials described in this section. Browse credentials are used by servers, domains, and organizational units to enumerate machines but do not actually authenticate to the individual machines.
This section provides information on how to define new scan credentials and how to assign the credentials to target machines. Credentials consist of a user name and password pair used to authenticate the program to specified target machines. One credential can be associated with any number of operations or entities. The credentials are stored with strong encryption techniques and are not available to anyone except the user who provided them.
The scan credentials you supply will be used to access remote machines, perform any scans, and push any necessary files. The supplied credentials will NOT be used to:
Rather, the program uses the credentials of the currently logged on user to authenticate to resources on the local machine. Therefore, in order to perform tasks on the local machine, make sure you log on using an account that has administrator and local machine access rights.
The machine credentials that you supply are used to provide access to the remote machine and to push the necessary patch deployment files. The actual deployment, however, will be run under the remote machine's Local System account.
You use a machine group to initially assign scan credentials to target machines. You can assign credentials to individual machines, to all machines in a machine group, or both. After a machine has been scanned and is contained in Patch for Windows 's database of managed machines, you can use the Machine Properties dialog to assign different credentials if desired.
Important! If there are two or more administrators using Patch for Windows, each administrator should provide their own machine credentials.
To assign credentials to one or more machines in a machine group, in the bottom pane select the machines and then select Credentials > Set Admin Credentials.
On the Assign Credentials dialog, select from the list of available credentials or click New to define new credentials.
When credentials are applied to the selected machines, the icon in the Admin Credentials column will become active. In addition, the name of the assigned credential is displayed next to the icon.
To assign credentials to all machines in a machine group, in the top pane select Credentials > Set Credentials.
On the Assign Credentials dialog, select from the list of available credentials or click New to define new credentials.
When credentials are assigned the icon will contain a check mark:
In addition, the button name will change to the name of the assigned credential.
There are several different tabs that can be used to add virtual machines to a machine group. The credentials that will be used to scan and/or deploy patches to these machines depends on how the machines are defined to the group and on the current power state of each machine.
A hosted virtual machine that is offline at the time of a scan will be accessed using the server's browse credentials. Any individual credentials supplied for the machine are ignored.
Machine Name tab, Domain Name tab, or IP Address/Range tab: Used to add virtual machines that reside on individual workstations and that are online at the time of a scan. See Assigning Credentials to Individual Machines in a Machine Group, above.
After one or more machines have been scanned and are contained in Patch for Windows's database of managed machines, you can use the Machine Properties dialog to assign different credentials or to remove credentials.
There may be several reasons for providing different credentials to machines after a scan has been performed. If you have multiple administrators in your organization and each is responsible for a different domain, they will need to set their own credentials before performing an action. Or, your organization's policy may be to separate scan (assessment) duties from deployment duties, in which case different credentials are probably required.
Important! If there are two or more administrators using Patch for Windows, each administrator should provide their own machine credentials.
The Credentials Manager is used to manage all credentials used within the program. It is also used to set the default credential for the program.
Although you can supply new credentials from several different areas of the program, all of the credentials can be edited and deleted from this single location. This greatly simplifies the credentials management process. For example, if a password that is used to authenticate a specific group of machines changes, you simply use the Credentials Manager to update the associated credential. All items assigned to that credential are automatically updated with the new password.
To manage the credentials used by the program, select Manage > Credentials.
Add | Enables you to add a new credential. |
Edit | Enables you to modify the selected credential. |
Delete | Deletes the selected credential. You can delete multiple credentials at the same time. When you delete a credential the following occurs:
Caution! Any items using the deleted credential will no longer be assigned a credential. Before you delete a credential you should browse your machine groups to verify the credential is not being used. |
Merge | Tip: This credential cleanup tool will typically be used immediately following an upgrade from an earlier version of Patch for Windows that does not contain the Credentials Manager. Enables you to merge one or more credentials that contain the same user name and password with another credential entry that also contains the same user name and password. Or you can merge several different credentials into one new credential that is effective in all situations. By eliminating duplicate and unneeded credentials you reduce confusion and lessen the chance for human error.
The Merge Credentials dialog is displayed. For example:
Note: A shared credential can only be merged with another shared credential. Therefore, if any of the credentials in the Confirm credentials to merge list are shared, then (1) only shared credentials will be offered for selection in the Existing box, and (2) any new credential you create will automatically be defined as a shared credential.
|
View usages | Enables you to see how and where the selected credentials are being used in the program. Only those credentials that are currently being used in the program will be displayed in the Credential Usages dialog. A credential may be listed multiple times if it is used in different areas of the program.
You can right-click on any list item and perform a number of different actions.
|
Set as default | Assigns the selected credential as the default credential. The program will use the default credential if other credentials are missing or invalid. |
Clear default | Removes the default credential assignment. |
User Name | Displays the user name portion of each credential. |
Name | Displays the unique name assigned to each credential. |
Shared | Displays whether the credentials are shared credentials. The information in this column is directly related to the Share this with background tasks, Agents, and other features check box on the Define Credential dialog. |
You can set explicit credentials for machines via View > Machines > Right Click a machine > Machine Properties.
Credential: Specifies the credential used when authenticating Patch for Windows to the machine. The credential you supply here will override credentials specified in other areas of the program. If you select None you effectively remove the credential currently assigned to the machine.
There may be several reasons for providing different credentials to a machine after a scan has been performed. If you have multiple administrators in your organization and each is responsible for a different domain, they will need to set their own credentials before performing an action. Or, your organization's policy may be to separate scan (assessment) duties from deployment duties, in which case different credentials are probably required.
Patch for Windows contains a number of built-in checks to guard against simultaneous and conflicting commands from different administrators. For example:
The program will not allow simultaneous updates to any groups, templates, distribution servers, or agent policies by different administrators. If this situation should occur the second administrator will receive a warning message similar to the following:
Recommendations
Minimum suggested hardware requirements for two administrators: 2 processor cores and 4 GB RAM
For each additional administrator, add 1 processor core and 1 GB RAM
For a high performance system, use 16 processor cores and 32 GB RAM
When two administrators log on to the same console they must use different accounts. The same account can be used only when logging on to different consoles.
If you edit a group that is typically used by another administrator you should notify that person about the change.
Each administrator should create their own credentials and assign them to machines.
Each administrator should define default credentials that are the same as their logon credentials. This will eliminate problems that may occur if the administrator forgets to assign machine credentials.
You must take a few common sense precautions when using multiple administrators. Even though Patch for Windows contains a number of built-in safety checks, it cannot guard against all possibilities. The program may act in unpredictable ways if the following occur:
The machines will be scanned twice, causing potential performance issues. In addition, there may be administrative rights errors due to the multiple connections.
The most likely result is that one deployment task will succeed and the other will fail. But because the deployment that succeeds will likely perform a restart of the target machines, the machines may be in an unknown state when the other deployment fails.
When you create credentials and assign them to machines, those credentials belong to your administrator account. If a different administrator (Administrator B) logs on and uses Patch for Windows, they will not have access to the machine credentials you provided. The second administrator must provide their own machine credentials.
One of the ways this can be confusing is if Administrator B fails to provide their own machine credentials and tries to schedule a patch deployment from a scan that was performed by Administrator A. The deployment can be successfully scheduled if default credentials are available, but the actual patch deployment will likely fail because the patch deployment requires machine credentials -- credentials that were provided by Administrator A but that are not available to Administrator B.
Recommendations:
Each administrator should define default credentials that are the same as their logon credentials. This will eliminate some of the problems that may occur if the administrator forgets to assign machine credentials.
Unlike machine groups (which can be viewed by all administrators), vCenter Servers and ESXi Hypervisors can only be viewed by the administrator that added them to Patch for Windows. If two different administrators want to manage the same vCenter Server or ESXi Hypervisors, both administrators must add the item to the Virtual Inventory list.
More information concerning credentials usage in Patch for Windows and possible known issues can be found in the following community documents:
Shavlik Protect Encryption Q&A
How-To troubleshoot Error 5 - Access is denied
Change Machine Credentials on Multiple Machines at Once
Account Lockout - Scheduler Service using Credentials
Patch for Windows 9.x
Shavlik Protect 9.x
Today I was getting the message "Connected to a machine with the wrong hostname or domain name." Turns out the real error was remote registry service not running (it was set to manual). This was 9.1.0 build 4334 scanning a fresh build of Windows 7 pro.
Any input in that, I have done POC for Ivanti Patch for Windows and Microsoft SCCM both, I found Ivanti as light,sleek and easy to use. Any Pro's and Con's will be helpful.
Hi All,
I did not receive any notification for Tuesday Patches yet? it usually receives on Wednesday morning, Can you please help me with this?
Regards,
Abhi
Hi Team,
after running the patching on windows servers (use default reboot parameter: reboot after installation) using BMC Bladelogic server automation tool.
- Once patches are installed have a look to your 'scheduled task' panel :
a "HF_BOOT_TASK_JOB (INSTALL_STATE_UPDATE)" task has been created.
Is there any resolution for the same.
Regards,
Abhishek Tundalwar
Hi All,
have been looking but am unable to find a list of Ivanti's download sources.
I am setting Ivanti up for a customer who has very restricted Site, Essentially any server that needs to break out to the internt can only do so to specific addresses.
I am looking to create a specific firewall rule which will allow Ivanti to break out to the internet and grab any required updates from any of its source locations, Windows updates adobe ect. Is there a list of the Applications download sources available.
Any help will be great.
Thanks
As a Manager, I want to know when all of my workstations are in compliance with a specific level of patching. Ivanti said the only way to know that is if the server can scan the endpoint. That doesn't work if 1) the computer isn't on the network at the same time we perform that scan and 2) the computer is never on the network to have a scan complete. Is a successful scan from the server the ONLY way to have the agent report in? There are no built in reports that provide what I need. Others must have found a way to do what I'm looking for. Can you please help. Thanks.
This document provides links to other documents addressing custom action, custom patch, and ITScript information and troubleshooting.
Custom Action
Prerequisites and Process
How To: Perform a Custom Action Complete Tutorial with Custom Actions
Can You Use Custom Actions With Agents?
Custom Action - Using The Null Patch
How to: Scan for the Null Patch using the Custom Actions scan filter
Custom Action - Things to know and watch for
Run a script
Custom Action - How to Work with Batch Files
How To: Run a PowerShell Script with a Custom Action
Install programs
Work with custom patches
How To: Run An Executable or MSI With A Custom Action
Using Custom Actions To Deploy MSU/MSI Files
Uninstall programs or remove files
Custom Action - Remove the Remote Scheduler for Protect Version 9
How To Uninstall A Program Using Custom Actions
How To Remove The Propatches Folder Using Custom Actions in Protect 9.1
How To: Uninstall Java using a Custom Actions
Reboot a machine
How To: Reboot Target Machines with Using the Custom Actions Patch Type in a Custom Scan Template
Work with custom patches
Custom Patch: Custom .exe File Distribution With Custom Action
Custom Patch
Considerations For Custom Patches And Products
Custom Patch Deployment .bat File Never Completes.
ITScript
ITScript - Errors Importing Custom ITScripts
ITScripts - Enabled Scripts Not Showing in Run Console ITScripts
Temp Folder Fills Up With Small Files Troubleshooting
Purging Downloaded Patch Install Files From The Protect Console
Shavlik Protect 9.x
Ivanti Patch for Windows Servers 9.3.x
Running Ivanti Patch for Windows v9.3.0 Build 4510 with the database running on SQL 2008. We are wanting to move just the database to a new SQL 2014 server. Will this version of Ivanti P4W run fine with that version of SQL, or do we need to run the database in a different compatibility mode on the server?
We are currently patching VMware templates using Shavlik. Shavlik converts the template to a VM, powers it on, patches it, powers it down and converts it back to a template, great. However, Now we're using Vsphere 6.5 we'd like to manage our templates in content library's as we have multiple Vcentres.
Therefor, I would like to raise a feature request for Shavlik to patch templates stored in content library's.
A lot happened at Dallas Interchange. Here are the highlights:
At Dallas Interchange 2018 we introduced the latest in Ivanti technologies and shared the development roadmap for our security products. We’re excited to share some highlights from that event with you. We’d also like to address misconceptions that arose about the future of the products we offer now. Be assured that none of our security products have reached end-of-life (EOL). We updated several in the past couple months, and we’ll continue to release updates throughout the year and beyond.
Please take a moment and view the attached document to learn more about security news from Interchange:
Your deployment stops progressing in what seems to be the middle, but some patches never progress past Scheduled. You may see a failure or you may not.
This can be verified in the logs, but this is often an indication that the system shut down or restarted in the middle of the patching process. You may see log entries similar to the following in C:\Windows\ProPatches\Logs\STDeployerCore.log that highlight some patches that are still showing as Executing or Scheduled:
2018-08-06T21:05:32.1345530Z 0c80 V UnScriptedInstallation.cpp:30 Executing (C:\Windows\ProPatches\Patches\windows8.1-kb4346406-x64.msu /quiet /norestart), nShow: true.
2018-08-06T21:05:32.2751767Z 0c80 V ChildProcess.cpp:140 Process handle 00000394 returned '1115'.
2018-08-06T21:05:32.2751767Z 0c80 W DeployerImpl.cpp:106 Patch state is 'Failed'. Registry bread crumb patch state not updated.
2018-08-06T21:05:32.2751767Z 0c80 I Authenticode.cpp:134 Verifying signature of C:\Windows\ProPatches\Patches\windows8.1-kb4346745-x64.msu with CWinTrustVerifier
2018-08-06T21:05:32.6970575Z 0c80 V UnScriptedInstallation.cpp:30 Executing (C:\Windows\ProPatches\Patches\windows8.1-kb4346745-x64.msu /quiet /norestart), nShow: true.
2018-08-06T21:05:32.7595763Z 0c80 V ChildProcess.cpp:140 Process handle 000003E4 returned '1115'.
2018-08-06T21:05:32.7595763Z 0c80 W DeployerImpl.cpp:106 Patch state is 'Failed'. Registry bread crumb patch state not updated.
From Microsoft's documentation on System Error Codes, we see that 1115 = A system shutdown is in progress, showing us something initiated a shutdown event in the middle of our deployment.
Deployments will not be able to resume after a shutdown or similar event, so it is recommended that you re-scan your target machine(s) to verify which patches were properly applied and push a new deployment.
Shavlik Protect 9.x
Ivanti Patch for Windows Servers 9.3.x
Several of our end user machines are still getting Blue Screens caused by TCPIP.sys after the July patches. Microsoft says that they have corrected but we are still fighting this issue with some of our users. I was curious what kind of testing (if any) does Ivanti do for patches being released.
With the now never-ending required OS changes from Microsoft and the constant re imaging and renaming machines, I am wondering if anyone has developed a workable solution to the 45 day expiration requirement of an Ivanti license seat. While Ivanti has been helpful and provided me with some temporary seats, I can see where future upgrades and replacements of machines will become an issue.
We want to patch a machine as soon as it is on the network, this of course requires it be given a name that hopefully it will keep for some duration, but often is not. When systems are swapped out, say a workstation for a tablet to the same user, the name changes to reflex the machine type, and using another license.
I am looking for methods to better control this, even if it means retraining techs and changing procedures, but wondered if anyone has had success with a specific process for such a moving target.
