Quantcast
Channel: Ivanti User Community : All Content - Patch Manager
Viewing all 1121 articles
Browse latest View live

How to upgrade to Windows 10 Anniversary Edition using Ivanti Patch and Compliance

$
0
0

This article describes how to use Ivanti Patch and Compliance to upgrade to Windows 10 Anniversary Edition

 

For information about upgrading to Windows 10 Creators Edition (1703) see How to upgrade to Windows 10 Creators Edition using Ivanti Patch Manager

 

Windows 10 Anniversary Edition is also known as Windows 10 RS1 or Windows 10 1607.

 

Goal

 

Upgrade the clients to Windows 10 version 1607.

 

Steps

 

These steps use the Ivanti Patch and Compliance Manager definition called "W10V1607". A prerequisite for installing this version to a client computer is that the target computer must have 2GB of memory or higher.  If the client computer does not have 2GB of memory or higher it will be detected but it will not attempt to install the update.

 

  1. Download or otherwise acquire the Windows 1607 media for the version of Windows that you are updating (Education, Professional, or Enterprise)

    This can be done by following the instructions in this link.

* MediaCreationTool.exe from http://go.microsoft.com/fwlink/?LinkId=691209 can create only two editions: Windows 10 Professional or Windows 10 Home. There is no option to download and create editions Windows 10 Enterprise or Windows 10 Education. Also within a Windows 10 ISO file created using the MediaCreationTool.exe there is no ..\sources\install.wim file and the verification of what edition Windows 10 is, cannot be performed using dism.exe -- "dism.exe /get-wiminfo /wimfile:F:\sources\install.wim"

 

Please note that the MediaCreationTool will download the latest Windows 10 version, which is at this point 1709 (Fall Creator Update)


If using a copy from MSDN this is likely an all-in-one image, only the product key changes the version.

  1. Place this .ISO into the \ManagementSuite\LDLogon\Patch\ directory on your core server.  If you have changed the patch storage location, place it in the equivalent directories.
  2. Open the LANDESK Management Suite Console and go to the Security and Compliance Tool group
  3. Open the Patch and Compliance Tool
  4. Ensure that you have downloaded the latest updates in the Vulnerabilities category.

    Vulneraiblities category.png
  5. After downloading the vulnerabilities category, find the "W10V1607" definition.  This is the definition that we will be using to upgrade Windows.

    Win10v1703.png

  6. Next, examine the properties of the definition by double-clicking it.

    You will notice that there is a list of rules in the definition.  You need to select the correct rule that matches the version of Windows you are trying to upgrade.
  7. Note the following in the description tab of the definition:

    W10v1703-properties.png
  8. Double-click the rule that matches the version of Windows you are trying to upgrade.  Be careful to choose the selectx86 or x64 version.

    W10V1703 Rules.png

  9. You will need to make sure that your .ISO file for the Windows upgrade matches exactly the filename within the rule in the Patch information section under Unique filename.  In order to do this highlight the filename and make sure to go all the way to the end just prior to ".ISO" and then press Ctrl-C to copy the file name except the extension.
  10. Right-click and rename your .ISO file from step 1 and paste in the name you just copied from the definition rule.  Make sure it still has the .iso extension and that it is not named ".iso.iso" or anything like that.  It must match exactly with the Unique Filename in the rule.
  11. Run Download Updates one more time to ensure that the "Downloaded" Yes/No column in the rule is updated to "Yes".  If it does not update, check your storage location and the name of the .ISO to make sure it matches.
  12. Run a scan and repair as usual.

 

Further information about the Patch Manager definition release can be seen here.

 

How to block automatic update to the Anniversary Edition of Windows on client systems

 

In order to block Windows 10 systems from automatically installing Operating System Upgrades, the following methods may be used:

 

Group Policy

Computer Configuration / Administrative Templates / Windows Components / Windows Update Policy

Setting: Turn off the upgrade to the latest version of Windows through Windows Update

 

Registry

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

DWORD value: DisableOSUpgrade = 1

 

Ivanti Patch and Compliance Manager Definition

The DISABLEWIN10UPGRADE can be sent as a repair job to turn off the Windows 10 auto-updates to newer OS versions.

This definition sets the Registry key listed above.


Issue: Clients Returning "Server Busy, unable to complete request" Code 433 When Patching Tasks Are Run

$
0
0

Issue

You are getting Server busy, unable to complete request Code 433 on all patch jobs ran on the clients. This can be seen in the status of a patching task in the Scheduled Tasks of the console or seen in a vulscan.log file located on the client.

 

Cause

