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

Important information on detection logic for the Intel 'Meltdown' security vulnerability

$
0
0

Overview

 

Microsoft has identified a severe compatibility issue with a small number of anti-virus software products.

 

We highly suggest all customers review these issues here:  https://support.microsoft.com/en-us/help/4072699

 

Due to to possible BSOD issues that may occur when installing this update on system with out of date AV software, we will be adding a detection prerequisite as Windows Update does:

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"

Value="cadca5fe-87d3-4b96-b7fb-a231484277cc"

Type="REG_DWORD”

 

If key does not exist you will be offered the detection only version of this patch.

 

This means that the associated patch for a system will not be remediated unless the Registry key is present. This mirrors how the patches are handled by Microsoft. Full details regarding the offering of the patch, and options if the Registry key is missing, are located in the Microsoft article here: https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

 

The patches will be offered for deployment if the key exists.

Affected patches:

  • MS18-01-IE Q4056568
  • MS18-01-SO7 Q4056897
  • MS18-01-SO8 Q4056899
  • MS18-01-SO81 Q4056898
  • MS18-01-W10 Q4056888, Q4056890, Q4056891, Q4056892, Q4056893

Affected CVEs:

  • CVE-2017-5753
  • CVE-2017-5715
  • CVE-2017-5754

 

Link to Security bulletin advisory:  https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

 

Please note that this reg key will be required for the February 2018 cumulative patches that replace these listed in this document and reg key will be needed for all replaced monthly patches for the foreseeable future as well.


Intelamt_mitigation keeps installing and force a reboot

2016.3 SU7 Updating Definitions Signature Is Not Valid

$
0
0

