2 minute delay on opening .pit file (from DMZ / SSL gateway)

Hi Michel,

These are the things we tried in the first place with quest support (without luck).

We did some more testing, and it appears to also happen without Quest SSL. We configured the web interface to accept connections on port 80, bypassing Quest SSL, and the timeout randomly happens.

So it seems to be not related to SSL. However, it only happens on connections from 'the outside'. Internal users don't have this problem.

I guess this will be an unsolved mistery..

Thank you for your time, but that's not the problem. The web interface itself loads quickly. You don't need to ping the site or whatever, just follow Rick Mack's suggestion in the second post about '.

It sometimes goes wrong at the moment you click on the virtual desktop.

Take a look at this capture:  http://www.chelloo.com/images/temp/vworkspace.avi

Are you using a self signed certificate?

René,

   From your video,  I noticed that the pit file is being scanned by IE's SmartScreen Filter - http://www.microsoft.com/security/filters/smartscreen.aspx

Just for troubleshooting, try turning it off and/or configure werkplek.schiphol.nl as a trusted stie and see if that makes a difference...

Quick question. I'm just trying to do elimination here and wonder if it's possible to do this:

You have 1 Secure-IT machine, 1 Web-IT machine and rest of the network

1) Try to deploy another machine, even virtual, install Web-IT role on it, quickly configure it similar to your original Web-IT and change Secure-IT web proxy to that machine (don't forget to restart pnsslsvc service on Secure-IT) machine. Will it be similarly slow? I'd even suggest to try 2003/IIS6 combination to host Web-IT.

2) Try to deploy another machine with Secure-IT service on it. Configure it with your SSL cert, point to original Web-IT server. Will it be slow as well?

It's an official certificate.

I almost thought this must be it! But too bad

I disabled smartscreen filter and made sure the site was added to the trusted site (already was). Did a complete restart, but it was still loading for 2 minutes.

Thanks all for your good suggestions. We still haven't solved this.

Because this topic is getting very big, here is a list of our conclusions:

• The timeout only occures with Internet Explorer (all versions / any OS). Never with Firefox!
  
• It happens randomly. If you try to click on the Virtual Machine 10 times in a row, it times-out about 5 or 6 times.
  
• It only happens when connecting from the internet (external users). So when we connect from our internal network to the external webserver, there are no problems. Our network guys say the exact same route is being used, and you pass the same firewalls.
  
• It has nothing to do with certificates or SSL gateway. I tried it directly on port 80, bypassing the SSL gateway, with same results.
  
• SSL/Webserver are installed on same server in DMZ. In DMZ we do not have an active directory.
  
• The brokers are on are internal network, in active directory.
  
• I also tried to proxy the SSL gateway (in DMZ) to an internal webserver, still the same time-out problem!
  
• All servers are Windows 2008 x64 / IIS7
  
• In the eventlog, we get a 'The request is aborted' message (see http://communities.quest.com/message/3068#3068)
  
• For a video of the problem see : http://www.chelloo.com/images/temp/vworkspace.avi
  

That is great news Stephen!

Rene, please let us know if this also solves your problem.

I tried it on Windows 2003. On W2K3 we do not have the .pit timeout, but then we got other problems.

On w2k3 strange things happen with the web-interface like pictures not loading.

So this is not the way we want to go, installing a 7 year old OS. If it would solve all problems then it would be fine, but it introduces new problems.

ps: Stephen says in his situation it is related to the SSL gateway, but in our situation it goes wrong with or without SSL enabled. Even on port 80, we get this timeout.

Only in DMZ...

We are very happy with this solution. It was really an annoying problem and very hard to replicate in another environment.

That's what made this one hard to solve, it only happend on our network.

Anyway, by adjusting one small setting in IIS the problem completely disappeard. That's just amazing!

I want to thank everybody who was involved by solving this problem, thanks for your patience. That includes myself (did you try turning it off and on again ).

That is an awesome find Yorker! Thanks for providing this!