Likely patching is still taking place but returning information to the core is unable to complete which is giving this error.  You can verify this by looking in a vulscan log located in the C:\Programdata\LANDesk\Log folder on the client.  In the vulscan.log file at the very end, you should see a postcgi.exe entry like the ones shown below but ending with an error near the end of the vulscan log when it tries to upload data to the core.

 

A good entry is show here:

Thu, 03 Aug 2017 11:08:39 HTTP POST: http://LDMS20163.ak.local:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{E0098567-4CC5-1F41-B922-2D5DDB6B8FDB}_034.vrz
Thu, 03 Aug 2017 11:08:39 Setting a proxy...
Thu, 03 Aug 2017 11:08:39 Setting socket timeout to 1000 * 60 * 4
Thu, 03 Aug 2017 11:08:39 Success

 

A failing log entry is shown here, the HTTP error code on the end of the failed entry might be different in your environment, note the 433 return code at the bottom of the vulscan log:

Thu, 03 Aug 2017 09:52:18 HTTP POST: http://LDMS20163.ak.local:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{E0098567-4CC5-1F41-B922-2D5DDB6B8FDB}_034.vrz
Thu, 03 Aug 2017 09:52:18 Setting a proxy...
Thu, 03 Aug 2017 09:52:18 Setting socket timeout to 1000 * 60 * 4
Thu, 03 Aug 2017 09:52:19 Failed http://LDMS20163.ak.local:443/incomingdata/postcgi.exe?prefix=vulscanresults\&name=ScanResults_{E0098567-4CC5-1F41-B922-2D5DDB6B8FDB}_034.vrz on server (0), server status: 404.
Thu, 03 Aug 2017 09:52:19 HTTP Error 404.  Giving up.
Thu, 03 Aug 2017 09:52:19 Last status: Failed: No response from core
Thu, 03 Aug 2017 09:52:19 Failed to put vulnerability results to core as file: 8DB301B1
Thu, 03 Aug 2017 09:52:19 Skipping repair step because scan errors occurred.
Thu, 03 Aug 2017 09:52:19 ReleaseMutex 'Global\vulscan_scan' succeeded. Code: 0
Thu, 03 Aug 2017 09:52:19 Failed
Thu, 03 Aug 2017 09:52:25 Read from pipe (0x230) failed: 109
Thu, 03 Aug 2017 09:52:25 ClosePipes
Thu, 03 Aug 2017 09:52:25 Exiting with return code 0x8db301b1 (433).

 

Resolution

On the core itself, open IIS Manager.  Select you core name on the left pane then open ISAPI and CGI Restrictions.  An entry for postcgi.exe should be present in ISAP and CGI Restrictions section as shown in the photo.  If one is not present add an entry for it by clicking Add on the right Make sure it is set to Allow and Allow Extension Path to Execute is checked.

 

 

The next section to look at is the incomingdata settings under Default Web Site by expanding the tree. You should see two entries under Handler Mappings One for CGI-exe and ISAPI-dll both should be enabled here in incomingdata but they disabled in the other parts of the website this is normal. If they are not enabled or missing, select Edit Feature Permissions on the right menu and check all boxes in the dialog to Enable or Add Script Map to create an entry.

 

 

 

 

After you make the changes close IIS Manager and run a patching task on the client again.

Dell Hardware Driver Scanning

$
0
0

I must be missing some part of the scan job because none of our computers are scanned for hardware drivers. Is there something I could be missing in Agent config or some way of adding hardware driver scans to inventory scanner?


Thanks

How to Effectively Troubleshoot Patching Related Issues in EPM

$
0
0

Introduction

When facing a Patch Manager issue while using Endpoint Manager there are a few tips you can follow to make it as effective as possible and reduce the amount of time it takes to resolve a support ticket. Providing accurate and detailed information can help your support engineer identify and resolve a patching issue quickly and efficiently. This document will outline best practices on how get all the necessary information to fixing patch related issues. Also, the hope it can provide some information to our customers to identify issues on their own.

 

Quick reference for support tickets:

Log.zip - Support will request the full 'Log' folder located on the client C:\Programdata\Landesk. For more effective logging and information see the Logging section

Vulnerability ID(s) - If we are dealing with a specific patch, having the Vulnerability ID(s) will help support identify the problem patch faster without the need to inquire for that information. When dealing with 10+ vulnerabilities provide 2-3 examples.

The behavior of the patch when manually run outside the Ivanti product - This is important to know the behavior outside the product to know the expected behavior the OS takes. You'll want to inform the engineer of this behavior.

The following sections are for information and self troubleshooting. When opening a support ticket the support engineer will require for the information in the Quick Reference.

 

Logging

Logs are the most important information you can sent your support engineer when opening a ticket. This gives detailed information of the patch process so you or the support engineer can identify the cause of the issue. There are a few things to keep in mind when raising a ticket with support.

 

