RE: Winsock 40006 error
- From: "John Tolmachoff \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
- To: "'[ISAserver.org Discussion List]'" <isalist@xxxxxxxxxxxxx>
- Date: Mon, 19 Sep 2005 15:36:35 -0700
Final update and issue is resolved.
Recap of problem: An in-house designed application has a new feature. That
feature formulated and sent an xml request using HTTP to a 3rd party server
on the Internet for live data. That data was then imported into the in-house
application for use by the sales people. The feature would error as soon as
the xml request was sent.
Issue 1: Application needed the use of the Firewall client. The firewall
client was not installed as during testing there were problems encountered
with an application the client was using before. That application was a 16
bit DOS application. That application is no longer in use, and the Firewall
client can now be freely used.
Issue 2: HTTP Redirector was enabled. The app would only work if the HTTP
Redirector was disabled. Why was it enabled? Before migrating the
workstations to XP Pro last November, they were running NT 4.0. There was an
application they were using (An earlier version of PaperPort) that would not
work properly unless the user had admin rights. Therefore, all the users had
admin rights on their workstation. As such, they could (and did) make any
change to their computer they wanted, including changing IE settings. (When
I came on the seen there, 2 users were even using Gator, ouch.) Through
testing, it was determined that the only way to force users through the
proxy was to enable the HTTP Redirector. The proxy service was then able to
both filter and apply rules. Since they are now on XP Pro, and users only
have local user rights, they can not change settings in IE (Forced through
GPO) nor have access to the control panel or any settings. (Again, through
GPO.) Therefore, the HTTP Redirector can remain disabled now.
Issue 3: Most users were able to access sites on the Internet that should
have been filtered. On Saturday, 09/10, GFI DownloadSecurity was uninstalled
from the server, and the new GFI WebMonitor was installed. As a result, the
order in which the web filters were applied changed. As a result, GFI
WebMonitor was scanning and passing and Burstek was not scanning at all.
Turns out this is a known issue by Burstek that if any GFI product is higher
priority that Burstek, this will happen. I put Burstek web filter as a
higher priority (number 1, GFI is now number 2, and the ISA URL converter
{not used} is number 3) and both are scanning and working as intended.
Issue 4. Some users were able to access sites that should have been blocked
by Burstek. Reading the Burstek logs showed they were properly categorized.
Called Burstek support. On Saturday, 09/10, I had also upgraded both the
Burstek WebFilter and LogAnalyzer. I did have problems with the WebFilter
install. Turns out some registry settings were amiss and not all policies
were being enforced. When I tried to Uninstall and reinstall both, CPU went
to 100%. After 10 minutes, I forced quit the services and uninstalled. What
then was happening is I was using a backup settings file from Friday
afternoon. Between Friday afternoon and Thursday when I was on the phone
with Burstek, 6 reports should have run. Well, Burstek LogAnalyzer saw that
and was running them, all at once. I let them run out, and after about an
hour it finished. I did a lot of testing after that and Burstek was back to
running as expected.
Moral of the story: Document Document Document
If had I documented what was in use or not in use on the firewall and why,
instead of having to dig through 3 years of notes, I would have solved this
a lot sooner.
Thanks to Erik Naumann and Abhishek Bajpai of Microsoft and the Honorable
Jim Harrison for their assistance in this problem
John T
eServices For You
Other related posts:
