Most admins like to build out a fresh box when upgrading a major application like SQL Server (I do too) and based on what we’ve seen, this is a popular approach. Sure, in-place upgrades are fully supported and they are generally easier to work with since your environment and system objects are upgraded automatically. However, if your server has been running for many years, it may have accumulated more unwanted bits than you’d like or know about. That’s why fresh installs are popular and that means you’ll be upgrading SQL Server side-by-side (aka. migrate).

We will cover this subject in detail over the next weeks but one thing I’d like to share real quick is the Service Accounts used for SQL Server services. First off, “Local System” is no longer permitted. During setup, you will not be allowed to select “Local System” for your SQL Server services. This is a positive move towards a secure by default and in deployment though many users will probably have to modify their automated setup scripts for 2008 (c’mon, admit it; you use local system cos it’s convenient). Local Service and Network Service are still permitted but as mentioned in numerous best practice documents, you really should create a specific local machine account for the SQL Server service or a domain account if it needs to communicate with other servers across the network.

 Now, you can still force the use of whatever account you want (at least as of current CTP build) after installation is complete by changing the properties using the Configuration Manager (I hope nobody still uses services.msc) but that’s probably not a good idea even in dev/test environments. Remember, security is not about production servers only. Many dev/test databases use copies of production data for testing which is a good thing as it provides a “real-world” sample but that also means your dev/test databases are now storing sensitive data that may be subject to the same security rules & regulations as your production server.

 For more information about Windows service accounts and recommended practices, check out http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.mspx

joe yong.