I am trying to create a custom definition for a patch (and product) and can only get the detection to work if I specify the full path to the executable I am detecting. It may not always be the case that the application is installed in the same location so I need to be able to detect using wildcards or just the executable name. Is this possible?

Thanks

Alastair

Hi got this question, if a server are missing, say from MS14-018, to MS18-03-SO81, is it then  required to install all MSXX-XX-XX in between  ? or is it enough to just install ms18-03.SO81

/Niels

Issue

When attempting to patch there are a large about of detections of vulnerabilities that are not applicable to the client machine. When scanning, these definitions are flagged as detected for reason "Pre-req Check failed." This can cause numerous failures, bloated detected definition results, and incorrect logging.

Symptoms

To know whether or not you are getting a Pre-req check failure there are a few symptoms you can look for in order to know if this is the cause of your patch failures. This issue only occurs with Next Gen vulnerabilities.

1. Scan Failed returns

One of the first symptoms most customers notice is an abundance of "Scan Failed, Failed to start scan" returns in their clients patching history. These returns are an indication that the core server received a failure to start the scan during Vulcan. This is due to important files not being in the proper location during the scan, more on that later.

2. Bloated "All Detected" patches list

The second symptom that can point to a Pre-req check failed is the bloated "All Detected" folder in the Patch and Security. This is normally filled with a large amount of detection of either previously undetected or not applicable vulnerabilities. Since there was a failure during the scan for these vulnerabilities they will be flagged as detected and will show up in this folder. When selecting one of your definitions you will see the reason for detection as "Pre-Req Check Failed."

3. Ivanti folders on the root of C:\

The final Symptom of this issue is the presence of two Ivanti folders that are being placed in the root of C:\.  "vulScan" and "LANDesk" will appear in the root of C:\ instead of the locations "ProgramData" and "Program Files(x86)" respectively. This is caused by them not being properly configured to the proper locations.

Resolution

This issue can be easily resolved by correcting the registry key where the vulScan folder should be properly located. Open Regedit and locate the following key

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\explorer\Shell Folders

Here you will find the CommonAppData key. If you are experiencing this issue it is caused by this key being blank. Simply add "C:\ProgramData" without the quotes then run a scan. This should allow for a proper scan and the vulScan and LANDesk folders will properly update in their designated locations. You are free to delete the folders on the C:\ root without any impact on the product.

Wed, 02 May 2018 10:49:41 SendRequest: SOAPAction: "http://tempuri.org/SetPatchInstallStatus2"

Wed, 02 May 2018 10:49:42 Success

Wed, 02 May 2018 10:49:44 TimberHlpr DLL_THREAD_DETACH called

Wed, 02 May 2018 10:49:45 DoDownloadFromSourceSteps: DOWNLOAD_ERROR_GENERAL_FAILURE

Wed, 02 May 2018 10:49:45 Failed to download \\IBS-FS4\PPS\Patch\windows6.1-kb4093108-x86_tw1211060.msu.  Error code 1

Wed, 02 May 2018 10:49:45 \\IBS-FS4\PPS\Patch\windows6.1-kb4093108-x86_tw1211060.msu Failed

Wed, 02 May 2018 10:49:45 TimberHlpr DLL_THREAD_DETACH called

Wed, 02 May 2018 10:49:46 TimberHlpr DLL_THREAD_DETACH called

Wed, 02 May 2018 10:49:46 TimberHlpr DLL_THREAD_DETACH called

Wed, 02 May 2018 10:49:47 TimberHlpr DLL_THREAD_DETACH called

Wed, 02 May 2018 10:49:47 Download Failure: Error 80004005 downloading \\IBS-FS4\PPS\Patch\windows6.1-kb4093108-x86_tw1211060.msu

Wed, 02 May 2018 10:49:47 Last status: Failed: Could not download \\IBS-FS4\PPS\Patch\windows6.1-kb4093108-x86_tw1211060.msu

Client machine unable to download patch after we removed patch location to other storage (before this when it worked, the patch folder is in core server). Client machine able to access the

path \\IBS-FS4\PPS\Patch\Patch\windows6.1-kb4093108-x86_tw1211060.msu from their machine but not able to download the file during the patch deploy task.

Share permission to everyone has been set as Full Control on folder Patch.

