Error: "Server Busy" When Running a Vulnerability Scan

Issue

The error "Server Busy... retrying" or "Server Busy... Failed." appears when running a vulnerability scan.

The Vulscan.log (Located in C:\Documents and Settings\All Users\Application Data\Vulscan) may contain lines similar to the following:

Thu, 03 Dec 2009 16:45:57 Action SOAPAction: "http://tempuri.org/ResolveDeviceID" failed, socket error: 0, SOAPCLIENT_ERROR: 5.  Status code: 503, fault string:  616   Retrying in 9 seconds...

Resolutions

There can be various causes for this issue.  It mainly centers around connectivity from the core to the client to the proper web services and web pages.

Core Server Reboot

Often rebooting the core server will clear up an issue like this.  This should be attempted before changes are made.

Database credentials are incorrect or core cannot contact the database

1. Ensure that the Core server is pointed to the right database.
2. Ensure that the proper credentials are configured on the core in Configure Services | General Tab | Database
3. Ensure general connectivity to the database.   Ensure the database is up and running.  Perhaps rebooting the database and/or core server could be a solution.

The identity of the application pool does not have the Replace a process level token user right.

This cause usually results in an HTTP 403.19 error. If you are seeing this error in the IIS logs please review this Microsoft KB Article.

http://support.microsoft.com/kb/942048

Incorrect alternate Core Server name specified in Scan and Repair settings

Verify what Scan and Repair Settings the client is using.

Open that Scan and Repair setting and check the server name under "Communicate with alternate core server" on the Network Settings tab.

The web services log file on the core server can be useful for troubleshooting:

Run a vulnerability scan and then check the following log on your core server:

c:\windows\system32\logfiles\w3svc1\(latest log file)

Within this log file there will be lines similar to the following:

2009-12-03 23:48:59 W3SVC1 192.168.0.69 POST /WSVulnerabilityCore/VulCore.asmx - 80 - 192.168.0.45 Microsoft-ATL-Native/8.00 200 0 0

If the HTTP result code (A red "200" in the example above) is in the 400's or the 500's, this can indicate a server-side error.

An internet search of "HTTP ERROR CODES" can aid in diagnosis.

It is also important that the Core Server was not renamed after IIS installation.  Verify that the IUSR_<coreservername> and IUSR_<coreservername> accounts truly match the current name of the core server.  (Check account names in IIS Manager or Computer Management vs. what is returned by running "hostname" in a command prompt" window.

IIS Configuration and/or Permissions Issue

At this stage in the Vulnerability Scan process, the Vulnerability Scanner attempts to contact the core at http://<coreservername>/WSVulnerabilityCore/VulCore.asmx.

A basic connectivity test can be done:

1. In Internet Explorer go to Tools --> Internet Options --> Advanced and uncheck the box next to "Show friendly HTTP error messages."

2. Browse from Internet Explorer on the client to http://<coreservername>/WSVulnerabilityCore/VulCore.asmx.

Take note of any error that appears.  If the page returns normally, it should look something like this:

If this fails, directory and virtual directory missions should be verified within IIS (Internet Services Manager) on the core server.

For information on the proper permissions that should be applied to directories, see this article.

Additionally, the .NET Framework may need to be re-registered and IIS reset as pictured below (Note: The directory for the .NET Framework version may vary)

Modifying the Identity used by the WSVulnerability Application Pool

At times there have been Group Policy changes that have restricted the rights to the "Network Service" that the Application Pool normally uses.  Changing this Identity to use "Local System" has at times resolved this issue.

1 - In the IIS manager, if you have not already create a new application pool then add the wsvulnerability web service to it. If you already have the pool then skip this step 1.
2 - On the application pool for WSVulnerability right-click and select properties.
3 - On the properties window select the Identity tab.
4 - Change the Predefined to "Local System"
5 - Open a Command Prompt and run "IISRESET"

Additional information regarding the Optimization of IIS can be found here.

Description

When running a Security Scan on the clients, vulscan returns the above error and the window closes. This happens on every device. The vulscan.log file reads: "Action SOAPAction: "http://tempuri.org/GetHashForFile" failed, socket error: 0, SOAPCLIENT_ERROR: 7. Status code: 500, fault string:"

ASP.NET and CBA_anonymous accounts

On the core server, make sure that the local accounts ASP.NET and cba_anonymous are created and enabled.

GPO Policies on Core Server

• Go to Start | Administrative Tools | Local Security Policy.
• Expand Local Policies.
• Highlight User Rights Assignment

Make sure that the Adjust memory quotas for a process value provides permissions for these accounts:

• Local Service
• Network Service
• IUSR
• Administrators

Note: These are the default accounts. The Application pool is running as Network Service and requires this ability.
Note: To test if this is the cause, set the identity of the Application Pool to be Local System. If this works, then permissions is definitely the cause.
Note: It may be necessary to put the Core Server in its on OU and have absolutely no GPOs applied to the OU, not even the default policy.

IP Address or Domain Name Restrictions in IIS

1. Using the Internet Service Manager (Microsoft Management Console), open the Internet Information Server (IIS) snap-in and select the Web site reporting the 403.6 error. Right-click the Web site, virtual directory, or file where the error is occurring. Click Properties to display the property sheet for that item.
2. Select the appropriate Directory Security or File Security property page. Under IP Address and Domain Name Restrictions, click Edit.
3. In the IP Address and Domain Name Restrictions dialog box, if the Denied Access option is selected, then add the IP address, network ID, or domain of the computer that requires access to the exceptions list.
4. In the IP Address and Domain Name Restrictions dialog box, if the Granted Access option is selected, then remove the IP address, network ID, or domain of the computer that requires access to the exceptions list.

Ensure that the proper Web Service Extensions are enabled

On the Core Server in IIS ensure that the following Web Service Extensions are enabled:

The identity of the application pool does not have the Replace a process level token user right.

This cause usually results in an HTTP 403.19 error. If you are seeing this error in the IIS logs please review this Microsoft KB Article.

http://support.microsoft.com/kb/942048

Patchbiz.dll versions not in sync with other patch manager related files

Install the latest Service Pack for your version of the Product

Client access certificate not approved - LDMS 2016 Enhanced Security Mode