Vulscan.log - Make sure that the issue resides in your vulcan.log(s). You'll want to make sure the issue resides in those logs in order for support to follow the process flow leading up to the failure and completion. It is important that, if possible, the vulscan process completes this provides a return code support can use to identify the general issue. For more information on return codes take a look at About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes. It is always a good idea to send logs from a client that has very recently been able to replicate the issue.

 

STDeployerCore.log - Since the introduction of our Next Gen patches this log has been added to identify the results of the patch installation attempt. One of the most important pieces of information contained in this log is the windows return codes that the client returned when attempting to install the patch. If a patch is failing this is an excellent place to start in determining what reason for failure is. Here is an example of a unsuccessful patch install

 

2018-07-16T10:41:08.0014620Z 044c V UnScriptedInstallation.cpp:30 Executing (C:\Program Files (x86)\LANDesk\LDClient\sdmcache\windows10.0-kb4343669-x64-1803_tw15004-40546.msu /quiet /norestart), nShow: true.
2018-07-16T10:41:11.2981195Z 044c V ChildProcess.cpp:140 Process handle 00000730 returned '2149842967'.
2018-07-16T10:41:11.2981195Z 044c W DeployerImpl.cpp:106 Patch state is 'Failed'. Registry bread crumb patch state not updated.

 

Here you can see '2149842967' this is the windows return that the patch returned. A quick web search will assist you in determining what that return means and how to handle it. In this example it is a return of 'Not applicable for this machine' this is a detection logic issue from Ivanti and should be brought to the attention of support. It is helpful to run the patch manually to see if you get a similar result, support will want to know this.

In some/most cases if the OS fails to install the patch outside of the Ivanti product then it may be an issue with the OS and not Ivanti. You'll need to use your own discernment when it comes to this. If you're not sure, support will be able to help you.

Your Support engineer may request other logging if they find it applicable.

 

Helpful Links:

About Ivanti Patch and Compliance Manager and Ivanti Antivirus return codes

System Error Codes | Microsoft Docs

Custom Definition for Full Cumulative - Windows 10

$
0
0

Hi

 

Is it possible to adjust the logic described in this article, so that I can create a custom definition for a Windows 10 monthly, which forces the full cumulative instead of trying to detect the delta via the N minus method described. I tried cloning the existing def and then disabling the delta Definition rules in there, but a machine will just scan against it and not detect the full cumul as required. Any help appreciated.

 

https://community.ivanti.com/docs/DOC-65653

Gather history task runs but ComputerVulnerability table not populated

$
0
0

I am told that the Gather History task runs on a schedule, but I don't have access to see messages or logs.

 

When I query the ComputerVulnerability table it is empty. That is the correct table right?

 

Can anyone think of a reason why that may not be getting populated?

 

I will try to get access to the logs, etc. but that will take some time.

 

Thanks...Paul

patching to Windows 10 - 1803

$
0
0

I wanted to share a bit of behaviour I noticed with the service pack definitions for Windows 10 1803.

 

I am currently testing an update process for moving our clients from v1709 to v1803. We have a multi lingual environment, so I have created a custom definition using a clone of the standard patch W10V1803 definition in Patch Manager.

 

I have customised my ISO image by adding the language packs we require in our build using DISM. I then tested the upgrade by mounting the custom ISO manually and then using the standard setup commands as included in the patch definition, minus the /noreboot switch:

 

setup /auto upgrade /quiet /dynamicupdate disable

 

Every time I run this patch manually on a client it works first time.

 

However, when I try to push the patch out using the custom definition (bearing in mind the script has not been modified from the original W10V1803 definition) I am getting very intermittent results. In many instances, the update appears to run but when the system reboots, nothing happens and it just reboots back in to Windows 1703 with no error prompts or failed update warnings. As far as Ivanti is concerned, I am getting a report that the patch has been successful.

 

On further investigation I have found that the definition script appears to be finishing before the upgrade has actually completed, causing Ivanti to request a reboot. I monitored one client and could clearly see that the setup.exe and setuphost.exe files were still running in the background.

 

I notice in the definition there is a time out script:

 

Option Explicit

Sleep 1800*1000

SetRebootRequired

ReportRepairResult True, "Restart successfully."

 

I am guessing I will need to modify this script, but I am curious does anyone know why this is included in the definition?

 

 

 

Does anybody know which DB Table provides the 'Installed Patches' data in the Security and Patch Information dialog?

$
0
0

This is more of a request for verification of what I have found in the forum already.

 

I am looking to gather the Installed Patches for various machines, hopefully in Xtraction, but an LDMS query might work as well.

I see 2 posts from 2013/2014, but wanted to see if there is updated info available.

 

