I felt the need to post this after going round and round with this issue. By the way thank you CA/Broadcom Technical Support for all the help. You guys are great. We had a service running nightly, Microsoft's Software Protection Service (SPS), which would cause virtual services to stop and eventually create a non-responding VSE condition. I re-scheduled this service to only run once weekly while the VSE's are stopped. This resolves the issues. Another partial solution to the non-responding VSEs is to make sure you do not have a blank base path. Although this does not totally fix the issues it does minimize the effects of the SPS. Here is one of the interesting things that SPS does: It sends requests to all our virtual services in an attempt to drill down and find vulnerabilities. When it gets a response from the virtual service it then reformats another request and repeats the process. This goes on for ~13 transactions and creates errors in our virtual services and log files. By the way I endorsed having a blank base path because we can essentially enable a "help" command by having the blank base path. This is done by changing the response in the "Service Image" section of the vsi and encoding a message in the <faultstring> with help information like a url to a spreadsheet containing valid requests.