We are attempting to install Windows 10 1709 release.  I have followed both steps to install using patching and provisioning, not having any luck.  Both tasks fail.  I have gone over these instructions multiple times and can not figure out what I am missing.  All help is appreciated.

LANDESK Patch News Bulletin: LANDESK has Released Content that will Update Clients to Windows 10 Anniversary Update 04-AUG-2016

patching windows to 1709

Re: anyone been able to push 1709 update to windows 10 in LANDesk?

2016.3 SU5 - I have 3 devices stuck in the Active queue of a scheduled task that was auto-generated by a rollout project. The devices failed because the core couldn't detect an agent. I did a "retry selected failed devices" when they went to the failed queue, which placed them back in the Active queue, but now they're stuck there and I can't find a way to retry them again? I found some of the LANDesk services were disabled on these, so after enabling them I can't find a way to retry them against the task? If I remove them from the task, and then drop them back in, they just sit in the Pending queue, even if I right-click the task and do any of the Start options, the devices just remain in Pending?

2016.3 SU5: Why do some patches appear with the word "DETECT" in the name and why aren't they downloadable?

Hello,

I have three issues with the new next gen patching system.

Landesk version = 2016.3        10.1.0.168

1. Some of the 3rd party applications will not automatically download the patch even though it has been detected on multiple workstations.
   
   
   
2. Custom variables for patch definitions is empty and greyed out. For example there use to be multiple custom variables for Java.
   
   
   
   
3. In the Affected Computers section of the Meltdown patch MS18-01-MR7-INTL I'm seeing a large amount with the "Reason" stating the "Pre-Req Check Failed." I know one of the requirements for this is the reg key that certain Antivirus software needs to place. We have Symantec and I have confirmed that it is placing the reg key in the proper spot. I know there will be some that were missed but Landesk is reporting 4000+ workstations with "Pre-Req Check Failed"
   
   

Wondering if anyone else has these two issues before I open a case with Support.

Thanks,

Andrew

EMP 2017.X

I can't find the W10V1803 under our detected patches.

Is it listed under a different number?

Best.

We are pushing these 2 repair tasks for these definitions and we get back Patch already installed, repair no longer needed. We check the servers and the patches are NOT there.

Hello all,

I have a large number of PHYSICAL machines on network with VMWare Tools installed -- The VMWare Tools update through LANDesk does not work (actually, it can't work at all since VMWare Tools executables simply throw an error on physical machines)

So I tried to uninstall VMWare Tools via VMware Tools "setup.exe" /s /c on a test machine. As far as I can tell, VMWare Tools is removed completely -- I've run several inventory scans since, and Inventory doesnt show VMWare Tools under Add/Remove Programs or Software Products.

Nevertheless, VMWare Tools seems to be detected by vulscan, and it still attempts (and fails) to run the fix.

Can anyone provide any insight as to why it's still detecting?

I am currently doing an LDMS implementation at my company for a little under 3k endpoints. I have years of experience with the product, but have never had or implemented Patch Manager. We currently use WSUS and will be replacing it entirely with LDMS. We are not up to the patch phase of project, but I spent a lot of time evaluating different areas of patch when I did the proof of concept. I have a number of questions that I'm hoping some of you can point me in the right direction on.

1.) Moving from WSUS to Patch Manager what is usually the practice here? Do people usually start from where WSUS left off when it comes to approving patches for autofix? Do you try to match up all WSUS approvals with Patch Manager?

2.) How are people using download definition settings? They are very limited where you only have vendor/product and contains/equals. Initially I was hoping to use this for automation in getting patches into a roll-out project for a more hands-off approach, but that doesn't seem possible with the limited options.

3.) For workstations we will probably be implementing a three-phase patch cycle where pilot 1 would get approved patches the weekend following patch Thursday, pilot 2 the following weekend, and the rest of the environment. I'm weary of using the 'Disable any rules this definition replace' setting in the download definition settings for this reason... If a patch is still in play for the general population and a newer version of the patch comes out that will go to pilot this setting would stop the previous version from getting fully deployed to the general population. How are people using this setting with this issue? If you are not using it, how are you retiring old patches?

4.) How are people using groups and tags to maintain phases/rollouts/etc?

5.) With autofix one of my fears is that a patch will fail a number of times and stop installing where WSUS would just keep trying with the regular schedule. How are people protecting themselves against this issue?

