I'm trying to troubleshoot a strange issue. Here are some specifics...
+ just set up a brand new 64bit server (Windows 2003 R2 64 bit O/S and SQL 2005 64 bit, Std Edition); SQL is the only thing running on this server.
+ installed this new server in our AD domain; set up custom domain-level accounts for the SQL Service, Agent, and Integrations Services service accounts, following the BOL help topics "Setting up Windows Service Accounts."
+ I use RDP (remote desktop) to connect to the SQL Server server machine just fine. Once I'm RDP'd into the SQL2005 box, I fire up SQL Mgmt Studio there... it takes well over a couple of minutes before it even finishes rendering the first screen to connect to any instances. Once it finally does come up, I can connect to the (local) db using Windows Auth or the sa account w/out any delay or issue.
+ on my own workstation (an XP Pro laptop), I can open up SQL Mgmt Studio, and it opens up quickly (well, as quickly as Mgmt Studio or Visual Studio probably can these days ... <g>) and also connect to that new SQL2005 box w/out issue.
I am completely baffled as to why it SQL Mgmt studio would take so long to open up on the very server SQL is running, much less a brand new 64 bit server! Any information on what it's trying to do might be helpful... It's almost like it's trying to authenticate or connect to something and timing out, although no errors are displayed and there's nothing in the event logs. It's odd to me though, as at that point (just opening up the application), it doesn't seem like it should be attempting anything like that.
-- Margo Noreen
One issue that can cause this problem is that if the server does not have access to the internet, then the .NET framework can't access the crl.microsoft.com website to verify that the digital signatures used to sign the binaries for managed applications are valid. Each certificate check has a 15 second timeout in the .NET runtime implementation. Depending on what features are installed, this can add up to a minute of start up time for Management Studio.
There are a couple workarounds:
1) Configure a proxy server to allow access to http://crl.microsoft.com from your server
2) Configure your firewall to return a failure status quickly when it blocks access to the http://crl.microsoft.com website
3) Disable checks for certificate revocation. You can do this using Internet Explorer by opening the Interet Options dialog, going to the Advanced Page, and then unchecking the "Check for publisher's certificate revocation" checkbox. There are fraudulently signed binaries in the wild that can make virus-infected applications look like they were published by Microsoft. Disabling this check should probably not be done on machines with internet access.
Hope this helps,
Steve
