Quantcast
Channel: Shavlik User Community : All Content - Ivanti Patch for Windows
Viewing all 2126 articles
Browse latest View live

Is there a way that we can save a update scan and deployment scan that we can use for different environments. Like a patch group but then still the same patches

$
0
0

We have a test environment and a Production environment that are the same

We clone the production to the test and want to update this environment with the latest updates after that we need 3 weeks to test all the applications if it works then we need the same updates/patches for the production

we have to save the updates like a group or something because we need to install the same patches in de Production environment

 

We don't want to install new updates in de production environment because we haven't test the applications in it.

 

Is this possible with Ivanti?


Enabling TLS 1.2 for Ivanti Patch for Windows

$
0
0

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+

Scheduled Scan - No Results / Incomplete Results

$
0
0

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.

 

Schedule.PNG

 

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

Scan_no_results.PNG

Incomplete_results.PNG

 

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

Adding ESXI Host - The Host Could Not Be found

$
0
0

Hi All wondering if anyone has came across this issue, (Support case raised)

 

Ivanti Product Fully Licensed:

Licensed Capabilities

--------------------

Maintenance and Data Subscription expires:  24/06/2019 01:00

 

## ISSUE ##

 

This is a New installation of Ivanti Patch for windows,

Once installed I was able to add 2 ESXI Vcenters, populate machine groups with discovered machines.

 

Came back a week later to add internet proxy details so I could start testing deployment and patching levels of the estate and I am met with:

 

Connection_Failed.PNG

 

I then removed one of the hosts and re-added and I get

Adding host.PNG

 

Credentials have been confirmed to be valid and working,

Successful Connection from Ivanti VM to Host via SSH:

Putty_Connection.PNG

 

Can Ping the hosts successfully:

Ping_Successful.PNG

 

Can telnet (443) from Ivanti VM to hosts:

telnet_successful.PNG

 

I have also completed a successful Refresh of all files.

 

Again the Credentials being used have already successfully added these hosts to Ivanti last week, and I can log in with these credentials to full admin level.

I have been unable to find any details of this issue anywhere else which has been successfully resolved.


Thanks Malachy

.MSU files cannot be downloaded from HTTP-configured distribution server and agents cannot patch machines (2021621)

$
0
0

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

End of Life Information for Shavlik Products - Shavlik OEM - HEAT OEM - Legacy Product Lifecycle Policy

$
0
0

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

Can I get list of scheduled patches from the API? Or is there any other way to do it?

$
0
0

Hi,

 

I am currently assigned to develop an automation to ignore alerts (in OpsGenie) from machines that are part of a scheduled maintenance in Ivanti Patch. Exploring the API module STProtect on Powershell, I didn't find any command useful to get scheduled patches. With the help of the documentation in powershell, I was only able to get the list of finished schedules using Get-PatchScan -OnOrAfter 'YYYY/MM/DD'

 

Do you have other ways on how to get scheduled patches within the current day or future?

 

I am referring to the list shown below:

 

 

Regards,

Paul

Windows 10 Build Upgrade Deployment Support in Patch for Windows Servers

$
0
0

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.

We currently do not support the Architecture selection of Both in the Media Creation Tool, so please select the specific architecture you are supporting.

Windows 10 version 1709 has a different ISO model. Please see this link to ensure you download the correct version.

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:

          TH2 Deployment.png

  • 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:

TH2 Deploy Failure.pngDeploy Operations Manager Failure.png

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

Reboot Deployment.png

 

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:

Protect Complete.PNG

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

 

OS Verify.PNG1607.PNG

 

Affected Products

 

Ivanti Patch for Windows Servers 9.3.x


deployment stuck at initializing

$
0
0

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

Scan Error 830 - Unable to Connect to the Virtual Server

$
0
0


Symptoms

 

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

Error830.PNG

 

Cause

 

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

VMToolsNotInstalled.PNG

 

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

Methods to Install An Agent for Patch For Windows Servers 9.3

$
0
0

Purpose

 

Agents can be installed via multiple methods, as follows:

 

Console Installation - Push Method

 

Agents can be installed from the console, in which case all the configuration prerequisites are the same as those for an agentless patch deployment - see Patch Scanning Prerequisites. This includes enabling the Remote Registry service on the target machine and verifying that the proper TCP ports are open. During the install process, the agent machine will need to successfully resolve the console via DNS and connect to the console via TCP 3121 in order to obtain the assigned policy. An agent policy must be created and configured prior to installation.

 

