Last updated: January 21, 2012
Introduction
The instructions I present here are for installing SharePoint Server 2010 as a single-server farm on a machine running Windows Server 2008 R2 SP1 and acting as a domain controller. This is a fairly common configuration used by a lot of SharePoint devs and will work for both on-premise and online (Office 365) development.
Notes: I don’t cover Windows 7 installations here. If you’re installing SharePoint on Windows 7, Microsoft has a set of instructions you can use. They also came out with an automated installation script that makes the process even easier. I also don’t cover how to make a “reusable” development image that you can clone from again and again. If you’re interested in that, you can combine the steps from a blog post I found on creating a cloneable SharePoint 2010 development environment with the steps I list below.
Requirements and Prerequisites
Whether your dev machine will be virtual or physical, it must meet the minimum hardware requirements outlined here: http://technet.microsoft.com/en-us/library/cc262485.aspx. Don’t worry about the software requirements yet that are mentioned in that article. We’ll get to those later.
Assumptions
These instructions assume you have licensed copies of Windows Server 2008 R2, SQL Server 2008 R2 (Developer, Enterprise, or Datacenter edition), Office 2010 (optional but recommended), and Visual Studio 2010. Most developers will have these through MSDN, Action Pack, or a similar offering. SharePoint Designer 2010 is free and doesn’t require a license.
Installation Instructions
- Install Windows Server 2008 R2 (Enterprise edition preferred). Be sure to install the “full” version and not the “server core” version. (The server core version has no GUI support.)
- Configure the Administrator password to never expire. (Using Server Manager, open the Configuration node. Open Local Users and Groups, and click on Users. Right-click on the Administrator user, and choose “Properties.” Select Password Never Expires.)
- Also, verify the Guest account is disabled (it normally is).
- Change the computer name. (Using Server Manager, click Change System Properties on the main page. Click the Change… button on the “Computer Name” tab.)
- Turn off Windows Firewall (makes things easier and isn’t really needed for a dev machine).
- Note: Windows Firewall has several “profiles.” Be sure to turn it off in all of them.
- Turn off Enhanced Security Configuration for Internet Explorer. (Using Server Manager, click Configure IE ESC on the main page. Select “Off” for Administrators.)
- Disable User Account Control. (Open Control Panel. Click the User Accounts link. Click User Accounts again. Click Change User Account Control Settings. Choose “Never notify,” and click OK.)
- Under “Server Features” (in Server Manager), enable Desktop Experience and Windows PowerShell Integrated Scripting Environment.
- Configure “Disable Loopback Check” in registry (I used Method 2 in this article for doing this, which is fine for a dev machine even though it says “Less Recommended Method”).
- Disable the Shutdown Event Tracker (instructions can be found here).
- (Optional) Disable the ability for Windows to set “Install Updates and Shut Down” as the default option in the shutdown menu. (Open the Group Policy Editor as described in Step H. Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Update. Open the “Do not adjust default option to ‘Install Updates and Shut Down’ in Shut Down Windows dialog box” setting. Select “Enabled,” and click OK.)
- Configure the Administrator password to never expire. (Using Server Manager, open the Configuration node. Open Local Users and Groups, and click on Users. Right-click on the Administrator user, and choose “Properties.” Select Password Never Expires.)
- Configure your machine as a domain controller (makes it much easier to do a single-server farm installation).
- Install the Active Directory Domain Services server role.
- Run “dcpromo.exe” to promote the machine to a domain controller (in my case the wizard for the above-mentioned server role gave me the choice to do this automatically when it finished running).
- Since this is a dev machine, I kept things simple and set up a single domain called “Dev.” But you can call yours “Contoso” or whatever you prefer.
- Create some domain accounts that will be needed when installing SharePoint and SQL Server. While it might be temping to just do everything under one account (probably the Administrator account if you’re like most people), I recommend against it. It’s better practice to get in the habit of using multiple accounts like you’d do in a production environment. I used to provide a list of accounts here, but now I’ll refer you to this list I found on another blog. I didn’t see any reason to duplicate that list again here. (Note: On the list I linked to, there are two sets of search accounts: one set for SharePoint Foundation and one for SharePoint Server. You do not need both sets. Only create one set of search accounts based on the edition of SharePoint you have. Also, the account he called “Search Access” I usually refer to as a “Search Crawl” account. It’s personal preference, but I like the latter because it’s more commonly used among the SharePoint community. Lastly, you only need the Excel Services account if you’re using that service.)
- Tip: Since this is just a dev environment, your life will be a lot easier if you use the same password for all your accounts. If you want to use a unique one for every account (as in production) you certainly can, but you don’t really need to. The point of using multiple accounts here isn’t really security – it’s just to build good habits that follow best practices.
- Install SQL Server 2008 R2. The Enterprise edition is recommended, but the Developer and Datacenter editions will do fine as well. (Note: If you go with SQL Server 2008 rather than 2008 R2, you’ll also need to install SP1 and SP2 CU2 for SQL Server 2008.)
- Under Instance Features, I installed Database Engine Services (both), Analysis Services, and Reporting Services.
- Under Shared Features, I installed Business Intelligence Development Studio, Management Tools (Basic and Complete), and the Microsoft Sync Framework.
- On the screen asking which accounts to run services under, I chose the option for running all services under the same account and gave it the name of my SQL Server service account (see Step 3).
- Install the WCF Hotfix for Windows Server 2008 R2 (Note: May no longer be needed due to software updates, but I kept it in here for the sake of completeness. If you don’t need it, you’ll get a message during installation letting you know it’s not needed.)
- Install ADO.NET Data Services for .NET Framework 3.5 SP1 (for Windows Server 2008 R2). (Same note as Step 5… may no longer be needed)
- Run SharePoint’s PrerequisiteInstaller.exe (included with SharePoint 2010 in the same folder as Setup.exe). Remember the software requirements I mentioned in the Requirements and Assumptions section above? That’s what this tools installs. (It also configures IIS and does a few other things.) NOTE: The prerequisite installer will not tell you to reboot when it’s done, but you need to reboot anyway to complete the configuration changes it made.
- Now it’s time to run Setup.exe for SharePoint. HOWEVER, there’s a caveat here. Because our machine is a domain controller, Setup.exe will assume we want SharePoint installed in standalone mode and will never give us the screen where we can choose to install as a single-server farm. To get around this, you need to open a command prompt window, navigate to the directory where Setup.exe resides, and issue the following command:
setup.exe /config Files\SetupFarm\Config.xml
- On the “Specify Configuration Database Settings” screen of the setup wizard, enter the name of your server as the database server. I kept the default database name that was provided (because I don’t really care on a dev machine), but you’re welcome to change it if you wish. For the database access account, enter the name of your SP Farm Account and the password. Notes: During the installation process you’ll be asked for a “passphrase” for your farm. In my dev environment I usually just use the same password I used for all my accounts (see Step 3A), but feel free to use a new one if you wish (as you would in production). You’ll also be asked whether you want to use NTLM or Kerberos authentication. Unless you’ve got a compelling reason to use Kerberos in your dev environment, I recommend NTLM. It requires less configuration.
- Optionally, you can run the SharePoint Configuration Wizard after the installation wizard completes. I generally recommend against this wizard because it doesn’t do a great job configuring things. In my case I’ve automated the configuration of my farms with PowerShell to create the service applications, web applications, and site collections I generally need. However, you can create them manually through Central Administration as well. Even that approach is better than using the wizard.
- Install Microsoft Office 2010 (recommended by not required). Not much to talk about here. Compared to SharePoint, installing Office should be a piece of cake.
- Install SharePoint Designer 2010.
- Optionally, install Microsoft Office Visio 2010 (if you want it and have a license for it).
- Install Visual Studio 2010 (I installed the Pro version because that’s what comes with my Action Pack subscription). Note: When installing Visual Studio, select “Custom” installation and uncheck “Microsoft SQL Server 2008 Express Service.” Otherwise you might get an error at the end of the installation process about that component not installing correctly.
That’s basically it. Now you should have a fully functional SharePoint 2010 development machine up and running.
Disclaimer: The usual warnings apply about not setting up a production environment in exactly the same manner. If you need help with that side of things, contact me and we’ll talk.