Here are the major items from those answers:

"That data is coming from the ComputerVulnerability table. That table is only populated when a Gather Historical Information task is run, and only contains information according to the constraints that you configure for that task."

     That table is not populated in my environment, but I am still seeing data in the dialog, so I assume that the next statement is where the dialog is getting the data:

"This information is also stored in the CVResults table, however that data is in BLOB format, so isn't really accessible outside the LANDesk Console"

     The actual Results field is a binary field so I can't extract anything from there myself.

 

Can anyone verify if the answers, and my assumptions, above are still true?

 

Any other way to get the info without the ComputerVulnerability table?

     I have done a ton of queries of other tables and just don't see the info I need.

 

Thanks a lot...Paul


About Patching: 101 - A simple, effective method of patching

$
0
0

As the Enterprise Ivanti Endpoint Manager Administrator of a large company that has had over 15 Core Servers with over 12,000 systems and over 20 other Ivanti tech's to support I have found "how should I patch" to come up often at my location as well as on this forum.

 

Like Windows, there are 3 or more ways to do most anything in Ivanti Endpoint Manager patching being one of those, and I have re-written the way I advocate our techs patch in Ivanti from the way I recommended a few years back and thought I would post it here for other to use as needed. It is not the only way, nor am I saying it is the best way.

 

Please keep in mind that this is a basic method, simple and effective.  I did not go into Auto-Fix, some of our advanced tech's use it, others don't.  I wanted something a newbie could pick up, read and begin patching in a very short amount of time.

 

Picking what patches to patch can be a political nightmare depending on your companies policies.  Ours went from 12 groups doing it all differently, some patching critical's only, some not patching, others patching everything possible to a reduced number of groups that all now have a "baseline" that is set from up above that is pretty in-depth and aggressive deadlines to have them patched by.

 

In short, we patch all security related items with few exceptions that are patchable via Ivanti and we do it aggressively as you must nowadays in this world of exploits.

 

If you are not patching, I strongly suggest you start.

 

Attached is the method I recommend, it uses two tasks, one a "Push" the other a straight "Policy".  Why not a "Policy Support Push" you ask?  We were doing that but are finding that some systems will stick in the "active" bin of the scheduled tasks for some reason (being researched) and thus the task will not become a policy.  If you restart the task, some of those systems will clear, but then others will stick... and so on.

 

It goes over creating a group of patches, creating the tasks, targeting the systems and scheduling the deployment.

 

I look forward to your feedback and I hope this helps some of you.

Windows 10 Folder Size

$
0
0

Has anyone else had problems with their C:\Windows\Installer and C:\Windows\WinSxS folders getting very large in Windows 10?  I'm looking for recommendations on how to decrease the footprint of our Windows 10 VMs.  From what I have read, the C:\Windows\Installer folder stores .msi and .msp files from updates and they shouldn't be deleted, however, disk space is an issue on our network and these two folders are taking up a lot.  Thank You in advance!

About Periodic Patch Engine Content Updates

$
0
0

This article is regularly updated with information

Overview

 

 

The Ivanti EPMpatchengine allows binary updates through definition downloads. At times it is necessary to make changes to some of the binary files to remediate issues.

 

When changes are made to these binaries and they are published to the patch content servers they will automatically be downloaded to the core (during the next content sync initiated by the core). When the client next scans in, it will check to verify what version of these binaries it has compared to the version on the core server. If needed, these binaries will be downloaded to the client automatically using the standard download mechanism (i.e., utilizing the CSA and/or peers and preferred servers if configured).

 

We only make changes to these files if it is found necessary to correct a critical issue. Below lists the file(s) updated, the date, and the reason why the change was necessary.

 

 

We will update the list before every expected change to binaries. However, in some cases more urgent fixes are required, and in such cases, we will post the change to this list a short time after the release.

Updated Binaries

 

File UpdatedDate UpdatedDescription
Timberhlpr.dll02/13/2018To correct an issue where if a patch took more than a specified amount of time to install it would fail
Timberhlpr.dll06/07/2018To correct an issue where shared patches were downloaded multiple times
Timberhlpr.dll07/27/208To improve scan performance

patching windows to 1709

$
0
0

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

False Patch Missing Status

$
0
0

We have system that is displaying several updates as missing even though they are installed on the system. Verified using get-hotfix and installed windows updates. Also checked against the patch detection details that Ivanti uses. Re-scanned system and refreshed the view several times but it won't show the patches as being installed. Also it seems to want to install Q3063109 even though the VM is no longer hosted on Hyper-V anymore.

 

Is there anyway to fix the issues.

 

Current patch status,Patch release date,Original patch status,Product,SP,Affected machine count,Patch type,Bulletin ID,KB,Bulletin title,Vendor severity,Uninstallable,Downloaded,EOL