6.) For autofix to work I assume you'd have to configure the reboot agent settings assigned to the agents to allow reboots during a time that overlaps with the patch/distribution agent settings maintenance window?

Where can i get the Office365Util.exe? Trying to patch office 365 C2R. 

Hello,

I am tying to install BIOS updates for the Spectre/Meltdown vulnerabilities, and so far the console says the client is processing the request but in reality the client is just sitting idle and not processing anything.

I've built Distribution packages using the extracted EXE from the Patch supplied by HP and all I get is dead air.

Has anyone else deployed BIOS Patches?  Any suggestions?

Thanks,

Matt

We have suddenly come across an issue where Patch Management is detecting a patch as being required by a number of servers but is not actually required by the server.

We are running LDMS 2016.3 currently.

The patch is showing as required on a number of servers but if I logon to any of the servers and run the patch manually it says T'he update is not applicable to your computer'.

Obviously the detection logic is looking for something that indicates the update is required but if it is not applicable why is this happening?

I have searched tinernet for any help with this patch but cannot find a resolution.  There are a lot of articles about failed patches but nothing I can find specific to this one and how to fix the problem.

Is this a Patch Management issue or a Microsoft Update issue?

If anyone is interested the update in question is 2973351 which is quite an old patch but is suddenly showing as required by quite a few servers.

I could remove the patch from the scanning process so that it is not detected but wonder if there is a deeper issue here.

Note: Clicking on a photo will enlarge it.

This document will go over what to look for and do if you think you have a patch that is detecting incorrectly on your devices.  Incorrect detections can happen if the detection logic is incorrect and still reports as needed but the patch has already been installed, is not applicable to the system or other issues.  In this document, you’ll learn what to look for in the vulscan logs which are required to submit the incorrect patch detection for review.

This document assumes you know how to find individual patches, create a patch group and move patches to it in the console and create a repair task on a specific patch or group of patches in the console.  It also assumes you have an understanding of repair tasks and how to add target devices to them and run the task.

Prep the Client

As of January 2018 all new content created uses the new patching engine.  Additional logs are needed as well as the vulscan log to troubleshoot the false detection.

Diagnostic Tool

^Updated The "Get debug logs and zip (patch)" feature is only available in 2017.3 and newer product versions.

To retrieve logging remotely access the Diagnostic tool and select the Logs | Client option to view client-side logs. An additional option "Get debug logs and zip (patch)" is present for debug logging for all Next Gen definitions. This will only function if the Distribution and Patch agent setting has Enable security scan debug trace logselected.

To enable debug trace logs for versions 9.6 - 2017.1 run the following cmd locally on the endpoint or distribute a script to the desired device:

vulscan /enableDpdTrace=true /showui

The showui switch is optional.

This will generate additional logging in the Programdata\Landesk\DebugLog folder consisting of the following (2) files:

PatchManifestSyncSDK.log

PatchScanSDKDpdTrace.log

Run a Repair Task

Running a repair task for the specific patch(es) gives supports the best information.  The vulscan logs only showing one patch or two processing will show them detecting and installing and are more concise and easier to look over to find details.  General vulscan logs are not Ideal as many only show the patch detecting but not installing and have a lot of unneeded information.  Running a specific repair task with patches having the issue will provide the best logs.

You can create a repair task by going to Tools > Security and Compliance > Patch and Compliance.  Click the Scan folder and find your patch.  When you find the patch having the issue right click it and from the menu that appears click Repair.  If you have a patch group or several patches you can do the same and create a repair task for several patches at the same time.

The Repair task dialog will open.  Most settings you can leave as a defaults.  You can add a target device at this time as well.  If you have a maintenance window on your clients, be sure to check Ignore Maintenance Window if specified so the patch tries to install as well as scan in this repair task.

Once you have a target in your task run it and wait for it to complete.

When the repair job finishes you will need the following files to give to support in a zip file:

C:\Programdata\landesk\log\Vulscan.log  (Make sure it is the correct one, see below)

C:\Programdata\landesk\log\stdeploy.log

C:\Programdata\landesk\log\stdeployercore.log

