Causes

Note: The "console system" refers to the system where you are running Ivanti Patch for Windows or Shavlik Protect.

1. Ensure that you are on the latest version/build of Protect.

Whenever we have a new version released there is a possibility that there may be bug fixes or product improvements which could help resolve your issue.

You can verify the latest version and download it from the following link:

https://go.ivanti.com/Web-Download-Patch-Windows.html

2. Make sure that your console system has enough resources to run your scans.

If you are scanning a high number of machines you may need to increase the CPU and/or memory available to the console system. Our hardware system requirements for processor and memory are as follows:

Processor/CPU:

• Minimum: 2 processor cores 2 GHz or faster
• Recommended: 4 processor cores 2 GHz or faster (for 250 - 1000 seat license)
• High performance: 8 processor cores 2 GHz or faster (for 1000+ seat license)

Memory/RAM:

• Minimum: 2 GB of RAM
• Recommended: 4 GB of RAM (for 250 - 1000 seat license)
• High performance: 8 GB of RAM (for 1000+ seat license)

For more information, see Protect Console System Hardware Performance Guidelines.

3. Antivirus or real-time threat protection software may be scanning our patch scan results as they are being sent back to the Protect console system.

Sometimes antivirus software, in particular those that perform on-access scanning may slow down the patch scan process. Most often we see these programs slow the process as the results are sent to the console's arrivals folder to be imported to the database.

Solution:

-Test disabling your antivirus/threat protection software to see if scans run faster while it's disabled.

-Create an exception in your Antivirus/threat protection for the following folder on the console machine:

On Windows 7, 8, 2008, 2012, or Vista: C:\ProgramData\LANDesk\Shavlik Protect\Console\Arrivals

On Windows XP or 2003: C:\Documents & Settings\All Users\Application Data\LANDesk\Shavlik Protect\Console\Arrivals

4. There may be network/configuration issues.

The most common issue is that high latency will cause scanning of remote systems to take a long time to complete. Things to check:

-Check the latency.

On your console system run a ping connecting to a target system. To do so click Start > Run > type CMD and hit enter, then enter the following command- ping [target machine name or ipaddress] i.e ping machine01 or ping 10.1.10.5.

The higher the latency (the value next to time=), the longer you can expect the scan to take for Protect. High latency impacts scans due to the fact that our scan engine uses a separate connection for each check that is performed during the Dynamic Product Detection process.

-Is the scan taking place over a LAN connection or WAN connection?

Most often WAN connections will have much higher latency. As such, longer patch scans can be expected over WAN.

Workarounds available for latency/network issues:

-If you have many machines in other areas that the console system would be scanning over a WAN connection it may be best to install a second Protect console on a system that is local to those systems. You can then scan those systems over a LAN connection rather than over a high latency WAN connection to avoid these problems.

-You can install a Protect agent on systems to avoid slow scanning issues caused by network problems. The agent will run the scan locally on the client system so it avoids all network traffic while scanning.

-There is an option to change the number of simultaneous machines scanned during the scan process. To make this change you will need to create a custom patch scan template in Protect. On the 'General' tab under the template you can decrease the number of machines the scan will simultaneously run on. Dragging the bar to a lower number may help improve scan speeds. You will need to use your custom patch scan template to run a scan for this to take effect.

-It's possible it may help you to perform network monitoring during the scan. This would require a 3rd party network monitoring tool which we do not support.

5. Possible Database Issues

You will need SQL Server Management Studio to perform some of these checks. If you are using SQL Express you will most likely need to download the free Management Studio Express from Microsoft's download site. See the links below:
For SQL 2005 Express: http://www.microsoft.com/downloads/details.aspx?FamilyID=c243a5ae-4bd1-4e3d-94b8-5a0f62bf7796&displaylang=en

For SQL 2008 Express: http://www.microsoft.com/downloads/details.aspx?FamilyID=08e52ac2-1d62-45f6-9a4a-4b76a8564a2b&displaylang=en

For SQL 2008R2 Express: http://www.microsoft.com/download/en/details.aspx?id=22985

For SQL 2012 Express (Choose the management studio after clicking download): http://www.microsoft.com/en-us/download/details.aspx?id=29062

-Open Management Studio and connect to your SQL server. Expand 'Databases', and locate your 'Protect' or 'Shavlikscans' database. Right click on the database, and then go to Properties > General tab. Check the Size of your database. If your database is over 4GB in size, it's possible that you may need to perform database cleanup.

-If you are using SQL Express there is a database size limitation built into SQL. Full versions of SQL are only limited by allocated space given by the DBA or space of the hard disk. The size limitations for currently support versions of SQL Express are as follows:
SQL Express 2005: 4GB size limit per database
SQL Express 2008: 4GB size limit per database
SQL Express 2008R2: 10GB size limit per database

-Perform database maintenance. You can now easily do this from within the Protect console under Tools > Database Maintenance. If you are having slow scans take place it may help to delete as many old results as possible as well as perform the option to 'Rebuild Indexes'.-After this it may help to close Protect, go into SQL Management Studio, and perform the following steps: Right click on the Protect database and go to Properties > Options. Set the Recovery model to "Simple". Hit Ok. Then right click on the Protect database again and go to Tasks > Shrink > Database. This will help shrink the size of the database and the log file.

-It can depend if the SQL server being used is remote or local. If the database is hosted on a remote server you may need to check into your network connection between the console system and the SQL server. If there is any latency or any network issues it could cause your scans to run slow.

6. Virtual Machine resource contention:
If you have the console running on a virtual machine make sure that the resources that the VM are trying to use are actually available in case you have other VM's running simultaneously that are possibly using all of the host server resources.