Push Method Steps

  • Create a new machine group.
  • Add the agent machine to the machine group using a machine name, domain name, or IP address. You cannot use the Install / Reinstall Agent button to install agents on machines that were added as Organizational Units, nested groups, or IP ranges.
  • Specify the necessary, machine specific credentials.
  • Select the machine, then select 'Install/Reinstall Agent'.

 

You can also select a previously scanned machine from the Machine View and select Install/Reinstall with Policy.

 

Manual Installation

 

Agents can be installed directly on the target machine, in which case the agent machine will need to successfully resolve the console via DNS and connect via TCP 3121. Additionally, either valid credentials for the console or a passphrase will need to be supplied. In the case of a passphrase being used, the passphrase will need to have been set on the console machine via the 'Agents' tab of the 'Tools > Options' menu. An agent policy must be created and configured on the console prior to installation. The preferred method of installation is as follows:

  • Ensure that the console's data files have been updated successfully (click Help > Refresh files)
  • Copy the 'STPlatformUpdater.exe' file from the console machine to the agent machine. This file is located in the following folder:
    C:\ProgramData\LANDesk\Shavlik Protect\Console\DataFiles
  • Log into the agent machine using credentials with administrator level privileges on the local machine.
  • Launch the installer.

If the IP address is used to specify the console URL, it will be necessary to create an Alias for this same IP address on the console machine (under Tools > Console alias editor)

 

Scripted Installation

 

Agents can be installed using a script. This method of installation is very similar to a manual installation, with the exception that the target machine will run the installation using the 'Local System' account, and that the necessary installation options must be specified as command line switches. See the administration guide for further details outlining the necessary syntax.

 

Once the agent has been installed, the installer files for the necessary components will be downloaded and executed. The components installed will depend what type of tasks are defined in the assigned policy (e.g, Patch tasks, Power tasks, etc.). The installer files, as well as all other necessary patch and data files, will be downloaded from the source as specified in the agent policy. If the agent is unable to obtain these files from the specified source, the agent will fail to perform as expected.

 

Installing Agents Using An Installation Script

 

Logs

 

The installation log files can be located in any of the following locations, depending upon installation method:

 

C:\Windows\Temp\

C:\Windows\Temp\{stringvalue}\

%temp%\

The log files will be named as follows:

STPlatform*.log

AgentInstaller.log

 

Once the agent has been successfully installed, further log files (including installation log files from component installations) can be located in the agent data files (within the '...\Logs' subdirectory).

 

How To: Collect Protect console, patch deployment and agent logs for troubleshooting

 

Additional Information

 

Our Agent Quick Start Guide can be found here:

Patch for Windows Server 9.3 - https://help.ivanti.com/sh/help/en_US/PWS/93/qsg-pws-9-3-agent.pdf 

Patching FileZilla Updates in Patch for Windows Servers

$
0
0

Purpose

 

The purpose of this document is to outline the issues surrounding FileZilla updates particularly related to the downloading of the patch files from the vendor.

 

Cause

 

Changes from the vendor, Filezilla, has caused downloads of the updates not from a Web browser to fail with an error 403 authentication error. From review, the cause is the lack of user token authentication as updates downloaded through Patch for Windows are done on behalf of a user or system account, not as the actual user. Additional findings have shown the direct download links to also reroute to the main Filezilla site versus downloading the actual installer.

 

Resolution

 

The current workaround to this issue can be found in this document: How To: Supply and Deploy Patches That Can Not Be Downloaded

 

Additional Information

 

Filezilla Downloads Page: https://filezilla-project.org/download.php?show_all=1

 

Affected Product

 

Patch for Windows Servers 9.3

User account not displayed in the “User Role Assignment” result pane if the user account was not created in the “Users” OU.

$
0
0

Purpose

 

The purpose of this document is to show how to assign a new user account to a user role IF:

  • The new user account is created in a different OU other than "Users", when unchecking "Quck Search" doesn't display new user account.
  • There are more than 100 users in "Users" and other OUs combined.

 

Symptoms

 

When attempting to assign a new user account for a user role, and if you have more than 100 user accounts throughout your organisation units in the active directory, chances are, you won't be able to see the new user account:

  1. if you create it in a different OU other than "Users" OU as depicted in the screenshots below.
  2. When you uncheck the "Quick Search"  box in the "Find User" pop-up

 