After updating our core to 2016.3 SU7 (I know it's a BETA, but I was hoping fix 382509 would work for us) our Definition updates for Patch and Compliance are failing with following errors:

 

Signature is not valid

Failed to download platform information

 

Checking the vaminer.details.log I see several errors:

 

INFO  6060:LoadingPatchSources : Certificate fail chain of trust validation.

INFO  6060:Main Thread : Signature is not valid

6060:Main Thread : Failed to download platform information

 

INFO  6060:LoadingPatchSources : Alert.RaiseAlert succeeded : alertId = internal.ldms.SPM.SignaturesDidntMatch

 

INFO  6060:LoadingPatchSources : File https://patchemea.landesk.com/LDPM8/ldvul.php?KEYWORD=filename&FILENAME=Virus4/10107_updates.xml does not exist

INFO  6060:LoadingPatchSources : About to check source type for preload steps

INFO  6060:LoadingPatchSources : Load: https://patchemea.landesk.com/LDPM8/ldvul.php?%Credentials%KEYWORD=filename&FILENAME=Virus4/

INFO  6060:Main Thread : No updates found.

 

I have worked with support and re-imported the Digicert GloballRoot CA certificate as a Trusted Root CA, and have tried various settings related to our proxy and firewall with no success. It appears to be related to the 'Verify digital signatures/hashes before downloading setting' which has been enabled in SU7 seemingly without warning (I know it is enabled in 2017.1 and above), but the definition downloads were working in 2016.3 SU6.

 

How can I get this working again?

Management Suite is unable to download definition updates.

$
0
0

When trying to download updates/definitions through Patch and Compliance in Management Suite 9.0 SP2 all patches fail and one of the following errors is given:

 

Object does not match the specified SHA-256 hash

or

 

 

Signature is not valid

Failed to download platform information

 

 

 

 

I am assuming that this is a problem with the server and not with the source of the updates.

How to leverage Linux vendor tools to remediate vulnerabilities

$
0
0

Ivanti customers want a solution that will allow them to remediate Linux vulnerabilities that are discovered on their client machines. This involves being able to determine what dependencies are required to install the packages for the detected Linux vulnerability. The remediation process needs to account for (install) dependencies that are required so that the vulnerability can be remediated completely.

Ivanti  has implemented a solution to invoke the Linux vendors’ patching tools which will resolve the patch dependencies. The vendor tool will download and install both the dependencies and the detected vulnerability package. This functionality will be called from the Ivanti vulnerability content section that performs the repair function. By leveraging the Linux vendor’s patching tools, we are able to resolve patch dependency issues.

 

Please see the attached document for details.

best practice installing patches

$
0
0

Hello,

 

I have an enviromnet of about 1200 Windows machines. I need to implement a patching solution which would be minimally affecting users. My users complain about prompts to restart a computer. They shut them down when they end their day after 8 hours of work. This way computers are restarted everyday. Whey i deploy patches the percent of installed patches is low. Most of errors are return code 437 "The device must be rebooted first" but computers were already shut down and started so why do these errors happen? I was thinking about setting "ignore pending reboots" Would that be a good idea in my case?

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

 

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.

Yellow Network Alert / Kaspersky

$
0
0

I have an issue since deploying ivanti agent with kaspersky that causes some network icons to show the yellow triangle.

I have found that disabling kaspersky allows it to go away, and I have added some urls based on somethings I have found for the mftconnect sites that Microsoft uses to check in with windows 10 connectivity.

 

Its not a 100% fix. but has has anyone else seen this issue?

 

kasp.png


status marked as detected

$
0
0

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:

Patch Management Best Practices and Structure

$
0
0

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?

Patches with "DETECT" in the name not downloadable?

$
0
0

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

 

 

DETECT.jpg

Error: "Verifying Device ID with Core - Failed: when running a Vulnerability scan

$
0
0

Overview:

When attempting to run a vulnerability scan, the scan will fail.  On the Windows agent, if running in verbose, you'll see the scan hang on Verifying Device ID with the core.  If you browse the logs on the clients, either Mac or Windows, you'll see some 403 error codes similar to the example below.

 

Action SOAPAction: "http://tempuri.org/ResolveDeviceID" failed, socket error: 0, SOAPCLIENT_ERROR: 5.  Status code: 403, fault string: Retrying in 2 seconds...

On the Core, you may see "certificate not presented" for the agent you requested the security scan.

Cause

 

With Enhanced Client Security, it's imperative to have a clean certificate store on the local device for IIS.  Having a non-self-signed certificate in the Trusted Root Certification Authority will cause issues.  The installer will prompt you to remove bad certificates prior to proceeding with the install, but if you have a GPO that may restore the bad certificate.  For more information regarding this issue, see https://help.ivanti.com/docs/help/en_US/LDMS/10.0/default.htm#cshid=RootCertificateConfiguration

 

More detailed information related to certificate troubleshooting is available here:
About Vulscan and SSL Verification

 

Validation

 

If you're having an issue with security scans and want to test a potential bad certificate:

  1. Open Internet Information Services (IIS) Manager
  2. Expand the Sites and click on the WSVulnerabilityCore application.
  3. Open SSL Settings and set Client Certificates to 'Ignore' (default is 'Accept').
  4. If the scan works, that is indicative of the problem. Leaving the configuration at Ignore is NOT recommended and could compromise the Enhanced Client Security.  This is just to test to see if a bad certificate is the cause.

 

Fix

  1. Launch certmgr.msc on the Ivanti Endpoint Manager Core Server
  2. Expand Trusted Root Certification Authorities
  3. Click on the Certificates sub folder and review the certificates in the store, paying particular attention to the Issued By category.  Look for certificates that are not signed by the server itself or by a certificate provider and remove them.

 

On some systems(Core Servers) it may be necessary to change the following registry keys that affect how certificates are trusted:

 

Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, Value name: ClientAuthTrustMode, Value type: REG_DWORD, Value data: 2

Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL Value name: SendTrustedIssuerList Value type: REG_DWORD Value data: 0 (False, or delete this key entirely)

For additional information, see Ivanti's article https://help.landesk.com/docs/help/en_US/LDMS/10.0/default.htm#cshid=RootCertificateConfiguration or Microsoft's article https://support.microsoft.com/en-us/kb/2802568

How to set Autofix attempt Times Before Giving Up

$
0
0

Description

When we use patch manager to deploy patch to client machines, we can set patch to be autofix. Autofix fails and does not attempt to repair again on client machines.

 

Cause

The autofix is set to attempt 1 times before giving up by default. The reason we limit the retries is to prevent reboot loops or blue screen loops. It's very rare, but I'd rather have a high retry count than an indefinite one.

 

Resolution

 

  1. Right click the patch definition and select 'Autofix - Autofix settings...' to open Autofix tab. Set Autofix retry count.
    3.png
  2. Go to the Patch and Compliance to set the global autofix default settings
  3. Click the 'Configure Settings' on menu and select 'Core settings...'
    1.png
  4. Set the autofix retry count.
    2.png

See also How to use autofix in Patch and Compliance Manager and About Autofix and Scan by Scope changes in LDMS 9.6

Do you patch Office 365 and if so...

$
0
0

Do any of you patch Office 365 (2016) using LANDesk / Ivanti?
If so, can you please check something on one of your systems, and let me know if you have this registry setting afterwards?

 

 

When I use LANDesk 2016 to patch it, this key and value get created, I talked with LANDesk, they say they are not do it, but I think they might be wrong.

 

We are not applying any GPO's that Ii can tell, and if I use the built in update feature of Office, this does not occur.

 

This key is created:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate

officemgmtcom

1

 

 

With this value set, the users are then not able to run an update manually, we want them to be able to.

 

This appears to be a setting to allow SCCM management.

 

I have tried numerous things, including removing a system from AD and testing, same key gets applied.

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

$
0
0

Hello,

 

Some of my clients are reporting this issue (all are Windows 7 and all worked fine for years till now)... i have looked at the article with the same title written by Ivanti and all the ISS settings they ask to check are as they are supposed to be. Anything else i can try to figure this out? Again, out of the sudden 10 of 150 clients are exhibiting this behavior.

 

Thanks!


Installing BIOS Updates

$
0
0

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

Would like to set up an Ivanti patch systems with distributed servers and external repositories, cant find the how to .. is it possible?

$
0
0

Would like to set up an Ivanti patch systems with distributed servers and external repositories,

cant find the how to .. is it even possible with Ivanti's patching solution?

 

For example we have 2 major sites

 

Site A has the DB and initial installation on server1 - Site A will have agentless and agent installs, also the repository for the site on Server1

Site B has server2, should server2 use same DB as server1? or have its own DB with Site A reporting on it.

There are lots of smaller satellite offices - want these to report in to Server1/Site A, but have its patches stored on a PC at the site to minimise bandwith usage

 

How do I go about this?

I have read the documentation but its vague and high level

Content downloads fail. Length of LOB data (654136) to be replicated exceeds configured maximum

$
0
0

Issue

When attempting to download the latest content, vulnerabilities fail to download. An error is displayed with the following error in your vaminer.details.log

 

04/24/2018 11:07:54 INFO  138068:Main Thread : Failed to download MS18-04-IE-4092946_INTL.
04/24/2018 11:07:55 INFO  138068:VulnerabilityTOC.SaveToDBThread.2 : Vulnerability.UpdateVulnerabilityLeanXML failed: Length of LOB data (654136) to be replicated exceeds configured maximum 500000.
Use the stored procedure sp_configure to increase the configured maximum value for max text repl size option, which defaults to 65536. A configured value of -1 indicates no limit, other that the limit imposed by the data type.
The statement has been terminated.

 

Cause

This issue is caused by your databases LOB data unable to be replicated past a specific size. When the text replication doesn't have the allowed size it will fail to download the vulnerability. In some cases it will delete any vulnerability that already exist in the database. i.e vulnerabilities that are being updated by the Ivanti EPM servers.

 

Solution

The simplest solution to this issue is to either increase or make unlimited the size of the replication text size. There are several ways to do this but the simplest way is through Microsoft SQL Server Management Studio.

 

  1. In Object Explorer, right-click a server and select Properties.
  2. Click the Advanced node.
  3. Under Miscellaneous, change the Max Text Replication Size option to the desired value. You may use -1 to indicate an unlimited amount

For additional methods and more information please visit: Configure the max text repl size Server Configuration Option | Microsoft Docs

Best time to use Global Autofix

$
0
0

Hi,

 

We are still fairly new here to using EPM and have begun creating Rollout projects for our 3rd party software updates. We use an Alpha/Beta/Prod workflow but wondering if it is generally advised to set something to Global Autofix after it has moved through the patching cycle.

Security content Automation Protocol

$
0
0

Does anyone use SCAP (Security Content Automation Protocol)?  It is an add on to the Patch and Compliance section of Ivanti Management Console. 

 

I can get it to run, but don't get results I am expecting.

 

Looking to talk with anyone that has any experience with it.

Viewing all 1121 articles
Browse latest View live


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