- Issue
- Resolutions
- The identity of the application pool does not have the Replace a process level tokenuser right.
- Incorrect alternate Core Server name specified in Scan and Repair settings
- Core Server Reboot
- IIS Configuration and/or Permissions Issue
- Modifying the Identity used by the WSVulnerability Application Pool
- Database credentials are incorrect
- GPO Policies on Core Server
- IP Address or Domain Name Restrictions in IIS
- Ensure that the proper Web Service Extensions are enabled
- Patchbiz.dll versions not in sync with other patch manager related files
- Issue
- Resolutions
- The identity of the application pool does not have the Replace a process level tokenuser right.
- Incorrect alternate Core Server name specified in Scan and Repair settings
- Core Server Reboot
- IIS Configuration and/or Permissions Issue
- Modifying the Identity used by the WSVulnerability Application Pool
- Database credentials are incorrect
- GPO Policies on Core Server
- IP Address or Domain Name Restrictions in IIS
- Ensure that the proper Web Service Extensions are enabled
- Patchbiz.dll versions not in sync with other patch manager related files
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
- Issue Resolutions The identity of the application pool does not have the Replace a process level tokenuser right. Incorrect alternate Core Server name specified in Scan and Repair settings Core Server Reboot IIS Configuration and/or Permissions Issue Modifying the Identity used by the WSVulnerability Application Pool ASP.NET and CBA_anonymous accounts Database credentials are incorrect GPO Policies on Core Server IP Address or Domain Name Restrictions in IIS Ensure that the proper Web Service Extensions are enabled Patchbiz.dll versions not in sync with other patch manager related files
- Issue
- Resolutions
- The identity of the application pool does not have the Replace a process level tokenuser right.
- Incorrect alternate Core Server name specified in Scan and Repair settings
- Core Server Reboot
- IIS Configuration and/or Permissions Issue
- Modifying the Identity used by the WSVulnerability Application Pool
- Database credentials are incorrect
- GPO Policies on Core Server
- IP Address or Domain Name Restrictions in IIS
- Ensure that the proper Web Service Extensions are enabled
- Patchbiz.dll versions not in sync with other patch manager related files
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.
The identity of the application pool does not have the Replace a process level tokenuser 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.
Core Server Reboot
Often rebooting the core server will clear up an issue like this. This should be attempted before changes are made.
IIS Configuration and/or Permissions Issue
At this stage in the Vulnerability Scan process, the Vulnerability Scanner attemps 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 Framwork may need to be re-registered and IIS reset as pictured below (Note: The directory for the .NET Framework version may vary)
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.
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.
Database credentials are incorrect
- Ensure that the Core server is pointed to the right database.
- Ensure that the proper credentials are configured on the core in Configure Services | General Tab | Database
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
- IWAM_SERVERNAME
- 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
- 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.
- Select the appropriate Directory Security or File Security property page. Under IP Address and Domain Name Restrictions, click Edit.
- 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.
- 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:
Patchbiz.dll versions not in sync with other patch manager related files
Install the latest Service Pack for your version of the Product