I feel like my blogging schedule hasn’t worked itself out yet. I was intending to post 2-3 times a week, and I am lucky to be writing twice a month. Pathetic. And I call myself a writer. I do enjoy the writing part of this adventure, but I am still struggling to figure out what is a hot topic and warrants discussion. So today, I will touch on my activities of the last 3 days – building a new virtual machine with SharePoint 2010. I started over three times. Thank god the last time worked or I may have just thrown the laptop out of the window! So here are my personal notes and best practices using Hyper-V on WindowsServer 2008R2.
- Start by creating the Virtual Hard Drive (vhd) from scratch. Do not try and reuse someone elses vhd as a baseline, you will suffer more time adapting than is worth it.
- Create the vhd and use the option to create OS from *.iso file. Make sure you have the license key handy – and you will probably have to key it in, no pasting.
- If the vm doesn’t have internet access, you can choose to activate the OS using the automated phone system. It takes about 10 minutes, but not too bad.
- Set up the OS with a good baseline configuration. Add Roles and Features that are typical for your environment – IIS, Application Server, etc. Set up standard service accounts and groups.
- Make a baseline copy of the vhd now. Note that this is before the server is joined to a domain. If you have to start over with a clean registry, this copy will be useful.
- Now, before installing any servers, join the server to the domain network. You will need to set up an internal network and be able to ping your domain controller. Refer to the Hyper-v documentation.
- Document your internal network details in the vhd description on the settings page.
- One your server is joined to the domain successfully, make a new backup copy of the vhd. Label this one with post-domain info.
- Now install SQL Server 2008R2 Enterprise (or Developer). You will need two instances – the default instance with absolutely every feature installed, and a named instance (SP2010) for all the SharePoint databases.
- MSSQLSERVER instance should be setup with default settings and Built-in accounts. The SP2010 instance should only have DB Engine and Reporting Services, and should be setup using the service accounts(Domain Service Accounts).
- Once SQL is installed, don’t forget to check the configuration and turn on TCP and Named Pipes channels for service communications.
- Once SQL Server is setup and checks out, make another baseline copy, label this one with post-SQL information.
- Now time to install SharePoint, but first – – – – really, you thought it would be that straightforward? This is a Microsoft product after all! You need to install the Pre-Requisites first!!
- If your VM doesn’t have Internet access, you need to download the pre-requisites and create an ISO image that you can mount and use inside the VM. You will also probably need one or two other KB patches depending on your config.
- Now, you can launch the Installer. Use your pre-defined domain service accounts for the Farm Account and SQL Access Account.
- If you want to be able to scale up and scale out for development and testing purposes, then choose a Farm Installation (Not Standalone).
- Once the SharePoint Installer finishes, you need to run thru the Configuration Wizard. If it fails on any step, note the step number and the error message and google it. There have been a lot of errors and blog articles written to help us muddle through.
- And finally, the Central Administration will appear. Success! Shut it down and make your final baseline copy, labelled with post-SharePoint information.
Thank you to Joel Cade for showing me the utility of this creation method.
Tricia Wilcox Almas 
Great post. I had a couple of questions/additions:
1) Why run the seperate instance of SQL for SP2010? What are the gains?
2) Around Step 12, prior to installing anything SharePoint specific, I’d define and create my service accounts. 2010 has SO many services, already having your service accounts set up and defined by role/permission is a lifesaver, especially when you spend some time troubleshooting:) Here’s a link.
SQL Instances – 1). There are several reasons I like have two SQL Instances for SharePoint. I like to set up the default instance with everything in it, and configured with default accounts. This gives you a lot of options for ancillary databases, supporting information, and a target for any databases created based on SharePoint content (remember, I love Data Sync Studio!).
The SharePoint specific SQL instance is only for SharePoint Specific databases, and can be configured with the SharePoint service accounts as SQL service accounts – and that makes connectivity and tracing much easier. You don’t need a lot of user accounts in this instance, because they shouldn’t be hitting the SP dbs directly anyway – so you can really lock down the dbcreator role.
Additionally, putting all the SharePoint Databases in one instance isolates them, allowing you to manage as a group, and keep track of what has been created. As you know, SP2007 didn’t have that many database, but SP2010 – wow! Also, all the maintenance and other SQL Agent jobs for that instance will be specific to the dbs in that instance, making maintenance and backup/restore more streamlined. Okay, I could wax on, but you probably get the point.
2) Exactly my point – thanks so much for the link!
I really like the idea of two instances of SQL Server – that makes a lot of sense. I think I’ll go back and do that in my build.