Patch Missing,6/17/2015,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Non-security patch,MSWU-1391,Q3064209,June 2015 microcode update for Intel processors in Windows,None,Yes,Yes,1/10/2023

Patch Missing,7/24/2018,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Non-security patch,MSNS18-07-4339284,Q4339284,Time zone and DST changes in Windows for North Korea,None,Yes,Yes,1/10/2023

Patch Missing,7/18/2018,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Non-security patch,MSNS18-07-QP81-4338831,Q4338831,"Preview of Monthly Rollup for Windows 8.1 and Windows Server 2012 R2: July 18, 2018 (KB4338831)",None,Yes,Yes,1/10/2023

Patch Missing,9/21/2016,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Non-security patch,HVCU-001,Q3063109,Hyper-V integration components update for Windows virtual machines that are running on a Windows 10-based host,None,No,Yes,1/10/2023

Patch Missing,1/10/2018,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Security tool,IVA18-001,Q4072698,"Windows Server guidance (KB4072698), undoing changes from KB4078130",Critical,No,Yes,1/10/2023

Patch Missing,1/5/2006,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Custom action,MSST-001,QSK2745,Custom Action Patch,None,No,Yes,1/10/2023

Patch Missing,7/16/2018,Patch Missing,Windows Server 2012 R2 Standard (x64),CU1,1,Non-security patch,MSNS18-07-4345424,Q4345424,Improvements and fixes - Windows 8.1 and Server 2012 R2,None,Yes,Yes,1/10/2023

patching and security monthly rollups.

$
0
0

So I have a question regarding the microsoft patching and landesk - I have found this document and we are patching based on this

 

Patch Detection for Security-only Quality Update and Security Monthly Quality Rollup

 

We apply the monthly rollups.

 

My question is for the security only updates that are not monthly? so for example the MS18-07-SONET-4340004_INTL definition. this title is Security only update for .NET framework.....

 

Does this patch exist in the rollup? And the cumulative security update for internet explorer July 10 2018. does the cumulative security update exist in the main Security Monthly rollups?

 

Should we be just applying the security monthly rollup ( which contains all patches up to that month ) Or still be applying the .NET update and the IE cumulative updates?

 

What is everyone else doing? this is for Windows 7 still we have windows 10 sorted.

Detected vulnerability Patch not downloaded

$
0
0

EPM 2018.1

Hello, I have Downloaded Updates but I have found some patches, under deteccion rules, that are not automatically downloaded, they download if I right click and select download.

Why is this?

If you could provide a link to a good Patch and compliance download setting explanation, would be fantastic, I think I understand 70% I would like to nail down the other 30%.

Thnx..


Recent Content Changes (June 2018)

$
0
0

Information

 

Changes to our patch content was done in two phases. The attached  spreadsheet includes all of the affected patches.

This will only affect patches that were released before May and then revised.

 

If the vuldef was built with our old tooling and we update it with the new tooling, the download name will change slightly. If the vuldef was built or last modified by the new tooling, then modified again by the new tooling, the download name will NOT change. If there was a revision in detection or URL for example that would cause it to need to be rebuilt.

 

We changed our tooling in May to resolve an issue where the same patch would be downloaded multiple times, once for the Server OS and once for the Workstation OS as a result this may require you to re download the patches in the spreadsheet to ensure the downloaded name matches what is in our content so deployments do not fail.

 

At this point there should be no additional churn, but Content is always subject to change. Going forward, if we make changes such as this, we will post an article to the community before any such changes.

 

You can monitor the Bulletin releases here to see what was modified if they would like.

How to upgrade to Windows 10 Anniversary Edition using Ivanti Patch and Compliance

$
0
0

This article describes how to use Ivanti Patch and Compliance to upgrade to Windows 10 Anniversary Edition

 

For information about upgrading to Windows 10 Creators Edition (1703) see How to upgrade to Windows 10 Creators Edition using Ivanti Patch Manager

 

Windows 10 Anniversary Edition is also known as Windows 10 RS1 or Windows 10 1607.

 

Goal

 

Upgrade the clients to Windows 10 version 1607.

 

Steps

 

These steps use the Ivanti Patch and Compliance Manager definition called "W10V1607". A prerequisite for installing this version to a client computer is that the target computer must have 2GB of memory or higher.  If the client computer does not have 2GB of memory or higher it will be detected but it will not attempt to install the update.

 

  1. Download or otherwise acquire the Windows 1607 media for the version of Windows that you are updating (Education, Professional, or Enterprise)

    This can be done by following the instructions in this link.

* MediaCreationTool.exe from http://go.microsoft.com/fwlink/?LinkId=691209 can create only two editions: Windows 10 Professional or Windows 10 Home. There is no option to download and create editions Windows 10 Enterprise or Windows 10 Education. Also within a Windows 10 ISO file created using the MediaCreationTool.exe there is no ..\sources\install.wim file and the verification of what edition Windows 10 is, cannot be performed using dism.exe -- "dism.exe /get-wiminfo /wimfile:F:\sources\install.wim"

 

Please note that the MediaCreationTool will download the latest Windows 10 version, which is at this point 1709 (Fall Creator Update)


If using a copy from MSDN this is likely an all-in-one image, only the product key changes the version.

  1. Place this .ISO into the \ManagementSuite\LDLogon\Patch\ directory on your core server.  If you have changed the patch storage location, place it in the equivalent directories.
  2. Open the LANDESK Management Suite Console and go to the Security and Compliance Tool group
  3. Open the Patch and Compliance Tool
  4. Ensure that you have downloaded the latest updates in the Vulnerabilities category.

    Vulneraiblities category.png
  5. After downloading the vulnerabilities category, find the "W10V1607" definition.  This is the definition that we will be using to upgrade Windows.

    Win10v1703.png

  6. Next, examine the properties of the definition by double-clicking it.

    You will notice that there is a list of rules in the definition.  You need to select the correct rule that matches the version of Windows you are trying to upgrade.
  7. Note the following in the description tab of the definition:

    W10v1703-properties.png
  8. Double-click the rule that matches the version of Windows you are trying to upgrade.  Be careful to choose the selectx86 or x64 version.

    W10V1703 Rules.png

  9. You will need to make sure that your .ISO file for the Windows upgrade matches exactly the filename within the rule in the Patch information section under Unique filename.  In order to do this highlight the filename and make sure to go all the way to the end just prior to ".ISO" and then press Ctrl-C to copy the file name except the extension.
  10. Right-click and rename your .ISO file from step 1 and paste in the name you just copied from the definition rule.  Make sure it still has the .iso extension and that it is not named ".iso.iso" or anything like that.  It must match exactly with the Unique Filename in the rule.
  11. Run Download Updates one more time to ensure that the "Downloaded" Yes/No column in the rule is updated to "Yes".  If it does not update, check your storage location and the name of the .ISO to make sure it matches.
  12. Run a scan and repair as usual.

 

Further information about the Patch Manager definition release can be seen here.

 

How to block automatic update to the Anniversary Edition of Windows on client systems

 

In order to block Windows 10 systems from automatically installing Operating System Upgrades, the following methods may be used:

 

Group Policy

Computer Configuration / Administrative Templates / Windows Components / Windows Update Policy

Setting: Turn off the upgrade to the latest version of Windows through Windows Update

 

Registry

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

DWORD value: DisableOSUpgrade = 1

 

Ivanti Patch and Compliance Manager Definition

The DISABLEWIN10UPGRADE can be sent as a repair job to turn off the Windows 10 auto-updates to newer OS versions.

This definition sets the Registry key listed above.

Agent Health Dashboard: Total vs. Enabled

$
0
0

EPM 2017.3

Hello, I would like to create a dashboard on the total of devices vs. the tatal of devices with Agent health Deployed. My goal if to have 100% of devices to have Agent health enabled.

I found this: How to create a chart for LANDESK Agent Health in the Dashboard?

But this shows definitions related to Agent health.

 

Any help is appreciated,

Best.

Disable replaced rules: Recurring Task.

$
0
0

EPM 2017.3

 

Hello, disable replaced rules seems to be a nice feature and an important one, however, I don't see a way to schedule a -recurring- task for it .

I'm overestimating its importance or is there a way and I just don't know how?

 

Any input is appreciated.

est.

How to set up a dark network Core Server (without outside network access)

$
0
0

How to set up your Dark Network Core: Step by step

 

 

Description

This document details the procedure for copying definitions from a "light core" (A core that is connected to outside networks) and a "Dark Core" (a core that is not connected to outside networks)  This is often done for security purposes or lack of connectivity.

 

 

Assumptions

 

  • The user has a familiarity with Ivanti Endpoint Manager and associated files and functions
  • The user has 2 servers, one "Light" and one "Dark" (One with Internet connectivity and one without internet connectivity)
  • The user has Ivanti Endpoint Manager installed with default parameters, file and drive locations, etc.

Process

 

Note: Due to current changes to the Ivanti Patch and Compliance Definitions, the Dark Core will need to have period access to the internet.  If you do not have periodic access to the internet, please follow only Step Six and then the steps in "Additional information for Dark Cores with no internet access"

 

This issue is being reviewed by our Development team and more communication will follow.

 

Step one: Prepare both core servers to have accurate data

 

