After typing in the word Cloud and running my search, I had 2 engines that had the first result taking you to Wikipedia to talk about Cloud computing. The other search engine still took you to Wikipedia, but it was talking about the visible liquid droplets or frozen crystals suspended in the atmosphere that we all know and love. Which one was that you might ask? Go try it for yourself and see.

The fact one search engine out of those three did not list Cloud computing as result number 1 actually surprises me a little. These days everyone is talking about it and looking at how their organization can potentially benefit from moving certain services, or applications to the cloud. Plus, people don’t get that much revenue for advertising cumulus clouds. I’d say cloud computing services are more likely to be profitable.

With cloud computing though comes one challenge. Especially as a service provider, how much storage do you need if you’re offering these hosted services? Well, obviously it has to be wicked scalable, the cheaper the better, and reliable! Tough combination…cheap, and reliable? Ya, I said it…. I found a blog post the other day from a company called BackBlaze (http://backblaze.com ). They’re just your basic online backup company that provides services to individuals that want to backup their important files and not worry about hard-drive armageddon. Now, don’t confuse BackBlaze with a company like Ubistor (http://ubistor.com) that specializes in online backups but are tailored a lot more specifically to businesses. Same idea, different markets.

Moving forward, BackBlaze realized that to offer this service, they need scalable, cheap, and reliable storage for their customers. Using a little ingenuity, I’d say they were able to meet those requirements.

WARNING: CAPS LOCK EXCITEMENT – 67 TERABYTES for around $8,000!!! Wow. Now, before we all rush out to buy everything on their B.O.M… read the article in its entirety before blowing your paychecks and buying up lottery tickets.

http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/

Problem:
Connecting to a SQL database using Windows Authentication over TCP/IP returns the error “Cannot generate SSPI context” whether it’s the application, or when you’re, setting up a User or System DSN for Microsoft SQL, for example.

Workaround:
If you change the DSN to use Named Pipes instead of TCP/IP on the client configuration area of the setup, the SQL Server connection will succeed.

How to troubleshoot the “Cannot generate SSPI context” error message
http://support.microsoft.com/kb/811889

Security Account Delegation (Using the setspn.exe utility to view/add/delete SPNs)
http://msdn.microsoft.com/en-us/library/aa905162(SQL.80).aspx

Solution:

1. Stop the SQL Server service
2. Downloaded and installed the SetSPN utility found in the Windows Server 2000 Resource Kit Tools. http://www.microsoft.com/downloads/details.aspx?familyid=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en
   1. Installed on Standard Server 2003
3. Run the setspn.exe utility from the resource kit command prompt. You want to use a –l username or –l computername. This will only LIST the current SPNs configured for either account. (You’ll want to use the –l computername if the SQL Server Service is running as LocalSystem OR a regular domain user) If the SQL Server Service is running as an administrative account (Domain Administrators/SQL Administrator) you would want to use the –l username to see the SPNs registered for that account.
   1. Setspn.exe –l clientdomain\Administrator and setspn.exe –l SQLSERVER1
      1. This showed multiple conflicting or non-updated SPN records for the both the user account and the computer account
4. Ran setspn –D MSSQLSvc/SQLSERVER1.clientdomain.local:1433 Administrator (Run as domain admin) to manually delete all SPN records for anything that had to deal with SQLSERVER1.
   1. In this client’s case, SQL had been setup to run as the domain Administrator, so I listed all SPNs for both the Administrator and the SQL Server hostname. Then manually deleted all registered SPNs for both the Administrator account, and the SQL server hostname.
5. For the time being, I also went ahead and changed the SQL services to run as LocalSystem.
6. Since the services are now configured to run as LocalSystem, you want to make sure to mark the computer account of the SQL Server as Trust for Delegation (Kerberos only) on the Delegation Tab of the computer properties in AD.
7. Reboot SQL server – This will ensure when SQL Server starts, it will attempt to register it’s SPN with your DC.
8. At this point I was able to successfully connect to all the database using Windows/Integrated Authentication over TCP/IP