C:\Programdata\Landesk\DebugLog\PatchManifestSyncSDK.log (sometimes doesn't get created)

C:\Programdata\Landesk\DebugLog\PatchScanSDKDpdTrace.log

Vulscan Log

The full vulscan log, created as a result of running the task, is needed for us to determine the issue of the false detection.  This log is located on the target devices in the C:\programdata\Landesk\Log folder. They are named vulscan.log.  Older logs have a number in the name.   The correct log file will have a line at the top with the task ID in the name as shown in the example.  This information changes with each task.

Thu, 26 Oct 2017 14:59:37 Command line: /policyfile="C:\ProgramData\LANDesk\Policies\CP.2353.RunNow._iOiXj4cedTDG&#474FOGYMztt+mWNQ=.xml"
Thu, 26 Oct 2017 14:59:37 client policy file: C:\ProgramData\LANDesk\Policies\CP.2353.RunNow._iOiXj4cedTDG&#474FOGYMztt+mWNQ=.xml
Thu, 26 Oct 2017 14:59:37 Reading policy parameters
Thu, 26 Oct 2017 14:59:37 scan=0
Thu, 26 Oct 2017 14:59:37 scanFilter=INTL_4049179_MSU;INTL_3089023_MSU
Thu, 26 Oct 2017 14:59:37 fixnow=True
Thu, 26 Oct 2017 14:59:37    maintEnable=False

Once you have found the correct vulscan log. Doing a search in the log file for the all capitals case sensitive “DETECTED” will yield the detection of the patch and the reason.  In our example case it show the file version is out dated and that is the reason the patch is needed.

Thu, 26 Oct 2017 14:59:45 VUL: '3089023_MSU' (windows8.1-kb3089023-x64.msu) DETECTED.  Reason 'File C:\Windows\System32\flashplayerapp.exe version is less than the minimum version specified.'.  Expected '18.0.0.232'.  Found '11.3.300.265'.  Patch required 'windows8.1-kb3089023-x64.msu'.
Thu, 26 Oct 2017 14:59:45    Patch is NOT installed

You can see in the example the patch was detected as needed due to a file being at a lower version than in the patch.  Now scroll down to the bottom of the log file.  You’ll see a “Patch Installation” header and below that you will find details of what happened when the device attempted to install the patch. In our example the patch returned the error code 2149842967 converted to a hex value that gives a result of  0x80240017 Looking on the list of WUSA codes the patch returned a “Not Applicable”.

Thu, 26 Oct 2017 15:03:21 Command Interpreter running
Thu, 26 Oct 2017 15:03:21 Setting current directory: C:\Program Files (x86)\LANDesk\LDClient\
Thu, 26 Oct 2017 15:03:21 Executing C:\Windows\system32\wusa.exe "C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows8.1-kb3089023-x64.msu" /quiet /norestart
Thu, 26 Oct 2017 15:03:23 Exit Code: -2145124329 (0x80240017)
Thu, 26 Oct 2017 15:03:23 Error: "C:\Windows\system32\wusa.exe" returned failure exit code (2149842967)
Thu, 26 Oct 2017 15:03:23 ERROR(EXECUTEFILE) Failed to run command - 80004005
Thu, 26 Oct 2017 15:03:23 DownloadPatch ERROR: Failed to run commands (80004005).
Thu, 26 Oct 2017 15:03:23 Last status: Failed
Thu, 26 Oct 2017 15:03:23 Stopping wuauserv service.
Thu, 26 Oct 2017 15:03:23 Stop service wuauserv
Thu, 26 Oct 2017 15:03:25 Successfully controlled the service.
Thu, 26 Oct 2017 15:03:25 DeferredReportAction: name 'windows8.1-kb3089023-x64.msu', code '1', type '-1', status 'Error: "C:\Windows\system32\wusa.exe" returned failure exit code (2149842967)'
Thu, 26 Oct 2017 15:03:25 Running post-install/uninstall script 
Thu, 26 Oct 2017 15:03:25 RunPatches completed.  1 processed.  0 installed. 1 failures.  Thu, 26 Oct 2017 15:03:25 Sending previous action history to core

STdeployercore.log

In addition the STdeployercore.log will also show the patch being installed and the error code for the Next Gen definitions:

2018-01-26T21:15:53.2279239Z 134c I DeploymentPackageReader.cpp:783 Deploy package 'C:\ProgramData\LANDesk\timber\sandboxes\InstallationSandbox#2018-01-26-T-21-15-15\0001c460-0000-0000-0000-000000000000.zip' successfully opened unsigned for package IO
2018-01-26T21:15:53.2279239Z 134c I Authenticode.cpp:134 Verifying signature of C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows6.1-kb4056894-x64_tw1158080.msu with CWinTrustVerifier
2018-01-26T21:15:54.2534266Z 134c V UnScriptedInstallation.cpp:30 Executing (C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows6.1-kb4056894-x64_tw1158080.msu /quiet /norestart), nShow: true.
2018-01-26T21:19:19.4406288Z 134c V ChildProcess.cpp:140 Process handle 00000408 returned '3010'.

Windows Update(WUSA) Error Codes

Windows Update Agent Result Codes

Manually Testing the Patch

It is best practice that you download the patch to the device and manually run in in the GUI.  The patch should display a message giving the same reason for not installing in a dialog. Once you have verified why the patch will not install manually, contact support and be sure to upload the vulscan log from the repair task to the case.

Detection Issues That Support Likely Will Not be able to Resolve

Certain false detection issues can occur that support will likely be unable to troubleshoot or resolve.  The most likely of these is with our powershell scripts running on Windows 7 devices. The example from another vulscan log below shows a script error when trying to run on a device.

Mon, 23 Oct 2017 14:58:48 File OSVERSION version within specified 
Mon, 23 Oct 2017 14:58:48 Prod Windows 7 Service Pack 1 (ID:WIN7SP1) verified OSVERSION, found: 6.1.7601.1 
Mon, 23 Oct 2017 14:58:48 Prod Windows 7 Service Pack 1 (ID:WIN7SP1) verified C:\Windows\explorer.exe, found: C:\Windows\explorer.exe 
Mon, 23 Oct 2017 14:58:48 Running detection script 
Mon, 23 Oct 2017 14:58:48 Content filename: 'RollupFixB201710.ps1' 
Mon, 23 Oct 2017 14:58:48 Writing script content to file 'C:\Windows\TEMP\RollupFixB201710.ps1' starting at line 5 
Mon, 23 Oct 2017 14:58:48 Launching external script processor: <powershell.exe> 
Mon, 23 Oct 2017 14:58:48 args: <-executionpolicy bypass C:\Windows\TEMP\RollupFixB201710.ps1> 
Mon, 23 Oct 2017 14:58:48 External timeout: 60 
Mon, 23 Oct 2017 14:58:48 Called CreateProcess: "powershell.exe" 
Mon, 23 Oct 2017 14:58:48 Error 2 launching application <powershell.exe> 
Mon, 23 Oct 2017 14:58:48 4041681_MSU detected 
Mon, 23 Oct 2017 14:58:48 VUL: '4041681_MSU' (windows6.1-kb4041681-x86.msu) DETECTED. Reason 'Unexpected error in custom script source. See agent log for details'. Expected ''. Found ''. Patch required 'windows6.1-kb4041681-x86.msu'. 

Mon, 23 Oct 2017 14:58:48 Patch is NOT installed 
Mon, 23 Oct 2017 14:58:48 Last status: Done

You can see from the log that the script attempted to run but got a 'Unexpected error in custom script source. See agent log for details' error. In all cases where we cannot get a proper detection from our scripts Ivanti errs on the side of caution and will throw a DETECTED and will try and install the patch just to be safe.

Issues that arise from script errors are difficult to impossible for us to troubleshoot.  The likely cause is a security setting or Antivirus/Malware program that prevents the script from running.  GPOs and powershell policies can also interfere if they are enabled in the customers environment. Since issues like this are impossible to replicate in our teat labs and are unique to the customers environment, the customer is advised to do some troubleshooting and see if security settings and restrictions can be lowered on a test device to try and get the script to run properly before contacting support.

Issue

Error when downloading content "Hash for patch (Patch Name) does not match with host. Discarding."

You can also be getting the following errors:

Causes and Resolutions

For security purposes, each patch file referenced within a vulnerability definition contains a hash value to ensure that the file referenced is the authentic patch file.

After downloading the patch, if the patch does not match, Patch Manager will discard the file.

There are various causes that can contribute to this issue.

Vendors use static URLs

This issue occurs because the update contains a static URL for the vendor file. This means that the vendor uses the same URL for thier files and they only make the latest patch available to download.

Often this is seen with Adobe and Google Crome updates.

A web caching or other networking appliance within the environment is causing the contents of the file to change or is serving up a deprecated version of the file

This is especially when getting the "Invalid XML file TOC_Product.xml" error.

In many environments, web caching appliances are in place.   When Ivanti Patch and Compliance Manager attempts to download the file, the Internet caching appliance intercepts the request and incorrectly delivers an older version of the file.   Once the file is downloaded on the Ivanti Core Server, the hash check fails.

In this instance, the cache for the particular failed file can be cleared on the Internet caching appliance, the entire cache can be cleared, or the Internet caching appliance can be configured to allow the core server to bypass caching.

Manually copying the file to the patch storage directory from a computer that bypasses the Internet caching appliance can verify that this is the issue.

The patch content needs to be updated as the local content is out of date

If the Ivanti Patch Content has been changed since the last time patch content has been downloaded this error can occur.

Download patch content again.   If the error still occurs, try downloading from a different patch content server (US West Coast, US East Coast, or Europe)

Patch definition content is corrupted in the database

If the latest patch content is downloaded, there are no caching appliance is in the environment, the locally downloaded patch file has been deleted from the storage directory, and there is still a failure, the following SQL query can be run to force the content to download again.

This query changes the LANDESKRevision number to "0".   When the core server compares revision numbers with the revision on the Ivanti patch content servers the version on the Ivanti patch content server will be higher, thus the content will download again:

UPDATE Vulnerability SET LANDESKrevision = 0 WHERE vul_id = 'definition name'

A more advanced variation on this is:

select * from VULNERABILITY where VUL_ID IN ('<vul_no1>', '<vul_no2>')

Update VULNERABILITY 
set LANDESKREVISION=0 where vul_id in ('<vul_no1>', '<vul_no2>')

The file has changed after the patch definition was published

If other steps fail, it is possible that the file has changed, and it is necessary for Ivanti to update the patch content.

It is possible that the vendor changed the contents of the file but kept the same filename, and Ivanti has not updated the related vulnerability definition yet.   At times a vendor will make a change to a file but does not publish information regarding the change.

If this is the case, this download should fail regardless of the Core server attempting the download.   This would be a global issue.

In this instance, contact Ivanti Support and request that the patch content be updated.   An Ivanti technician can also verify the file download failure internally.

Manual download patches

It can be difficult to determine if the hash does not match for patches that must be manually downloaded from the vendor.   Typically these require going to the vendor web site, finding the correct file and version, renaming it to the unique filename specified in the rule for the definition, and placing it into the patch download folder.

Issue

Vulnerability scanner (vulscan) is hanging with the message "Checking for other instances of scanner or software distribution agent".

Cause

The vulnerability scanner cannot run while another instance of the vulnerability scanner is running.

The vulnerability scanner cannot run while another instance of the software distribution agent (SDCLIENT) is running.

Resolution

Check to see if the running Vulnerability scan is stuck, or if it is currently doing something.

You can check the log files in C:\ProgramData\LANDESK\Log to see what is currently occurring.   Sort by date and time so that the newest is on top and look at the latest logs.

Vulscan is responsible for several activities.  A currently running log will typically be called vulscan.PID_XXXX.log (Where the PID stands for the Process ID of the running Vulscan process)

In addition if an SDCLIENT process is running the vulnerability scanner will wait for it to finish or eventually it will time out waiting for it.   Check if there is an SDCLIENT process running.

Verify that the SDCLIENT process is doing something, if it is not you can likely End Task in task manager to allow Vulscan to proceed.

I've got patches piling up.

the repairs are failing due to "Status marked as detected because pre-req check failed."

not sure how to go about troubleshooting this. its started with the new patching process this year.

I do have the MS registry key set on the computer I am using to try and get patched first.

example:

Hi

I am very new to the forums and Landesk in general

I have a problem upgrading windows 10 from 1511 to 1709 using patch and compliance.

Here is what I've done so far

I followed the below guide, downloaded the ISO from our Microsoft portal, we have both Enterprise and Pro in our environment so I created a file for both of them and  Landesk accepts them both as downloaded

How to upgrade to Windows 10 Creators Edition using Ivanti Patch Manager

Then I distributed the ISO's to our preferred server and created a repair job

this job I sent to a specific machine and within 2 minutes it showed Success

now for my stress factor..

Noting happened on the machine itself, I cannot see the package on the machine and it does not patch.

I have created several software packages and set up PXE booting for the environment but this one I cannot solve

I sent a package to the machine to check if I could install to it, and that works as it should

I hope you guys can point me in the right direction