1)I created a new account named “Michael Long” in a different OU called “EDW”. This OU contains all other users. This is a normal domain user account.

   2) On the “Patch for Windows” management console, when clicking on “Manage – User Role assignment – New – Find User”

Clicking on the “Quick Search” will not display the new user account. This is because the “Quick search” function would only search for accounts within the “Users” OU on the active directory.

 

3) By right, when unchecking the “Quick search”, it will search for all the user accounts from all OUs on the active directory and display them in the result pane. But at times, you won’t be able to see the new user account listed, as shown below, the new user account “Michael Long” is not within the list. The user accounts are listed with alphabetical order.

 

Resolution

 

In this case, please add the new user account manually and create the new role.

1) Click New
2) Type in domain\username
3) Set Role
4) Click OK.

New account added

In the “Patch for Windows Administration” guide, it also states:

“All configured users must have access to the database. If users without administrative rights on the console machine receive an error when starting Ivanti Patch for Windows Servers, it probably means they don’t have the necessary SQL Server permissions.”

 

i) Apart from creating the new role based on the new user account, the new user account must exists in the SQL server.

 

ii) Please also add this new user in the local "Administrators" group on the "Patch for Windows" actual server.

iii) Last but not least, if you have any multiple active VM sessions for the Shavlik protect server, please close them all, and login using that new account. Or reboot.

 

Additional Information

 

According to internal sources, this scenario is an expected behavior. It is a limitation to the API we use to interact with AD to obtain the complete list of users. It is not a defect, and a change request to enhance the search feature in the future was already in place.

 

Affected Products

 

Shavlik Patch for Windows 9.x

Always exclude Java from patch template

$
0
0

Hi all,

 

We have a need for one or two specific machines to not patch their Java version while we work on upgrading some core software first.

 

I thought this would be simple in IPW - clone the existing patch scan template, then untick the 'scan for these' box for Java. Makes sense, right?

 

Except there doesn't seem to be a Java box. I thought it would be under 'Oracle' but it is not.

 

Does anyone know a way to do this? I have read through all the documents about excluding specific patches, but this won't work because every time a new version comes out it will start to auto deploy - I need it to fail safe and not install.

 

Any ideas?

 

Thanks!

Getting list of upcoming patch deployments

$
0
0

We would like to create a view/list of upcoming patch deployments. it seems that API is not ready for this task yet, so we thought that maybe SQL query would work. Most of the patch deployments have been automated via "Schedules Console Task" view.

 

We would like to list following data: machine name, ip, machine group, last deployment time, next deployment time.

 

In "Schedules Console Task" view we can see "Last run" and "Next run time" columns. Where can i find these columns in SQL database?


custom actions not working with creator update AND now with April 2018 update (1803) and (1809)

$
0
0

hello

 

if you scan machines with the creator update installed with custom action, it reports no patch missing

it should have a patch count of 1

 

this happened before when 1511 was released

 

see  Re: windows 10 build 1511  custom actions no longer work

 

please can you add build 1703 to supported OS for custom actions

thanks in advance

 

neil

Manual scans work, scheduled scans fail: Scheduler Credential

$
0
0

Purpose

 

This document will explain why and how to fix scheduled scans that fail to run, but manual scans do work.

 

Symptoms

 

Scanning a machine runs immediately but when scheduling the tasks are failing to run.

 

Causes

 

1) When scheduling a scan, Protect requires a "Scheduler Credential". This credential is set under Manage > Scheduled Console Tasks.

 

2) The credential being used does not have Local System Admin rights and permissions. It must be a local Administrator, and it must be allowed to run scans under User Role Assignment.

 

 

Resolution

 

1) Look in Manage > Scheduled Console Tasks and determine which account is the scheduled jobs are being scheduled as

2) Log into the Protect server with those credentials.

3) Go to Manage > Credentials and recreate the credentials be set in the Machine Group (click option to share).

4) Log into Protect with the account you normally log in with.

5) Open the Machine Group and set the new credentials.

6) Scan without scheduling to make sure it works.

7) Schedule a scan for 5 minutes into the future to test.

 

Example: If the credential is domain\user1, then domain\user1 needs to log in to the Protect server, open the console, create the credentials, and assign them.

 

It is best practice to use the currently logged on users credential as the scheduler credential, as it should always have the needed permissions to run.

 

Additional Information

 

This document also pertains to scheduling the staging process.

This credential is used to place the scheduled task on Windows Task Scheduler and not used to login to the target machine.

Scheduled tasks are created and will be viewable in Windows Task Scheduler.

 

