The issues caused by installing SP1 for SQL Server 2005 have been addressed and Microsoft is releasing a hotfix this week. The hotfix will correct the timeout errors received when trying to connect to SSIS as well as some other minor issues that surfaced with the service pack. Microsoft is doing some testing and hopes to have the hotfix released by the end of the week, but if testing goes really well, it could b The issues caused by installing SP1 for SQL Server 2005 have been addressed and Microsoft is releasing a hotfix this week. The hotfix will correct the timeout errors received when trying to connect to SSIS as well as some other minor issues that surfaced with the service pack. Microsoft is doing some testing and hopes to have the hotfix released by the end of the week, but if testing goes really well, it could be sooner. It’s important to understand what caused the issue so you can decide how important this hotfix is to you. The issue was simple. When the SSIS team compiled their fixes to be added to SP1, they issued a new certificate for the file that changed. By issuing this new certificate it put the new version out of synch, certificate-wise, with the old file, so there are now two certificates to validate when the .Net framework connects to the Certificate Revocation List. So the simple explanation is that having to validate two certificates exceeded the timeout limit for the connection, therefore causing a timeout when trying to connect to the SSIS server. There’s another situation that could cause this issue: The situation where the server is configured for certificate revocation checking and it doesn’t have internet connectivity. The internet connectivity could be blocked by a firewall, permissions, or just plain network issues. This is why the workarounds I posted last week work. They revolve around either fixing connectivity issues, or disabling certificate revocation checking. There’s another workaround I got from Microsoft. Configure your firewall to return errors. If the firewall drops packets when they cannot reach their target, then the certificate checking does not return a failure – it just hangs about waiting, and eventually the service control manager says “this is taking too long” and times out. However, if the firewall returns an error, then the service control manager knows that the Certificate Revocation List could not be reached, and can continue. Checking for a revoked certificate is something the .Net framework does – the Service control manager knows that sometimes this can fail, so it continues even when a failure is returned – but it it needs an error message, not a timeout. But these are only workarounds, so unless you can’t install the hotfix for a specific reason, I suggest you install it as soon as you can if you’ve already installed SP1. And I can’t stress enough that the workarounds are just that. It’s really best to install the hotfix if you can.The fix was fairly simple on Microsoft’s part though. All they had to do was re-issue the new certificate for the file that is missing it. Just to be on the safe side, they also increased the timeout for the connection to the Certificate Revocation List.And since most organizations keep a centralized network location for these types of installs, I suggest you slipstream this hotfix into your network copy of SP1, and if you have SQL Server 2005 itself being installed from a centralized location, you might think about slipstreaming both SP1 and the hotfix into the database install… just to prevent any mishaps. The KB article fully explaining the hotfix can be found here. So, with this hotfix, I see now reason why you can’t resume testing with an honest intent to push this into production.I’ll let you know when it actually gets released. Read my book reviews at: https://www.ITBookworm.com Databases