In order to download a complete set of data to transfer from the light core to the dark core, the database tables related to Patch Manager must be reset.  This must occur on any core server that has previously downloaded patch data, otherwise, a complete set of data will not be downloaded.

 

This can be done on both core servers by doing the following:

 

    1. On each core server, open a command prompt on the server and change to the C:\Program Files\LANDESK\ManagementSuite folder.
    2. Run "CoreDbUtil.exe /patchmanager".
    3. Open the process list in Task Manager (right-click the taskbar and select "Task Manager) and watch for CoreDbUtil.exe to drop from the list to make sure it has finished.
      (The log for CoreDBUtil.exe is located in the main log location at \Program Files\LANDESK\ManagementSuite\Log)

 

Step two: Prepare the Dark Core folder structure

 

On the Dark Network Core Server, you will need to have a location for the vulnerability XML files and a location for the actual patches themselves to be stored in. For ease of use, we recommend using the already created patch folder structure that is set up when you install Ivanti EPM. By default, patches are stored in the \Program files\LANDESK\ManagementSuite\LDLogon\patch  folder. If a different location is desired this article can be used to set up the alternative location.

If patches have not been downloaded on the dark core previously the patch folder may not have been created and should be manually created.

 

Step three: Retrieve content on the "Light Core"

 

    1. Within Security and Patch Manager open the Download Updates window and select all of the categories you want to download.
    2. In addition select "Download patches for definitions selected above and also the radio button for "for all downloaded definitions" and click "Apply" and then "Close".
      SelectCategories.gif
    3. From a Command prompt, change to the LANDESK\ManagementSuite folder.
    4. From a Command prompt, type "vaminer /noprompt /copy" and hit enter.  (If scripting this action to run regularly please add the /noui" switch to the vaminer command line switches)

 

(Vaminer.exe is the executable that runs to download content from the Ivanti patch content servers).

 

The first time this is run it will take quite a while as it will not only be downloading vulnerability definitions but also all patches.  (Due to this you will need a large amount of storage space on the dark core server).  This will download updates and store them to a to the patch directory.  The default patch directory is \Program Files\LANDESK\ManagementSuite\LDLOGON\patch.

 

To verify further that this process has completed correctly, in \Program Files\LANDESK\Managementsuite\ldlogon\patch and it's subdirectories you should have .XML files that were generated by the Ivanti Content download to represent your vulnerability definitions.  Do not change the folder structure or files.

 

Step four: Copy PatchSources file to patch directory on Source (Light) Core


Copy ENU_PatchSourcesXXX*.xml (Where XXX equals the current LDMS version) from \Program Files\LANDESK\ManagementSuite\LDMAIN to \Program Files\LANDESK\ManagementSuite\LDLOGON\PATCH on the source core.  This step is necessary because Vaminer.exe (the program that is downloading the Patch Content) expects that file to be in that location.  Again, this needs to match the version you are running: 9.5 (ENU_PatchSources95.xml), 9.6 (ENU_PatchSource96.xml, 2016.3 (ENU_PatchSources101.xml) and so on.  Modification of the file is not necessary, it just needs to exist in that location.

 

               (It has been noted that on LDMS 2017.3 SU3 the file has to be renamed from ENU_PatchSources1013.xml to ENU_PatchSources10132.xml)

 

Step five: Prepare the ENU_PatchSourcesXXX.xml on the Dark Core

 

In the \Program Files\LANDESK\ManagementSuite\LDMAIN folder there will be several files called ENU_PatchSources and then a numerical ending.  These stand for the current and prior versions of LDMS.   Choose the one that is the latest and matches your version on your core server.

 

For example: On a 2017.3 Core server you will likely see three ENU_PATCHSOURCESXXX files:

      • ENU_PatchSources951.XML
      • ENU_PatchSources961.xml
      • ENU_PatchSources101.xml
      • ENU_PatchSources1013.xml

 

We would select ENU_PatchSources1013.xml as this corresponds to LDMS 2017.3 and begin editing it.

 

If your core is not running in the English language you will want to select the XML file that matches your language prefix (ESP, JPN, etc)

 

Modify the Enu_PatchSourcesXXX.xml as modeled below:

Line #3 in the .XML will contain ‘/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&FILENAME=’.  Replace it with  /ldlogon/Patch (or whatever directory you have defined as your patch storage directory).

Before:

PatchesSrcRelativePath>/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=patches</PatchesSrcRelativePath>
<LDAVRelativePath>/kvirus-8.0/mirror</LDAVRelativePath>
<CVEMoreInfo>http://cve.mitre.org/cgi-bin/cvename.cgi?name=%CVE_ID%</CVEMoreInfo>


After:

<PatchesSrcRelativePath>/LDLOGON/PATCH</PatchesSrcRelativePath>
<LDAVRelativePath>/kvirus-8.0/mirror</LDAVRelativePath>
<CVEMoreInfo>http://cve.mitre.org/cgi-bin/cvename.cgi?name=%CVE_ID%</CVEMoreInfo>
  1. Next you will need to change the URL's for each Patch Content Server location.    These will be listed under the <Sites> tag.  Search for <sites> and you will see 3 sites, West Coast, East Coast, and EMEA.

    Delete two out of three sites leaving just one site. 

    You will change the hostname listed in the <URL> field and then the Description.

    EditXML.gif

If you are using content that will be manually copied to the core server, put the name of your Dark Core server.  If there will be constant or periodic network connection between your light core and dark core, put the name of your light core here.


In the following section, you will select the definition download category that you want to download to the dark core and you will edit that entry in the .XML.  We will replace the string that normally works with the Ivanti Patch server and replace it with a local path.

 

The following example is for the vulnerability definition category Windows Vulnerabilities  Again, you will modify the path from the patch server location to a local directory.

Search for /LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=Windows2 the correct section by searching for "Windows2".  Modify the section within the <URL> tags

 

The resulting line will be<URL>/LDLOGON/PATCH/Windows2</URL>. 

 

You also will add the tag <Enabled>true</Enabled>. This is the same as ticking the checkbox next to the vulnerabilities category when bringing up the Download Updates tool.  Without adding the <Enabled> tag you will need to select the categories every time Download Updates is opened.
EditXML2.gif

When renaming these sections per component you wish to download, FILENAME=Windows2 will use the subdirectory name of "Windows2" under the Patch directory after you modify it.  For example, if I wanted to change the source for Ivanti Data Analytics updates, you would search for that category by searching for just that - "LANDESK Data Analytics Updates".

 

You would then modify the <URL>/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=LDDA</URL> to <URL>/LDLOGON/PATCH/LDDA</URL>.

 

     Before:
     <Source>

                     <URL>/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&amp;FILENAME=LDDA</URL>

                   <Description>LANDESK Data Analytics Updates</Description>

                   <ShowInLDSM>true</ShowInLDSM>

                   <ShowInLSM>true</ShowInLSM>

            </Source>

 

     After:
     <Source>

                        <URL>/LDLOGON/PATCH/LDDA</URL>

                        <Description>LANDESK Data Analytics Updates</Description>

                        <ShowInLDSM>true</ShowInLDSM>

                        <ShowInLSM>true</ShowInLSM>

                        <Enabled>true</Enabled>

            </Source>

 

Once all of the edits have been made do a "Save as" and save it as "Patchsourcestemp.xml" and mark it as a read-only file.  (Right-click, go to properties and check the box "Read Only")

After you have marked it as read-only, rename it to "patchsources.xml".  Remember, all of this is taking place in the LDMAIN folder.

 

Step six: Import the vulnerability definitions into the "Dark Core"

 

  1. Now you will need to move the data to the dark core for insertion into the database.   Copy the following to an external hard drive, flash drive, or whatever method you prefer to transfer using.
    • The entire Patch directory and all subdirectories of that folder
    • The entire LDLOGON\Timber folder
    • The following files from the LDLOGON folder on the light core to the LDLOGON directory on the dark core, once at first, but the copying procedure should include copying these files if newer files are detected.
      • Office365Utility (folder)
      • SCSDiscovery_11.1.0.75.exe
  2. These files will need to be copied to the same directories on the dark core server.  If the light core will have access to the dark core this can be done automatically through a file transfer process, automated or otherwise.  The key is to download content on the light core server regularly using the "vaminer /noprompt /noui /copy" switch and then copy the updated data to the Dark Core.
  3. When copying the Patch Directory from your Light Core to your Patch Directory on your Dark Network Core, ensure the directories look the same.
  4. Run Download Updates on the Dark Core Server, if running via script simply run "VAMINER.EXE" from the main ManagementSuite folder.

 

 

If automating the copying of Data from the light core to the dark core:

 

If you are automating the copying of the vulnerability data from the light core to the dark core, ensure the following steps are taking place:

 

    1. "Vaminer /copy /noprompt /noui" is run on the light core server.
    2. All files from the Patch directory, its subdirectories, the LDLOGON\Timber folder and the listed files above in step 6 from the LDLOGON folder are copied to the Patch folder on the dark core.  This can be done using content replication, robocopy or other preferred methods.
    3. Vaminer.exe is run on the dark core (without switches).

 

This should be done on an automated schedule so that these steps take place in sequence and that there is enough time for each step to complete before the next one starts.

Viewing all 1121 articles
Browse latest View live


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