Denali is packed with new features. A lot of features evolve around the engine, BI, Data Quality but there are also new features added to the installation process. In a previous post I already mentioned managed service accounts and in this post I will show how to install SQL Server Denali on Windows 2008 R2 Core Edition. As an added bonus I will be using managed service accounts again but instead of having the domain admin activate the managed service account I will delegate these permissions to Bob, our SQL administrator. I’m using the same setup as in my previous post.
I installed a new Windows Server 2008 R2 Core Edition and set a fixed ip (10.10.10.5/255.255.255.0). The computer was named SQL-02 and added to the domain CONTOSO. Again, Bob was added to the local administrators group using net localgroup Administrators CONTOSO\Bob /ADD.
First we will setup a new group for SQL Admins, add a new managed service account, sql2, and delegate permissions to the SQL Admins group. For Bob to be able to control the managed service account we must add him to the SQL Admins group.
With Windows Server 2008 R2 Core you get a smaller install base; 33 processes running on core vs 41 on full installation, 351MB vs 452MB memory in use after start and 4GB vs 9GB disk space. Of course your mileage may vary but you get the general idea. Not only did I show how easy it is to install SQL Server Denali CTP3 on a Windows Server Core edition but also how you permissions to control managed service accounts can be delegated to other administrators.
Give SQL Server Denali CTP3 a run and remember to provide your feedback. If you’re fast you might win something as well, http://blogs.technet.com/b/dataplatforminsider/archive/2011/08/19/announcing-the-sql-server-code-name-denali-feedback-challenge.aspx.
As we all know we should run our SQL services with the least privileged principle. Most of the times this comes down to running with a domain account that’s not a member of any group. But we also want to use strong authentication mechanisms like Kerberos, so we need a domain administrator to set the proper SPNs for us. And our policies require us to change passwords every 90 days for all accounts, including service accounts. And to finish we don’t want the service account to be able to login in interactively so we set a Deny Local Login through Group Policies.
This seems like a lot of administration and handling just to be secure. And it is! That is, until now.
Windows Server 2008 R2 and Windows 7 introduce two new type of service accounts, managed and virtual. Both accounts eliminate password management by the administrator and managed accounts also eliminate the need for an administrator to manage SPNs. The full story can be found here: http://technet.microsoft.com/en-us/library/dd367859(WS.10).aspx
To demonstrate how this works I will create three machines, a domain controller, a SQL server and a Windows 7 client machine. All servers are running Windows Server 2008 R2 Sp1 and the client is on Windows 7 Sp1.
Installing the Domain Controller
To start off we need a domain controller. I’m using Hyper-V to create a virtual machine and install Windows Server 2008 R2 Core Edition. There is no GUI to create managed service accounts so the core edition will suit us well.
[DCInstall] InstallDNS=Yes DomainNetBiosName=contoso NewDomainDNSName=contoso.com ReplicaOrNewDomain=Domain NewDomain=Forest ForestLevel=4 DomainLevel=4 SafeModeAdminPassword=myverysecretp@ssw0rd! RebootOnCompletion=Yes
To summarize the benefit of managed service accounts:
With the combination of SQL Server Denali and Windows Server 2008 R2 you can leverage the use of managed service accounts to ease your user administration.