We had an issue with a customer whereby his installation of SAP’s Desktop Intelligence product was timing out when running large queries after an upgrade to IE8 showing an error – SQL Execution (DA0003) CS, Job already in use. It’s a thick-client product but under the hood uses HTTP to communicate with the server estate.
We found a Registry fix:
The Registry fix increases the timeout that the WinInet library (which is responsible for HTTP comms) has to receive any content from a website. Under IE6 the timeout is 60 minutes, under IE7 and IE8 a new version of the library is introduced which times out at 30 seconds. According to the Microsoft KB article Internet Explorer itself should be unaffected, it’s only applications that use the WinInet library.
On IE6-XP SP3 the version of WinInet is 6.0.2900.6148 and after IE8 upgrade its 8.0.6001.18702
Outlook 2010 on Windows 7 hung so I killed it off with the close all open windows option in Windows Explorer. After that I got the above error message stating that it couldn’t configure my email with a reference to my .ost file.
I didn’t want to reboot or log-off so I was looking for a solution that I could use within these constraints as a standard user. I found a blog entry that advises exiting Microsoft Lync before trying to start Outlook, suddenly it all started working again!
My current client has a pair of load balanced windows 2003 servers running IIS hosting 30+ sites each configured with its own app pool. They only serve pages to approximately 85,000 internal users but we got reports of occasional slow page load times. On investigation the worker pool associated with one website was consuming lots of CPU. With a 30 second sampling average we could see peaks of 75% at busy periods of the day with a CPU queue of up to 8. Using perfmon with a much more granular sampling period we could see the reality that the CPU was regularly spiking to 100% over the same 30 second period the enterprise monitoring tools were showing. We discounted caching issues after looking at the IIS perf on counters, and a hardware upgrade was out of the question as we already had the best CPU model the server could take. We looked at scaling out by re-purposing hardware in the same environment bit this would have cost and taken a relatively long time. One of the guys knew that some of the content was ASP pages and some of them used COM components, the theory being it was this that was causing the issue i.e. maybe the components weren’t being correctly released. Looking at the pages we could see that the MSXML component was being used on public pages to apply XSLT transform on XML encapsulated data (e.g. telephone lists). While MSXML 6 was present the registry configuration for the component was incorrect – only v3 was used. By default this is the Microsoft configuration, the latest COM version is set to 3 rather than 6. However, using procmon on the spiking threads in the worker process consistently showed that COM interop and marshalling at the top of the stack. The content authors were asked to not use the COM component, so they changed to using client browser side mechanisms instead. Once deployed cpu dropped to about 15% at peak.
I’ve just installed Squid 2.7 /Stable 8 release for Windows (from http://www.acmeconsulting.it/SquidNT.html) on a Windows 2008 R1 server used the instructions supplied by acmeconsulting. This was on a non-Internet connected server in the labs at work and was part of an internal domain which also hosted it’s own DNS. After running the command lines to install the Squid binary as a Windows Service and create the Cache folders I went into the Windows Services Applet and tried to start it.
No joy, I got a Failed to start service error code 1037 from the Windows Service Control Manager. In the Squid logfile I got the message “FATAL: ipcache_init: DNS name lookup tests failed”. The Squid FAQ notes that on startup the service automatically tries to resolve some DNS addresses. This of course fails as the internal DNS has no knowledge of the external websites, the recommended -D command-line option to disables this wasn’t being persisted by the Service Properties dialog so I had to change the Squid.conf file to alter the sites that were checked to ones that were known by my internal DNS server:
dns_testnames www.org1.org2.uk (names change to protect the innocent)
My wife’s iPad mail app is configured to use hotmail. We recently changed the password using hotmail’s web interface . On starting the iPad mail app a prompt for password kept popping up to the extent that the user interface wasn’t usable. The only way to stop the prompting was to reboot the iPad and go into mail settings to change the password without starting the mail app.
The issue reported by the client was that for a particular website on the Internet they were unable to open PDF’s directly in IE8, they were only offered the option to save them to the local machine. Under IE6 all had worked ok – on clicking the PDF link they were offered Open | Save | Canel buttons, on IE8 they only had the Save | Cancel buttons.
This came down to the improved security model of IE8 and the new HTTP Header directives it now supports. Have a look at “MIME-Handling: Force Save” in this blog post. To prove it I used Fiddler script to block that specific HTTP Response Header to see if I could get back to how IE6 works. Once the Header was blocked from the HTTP Response the Open button appeared in the Dialog box.
Putting the site into IE8 Trusted Zones didn’t alter the behaviour and a search of the Group Policy settings available for IE8 didn’t show up anything around download-options or HTTP Headers.
The root Cause of the why the HTTP Header is being sent by the website is down to the software used by the specific website, they are hosting their content on SharePoint2010, by default this sets the noopen HTTP Header Response as a security feature. It can be turned off using the Central Admin console which this post refers to.
The wifi fix didn’t last long as a solution. On the next heavy rainfall the central locking system wouldn’t unlock the doors when using the remote fob. Luckily it appears to now be fixed, well it’s been working fine for the past 5 months.
Given that it appeared to be a signal degradation problem I open the fob and used electrical tape to strap the 2 batteries together and to the contact. This appears to have cured the problem. My reasoning is based on the supposition that only a single battery of the two was being used and consequently more susceptible to interference. Strapping them ensures more signal strength from the fob and less signal inference from wifi or environment issues such as rain.