Affected Products

 

Ivanti Patch for Windows Server 9.3

Windows 10 Build Upgrade Deployment Support in Patch for Windows Servers

$
0
0

Notice 12/06/2018

We are changing our ISO file name format for Windows threshold OS patch 1809 from WindowServer1809Standard.iso to WindowsServerStandard1809.iso.

  • This change will be included in the content release Thursday, 12-06-18.
  • This effects ISO threshold patch 1809.
  • This will require customer to change the name of the .ISO already in the patch store.

 

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.

We currently do not support the Architecture selection of Both in the Media Creation Tool, so please select the specific architecture you are supporting.

Windows 10 version 1709 has a different ISO model. Please see this link to ensure you download the correct version.

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:

          TH2 Deployment.png

  • 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:

TH2 Deploy Failure.pngDeploy Operations Manager Failure.png

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

Reboot Deployment.png

 

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:

Protect Complete.PNG

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

 

OS Verify.PNG1607.PNG

 

Affected Products

 

Ivanti Patch for Windows Servers 9.3.x

Oracle SE Java 8 support changes and how it effects deployments through Ivanti Patch Management solutions

$
0
0

Overview

 

Oracle has announced changes to ongoing support for Java SE 8 (Standard Edition). This article describes these changes and how Ivanti will continue its support for Java SE 8 in January 2019 and beyond.

 

In January 2019 Oracle will require those who wish to continue support for Java 8 SE on Servers, Desktops, and Cloud Deployments to subscribe to the new Java SE Subscription offering to continue to receive Java SE 8 updates. This subscription covers all Java 8 SE licensing and support needs. If you cannot migrate applications with dependencies on Java 8 over to Java 10 by then, this is your option to continue to gain security updates until you can transition.

 

The following End of Public Updates announcement was taken from the Oracle Java SE Support Roadmap.

“End of Public Updates of Java SE 8

Java SE 8 is going through the End of Public Updates process for legacy releases.  Oracle will continue to provide free public updates and auto updates of Java SE 8, until at least the end of December 2020 for Personal Users, and January 2019 for Commercial Users. Personal Users continue to get free Java SE 8 updates from Oracle at java.com (or via auto update), and Commercial Users continue to get free updates to Java SE 8 from OTN for free under the BCL license. Starting with the April 2019 scheduled quarterly critical patch update, Oracle Customers can access updates to Java SE 8 for commercial use from Oracle through My Oracle Support and via corporate auto update where applicable (Visit My.Oracle Support Note 1439822.1 - All Java SE Downloads on MOS– Requires Support Login).

Oracle does not plan to migrate desktops from Java SE 8 to later versions via the auto update feature. This includes the Java Plugin and Java Web Start. Instead of relying on a browser-accessible system JRE, we encourage application developers to use the packaging options introduced with Java SE 9 to repackage and deliver their Java applications as stand-alone applications that include their own custom runtimes.

Current releases remain free and open source for all users from jdk.java.net.”

 

Ivanti will continue to support Java SE 8, but will do so with what we refer to as “drop-in” support for products who have this functionality.  This means supported Ivanti Patch Management solutions will continue to detect and have logic to update Java SE 8 instances in your environment, but it will be up to the customer to provide the installer and drop it into the patch repository for remediation purposes. This change keeps both Ivanti and our customers in compliance with Oracle’s licensing for Java SE 8.

 

Additional Information

 

Please refer to instructions for the Ivanti Patch solution you are using for details on how “drop-in” support works in your product:

 

Supported Products

 

Ivanti Patch for Windows

Ivanti Security Controls (ISeC)

Ivanti Patch for SCCM

Ivanti trying to install non applicable patches

$
0
0

Today when I was updating our machines with Ivanti Patch for WIndows tool, I got error on 15 patches on 2 machines.

I was trying to get those patches on machines, but it would always give me error code 2147483647.

After some looking around, I noticed that it's trying to install patches for .NET Framework 4.6.1, but that can't be done, since those 2 servers are Windows Server 2008 (Not R2), so they can't even have .NET Framework 4.6.1.

It would be nice, if Ivanti could know, that those patches can't be applied to Server 2008 machines ... now it's showing me like 15 patches are missing all the time, and it's a bit annoying.

 

Any ideas for some workaround, how to get rid of those false 15 patches missing? I still want those patches on all my other machines that does have Server 2008 R2 or higher version of OS.

 

Viewing all 2126 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>