My Approach to SharePoint 2010 beta Development
Rich Olivieri, email@example.com
This weekend, I finally got a chance to go to the mattresses and build out my SharePoint 2010 development environment.
I have come away victorious, but it was a bloody fight.
My approach was to create a throw away environment which would last until the initial release of SharePoint 2010 or until the CTP. I used trial 180 day licenses of Windows 2008 R2 and SQL 2008 R2. Once the release version of SharePoint 2010 is available, I will build out VMs using my Action Pack licenses for Windows 2008 R2 and SQL 2008. I downloaded the VHD for Windows 2008 R2 and duplicated it for my two VMs. Note: You can only use the trial versions of Windows Server 2008 R2 and SQL Server 2008 R2 for evaluation and testing purposes only.
I ended up having to run this Sysprep command on the second image, because I had problems (got a System.Security.Principal.IdentityNotMappedException error see ref #5) joining the VM to the domain: c:windowssystem32sysprepsysprep.exe /quiet /generalize /oobe /shutdown
Hyper-V Host Server: 8GB Quad 6600 running Windows 2008 R2 standard (the license I own via the Action Pack).
- 2GB VM1 – Windows 2008 R2 EE running SQL2008 R2 and Active Directory (I am using the trial edition of both the OS and SQL Server which are both good for 180 days. I will either reinstall this after 180 days or move to my final version using my Action Pack licenses)
- 2GB VM2 – Windows 2008 R2 EE running SharePoint 2010 beta (The technical requirements state 4-8GBs for SP 2010, but I found two "official" references that indicate you can get by with 2GB for development. Mine seems to work fine and running well).
Based on my battle experience this past weekend, I recommend the following steps. If I had followed these steps, my weekend would have been a cake walk.
1. Active Directory: Create your Active Directory environment. If you have one then great, use it. Run the wizard (dpromo.exe) and let it install DNS for you. I used a fake domain – dev.sp2010.com and put an entry in my host file on both VMs pointing the IP to the AD/SQL 2008 VM. I also added an entry for DEV pointing to the same IP.
2. SQL Server: Create your SQL 2008 environment and join your SQL 2008 server to the domain. (If you use my approach then it is already on the domain controller and part of the domain. Just make sure that went well.) Install SQL Server on your SQL Server VM or like me on the Active Directory domain controller VM – Yeah, I know that is not recommended for production, but it was in the MSDN article as a suggestion for a dev environment.
3. Default SQL Instance: Create a default instance of SQL Server 2008. Make sure it is set to allow remote connections and TCP network protocol has been enabled. The default instance will use port 1433 as a fixed port. Any other named instance will use dynamic ports – so be easy on yourself and just use the default instance.
4. SQL Service Account: Use a domain managed service account for your SQL Services. Set the trust delegation and add it as a SPN for MSSQLSVC on the default port.
5. SQL and Firewall: Make sure SQL Server and SQL Server Bowser have been added to the inbound rules of your firewall.
6. Do not proceed to installing your SharePoint server until you know your Active Directory and SQL Server environments are working.
7. SharePoint Server VM: Create your SharePoint Server VM and join it to the domain. I had problems here, but solved it by making sure I first join to my home private network and turned on network discovery. Your domain controller must be able to ping and connect to your SharePoint VM. (You might have to run sysprep if you follow my approach of using a duplicate of the same VHD image. This is because the SID will be the same and you will have problems joining them to the same domain. Do this before you spend any time on the SharePoint Server VM).
8. SQL Client Tools: Once your SharePoint Server VM is joined to the domain then logon as a domain admin and install the SQL client and management tools.
9. Verify SQL Connectivity: Verify that you can connect to the default SQL instance on your SQL Server from the SharePoint VM. If you cannot then troubleshoot that before you attempt to install SharePoint 2010.
10. WCF Hotfix – There is a WCF Hotfix needed, but this will not install unless you have put the SharePoint Server VM in application server role.
11. SharePoint Service account: Create a domain managed service account and set it to trust delegation. (Jie Li, SharePoint Technical Product Manager, suggests adding the Replicating Directory Changes delegate control task to the SharePoint service account see ref #1)
12. ADO Data Services 1.5 is needed if you want to use the new REST API (/_vti_bin/listdata.svc) See install link below.
13. Once you have your SharePoint VM connecting to the default SQL instance then while logged on as a domain admin prepare to install SharePoint 2010.
14. Run the PrerequisiteInstallerFiles application or that option from the SharePoint install splash screen.
15. If the PrerequisiteInstaller succeeds then proceed with the installation of SharePoint 2010.
16. Create a new complete farm and run the config wizard afterwards.
17. After the wizard completes, Central Admin comes up and prompts to run a wizard to configure services. Do it! I reused my farm admin account. If you use a new one make sure it is created like the farm account as a managed service account with trust delegation and the replicating delegate changes added as outlined in ref #1
18. The Central Admin wizard will complete the services configuration and will then prompt you to create a top level site.
So now you should have SharePoint 2010 beta development environment created within a working Active Directory domain.
References: These are the various references I collected this weekend to help me in my battle.