Building a SharePoint 2007/2010 development environment – Part V: Guest Build

In the first four parts of this series I covered the project objectives and the system design, then turned my attention to the Hyper-V host image build and automated deployment. In this post I describe a SharePoint 2007 virtual machine build.

Where’s the SharePoint 2010 build?

In short, we’re working on it. I’ve produced a new SharePoint 2010 beta virtual machine for this environment but we’re not yet ready to publish build guidance. Stay tuned. Additionally…

SharePoint 2010 memory requirements

We have validated this environment for use with SharePoint 2010 virtual machines, but performance will be inadequate for development unless 4GB RAM can be dedicated to the SharePoint 2010 VM. It will run with 2GB but it will be too slow to do anything beyond lightweight demonstration. Also, be sure to check if your system has a NUMA CPU architecture. If it does, only allocate memory within NUMA node boundaries, as performance degrades when accessing memory from alocal nodes. See the performance and capacity requirements for virtualising SharePoint guidance for an introduction to the issue, but be aware  that NUMA architecture is less common in laptops so it may not be an issue.

Virtual networking recap

As explained in part two of this series, we have created  three virtual networks on the Hyper-V host, although this development virtual machine will only have two network adapters. The first will be “plugged in” to the Hyper-V ICS Network. The second is “plugged in” to the Hyper-V Internal Network. We plug the Hyper-V External Network in for testing purposes only. For more information about how I’ve designed these networks please refer to the design post.

Working with virtual networks

The guest virtual machine’s “ICS Network connection” will receive the host’s LAN or VPN connectivity (and an IP address via DHCP) from the host’s adapter on the Hyper-V ICS Network. The second adapter is “always on”, in that communication between the host and the guest will be completely separated from the host’s provision of ICS to the guest. This second adapter has a fixed IP address on a network that’s dedicated to providing communication between guest VMs and a resilient, permanent connection in the host. This enables:

  • Persistent network sharing.
  • RDP connections to guest VMs.
  • HOSTS file entries and BackConnectionHostNames security.
  • Multiple IP addresses on static adapters in guests, for multiple sites with SSL, etc.

Static IP address allocation on the ICS connection in the guest is not a supported configuration and results in instability.

System Build

Installation

Create a new virtual machine in the location of your choice. After the virtual machine has been created, modify these settings:

  • Assign multiple processors to the virtual machine (for most laptops you will want to assign all of them).
  • Assign sufficient RAM, leaving at least 2GB RAM for the host machine (1.75GB bare minimum – host performance is too slow with only 1.5GB available).
  • Connect the Hyper-V ICS Internal Network to the first NIC.
  • Connect the Hyper-V Internal Network to the second NIC.
  • Point the DVD drive at an ISO file or installation media for Windows Server 2008.
    • It’s also possible to network-boot, following a similar approach to the host deployment from WDS. To network-boot a Hyper-V machine, add a legacy network adapter (it must be legacy) and modify the BIOS settings to boot from the network.
    • We could have installed Windows Server 2008 R2 as we did on the host, but at the time of our pilot it was still only in Release Candidate, so we opted to stick with a tested OS in order to compare the development experience with our current environments. I built our SharePoint 2010 Technical Preview and Beta environments on Windows Server 2008 R2 RTM without problem.

Turn on the virtual machine and install Windows Server 2008 Standard. On completion, log in for the first time, insert Hyper-V Integration Services from the Virtual Machine Connection’s Action menu and reboot when prompted.

Initial configuration

These steps establish basic connectivity and improve usability:

  • Log in to the new virtual machine and enable remote desktop connections using any version (in order to support older versions of Royal TS). If all versions of Remote Desktop are current then select the secure option.
  • Test that the ICS connection is able to retrieve an IP address and that the connection is receiving connectivity from the host machine. If there are any problems connecting to the LAN or web, make sure that the connection is shared in the host and that the ICS connection in the guest is on DHCP. Also check the firewall settings. No settings should need to be modified but make updates if necessary.
    • Temporarily plug the Hyper-V External network in to this adapter for testing if needed. This is a good way of identifying if a problem relates to ICS itself or if it’s a guest firewall issue.
  • Add DNS suffixes to the ICS connection if you want to be able to resolve host names on your LAN (without having to use the fully-qualified domain name). ICS will not pass through primary or connection specific DNS suffixes.
    • Go to the ICS Connection’s IPv4 properties.
    • Select Advanced.
    • On the DNS tab select the Append these DNS suffixes (in order) radio button.
    • Add domain suffixes for any named resources that should be resolved using host headers.
  • Configure IP settings on the Internal Connection in the guest.
    • Configure IP addresses as 192.168.200.100.
    • Set the Subnet Mask as 255.255.255.0.
    • A default gateway and DNS settings are not necessary.
  • Remove IPv6 from all connections in the host and guest. See earlier guidance for more information.
  • Give all adapters sensible names.
    • I chose “ICS Connection” and “Internal Connection”.
  • Test browsing to \192.168.200.1 to test connectivity over the Internal network.
  • Optionally, turn off IE Enhanced Security Configuration (ESC) for administrators.

Patching

  • Apply Windows Server 2008 SP2.
    • Reboot.
  • Patch current.
    • Reboot if prompted and patch again if patches are available. Reboot again if needed and repeat until current.

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “Windows installation and patching complete”. You will be able to roll back to this state if you have problems with the Windows configuration.

Adding Prerequisites

Adding Web Server (IIS) role

Start up the virtual machine and add these Windows Role services:

  • Web Server
    • Common HTTP Features
      • Static Content
      • Default Document
      • Directory Browsing
      • HTTP Errors
      • HTTP Redirection
    • Application Development
      • ASP.NET
      • .NET Extensibility
      • ISAPI Extensions
      • ISAPI Filters
    • Health and Diagnostics
      • Logging Tools
    • Security
      • Basic Authentication
      • Windows Authentication
      • Request Filtering
    • Performance
      • Static Content Compression
      • Dynamic Content Compression
  • Management Tools
    • IIS Management Console
    • IIS Management Scripts and Tools
    • Management Service
  • Windows Process Activation Service
    • Process Model
    • .NET Environment
    • Configuration APIs

Adding Features

Add these Windows Features:

  • Desktop Experience
  • Optional: Windows System Resource Manager (and Windows Internal Database)

Installation of the Desktop Experience will prompt for reboot. It is not necessary to do so immediately. Note that when the reboot happens, Windows will restart a few times. This is a normal part of the Feature configuration.

Additional preparation

HOSTS file entries

Created the following HOSTS file entries for the web applications:

192.168.200.100                SSPAdmin

192.168.200.100                MySite

192.168.200.100                Portal

DisableLoopbackCheck or BackConnectionHostNames updates

Either disable the Loopback Check or add BackConnectionHostNames entries. Since ICS prevents inbound connectivity to these virtual machines we feel comfortable disabling the loopback check, as this would be a considerable annoyance to developers otherwise. For unisolated systems I would always recommend putting the BackConnectionHostNames entries in place. Spencer Harbar has summarised the background information best.

To disable the Loopback Check, add a new DWORD DisableLoopbackCheck value “1” to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

Creating the Source repository in the host and sharing to guests

To understand these steps it is worth reviewing the Local source code storage on the host machine section of the design post.

  • Create a new user account in the guest machine called SourceShare, with same password as the account that was created by the WAIK unattend file in part four of this series. This password should be strong, as the share will be visible to authenticated users on the host machine.
  • Confirm that the CreateSourceShare.bat script from part four has created a folder on the host system that is shared it to the SourceShare user with full control. Remove “Everyone” from the sharing permissions and replace with “Authenticated Users”.
  • In the guest virtual machine, map the Z drive to \192.168.200.1Source, specifying the SourceShare account credentials and that it should be reconnected at login. Save the password.
  • Test the connection by opening the Z drive. If there are problems opening the drive, browse to \192.168.200.1 and troubleshoot from there.
  • If users have trouble with the strength of the password, allow them to change it to something that they will remember, but make certain that it is changed in both the host and the guest and make sure they know that the change will need to be applied to all snapshot states and any other virtual machines that use this repository in the host.

Note: if you would prefer to store source code in the virtual machine it is not necessary to follow these steps. The benefits of preserving code outside of the snapshot state need to be weighed up against the drawbacks of rolling back to a state when some of that code did not exist, and users of the system need to be aware of the implications of using either approach. Clearly this approach adds some complexity and any approach should be validated for your needs.

Create local user accounts for services and application pool identities
  • SQL service accounts (which should be for obvious purposes):
    • SQLSvc
    • SQLAgent
    • SQLAnalysis
    • SQLReporting
  • SharePoint service accounts and application pool identities:
    • MossSetup (installation account)
    • CentralAdmin (farm account)
    • SSPAdmin (Shared Services Administration site application pool identity)
    • MySite (MySite application pool identity)
    • Portal (Portal application pool identity)
    • SearchService (MOSS Search service account)
    • SharedServices (the SSP web service identity)
    • ContentAccess (the crawl account)

Assign the MossSetup account local administrative rights.

Activate windows

Add a valid Windows license and activate the system. Aside from obvious compliance issues, if this is not done you will see repeated 12321 Security-Licensing-SLC “Token-based Activation failed” warnings in the event logs.

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “Windows configuration complete”. You will be able to roll back to this state if you have problems with the SQL installation.

SQL 2008 Setup

Installation

Start up the virtual machine and run the SQL 2008 installer. Select all features.

  • Give the instance a name or choose the default instance name according to preference.
  • Set up SQL services under these accounts:
    • SQLSvc
    • SQLAgent
    • SQLAnalysis
    • SQLReporting
    • Everything else can run as Network Service.
  • Disable Analysis, Reporting and Integration services. We do not run these services by default in order to optimise performance. However, we do install the services to speed up deployment as needed. Use as necessary in your environment.
  • Select Windows Authentication.
  • Select the local Administrator account as a Server Administrator.
  • Install Reporting Services in SharePoint integrated mode.

After installation completes, launch the SQL Management Studio and assign the MossSetup account DBCreator and SecAdmin rights. It will not be necessary to assign other permissions directly in SQL, as the setup account will assign DBCreator/SecAdmin rights to the farm account.

Patching

Add the SQL Server 2008 Feature Pack and SQL Server 2008 SP1 and. Reboot as necessary and patch with the latest Cumulative Update.

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “SQL 2008 configuration complete”. You will be able to roll back to this state if you have problems with the MOSS installation.

MOSS deployment

Installation and initial configuration

Start up the virtual machine. Log in with the MossSetup account and follow these steps.

  • Run the MOSS installer with (at least) SP1 slipstreamed. Select the Complete Server Type.
  • When the installer completes, un-tick the “Launch SharePoint Products and Technologies” wizard tick box.
  • Open a command window, running as Administrator and navigate to the BIN in the 12 Hive. Run PSCONFIG –cmd configdb –create to manually specify friendly names for the Central Admin databases and to assign the CentralAdmin farm account as the user. Specify both the Central Admin configuration and Content databases or they will receive an awful GUID for a name. Find more information about PSCONFIG on TechNet.
  • Launch the SharePoint Products and Technologies Configuration wizard from the start menu. Retain the connection to the newly-created farm databases and proceed through the configuration wizard according to your build requirements. I recommend that you specify a standard Central Administration port if you use one and authenticate using NTLM.
  • Once the wizard completes, launch Central Administration to confirm that the site is up and running.
  • There are tips and tricks that you may want to include for your developers, for instance Andrew Connell’s suggestions and an interesting use of junction points from the Share Notes blog.
    • Consider putting a desktop, task bar or start menu shortcut to the 12 hive.
    • Add an environment variable for the 12 hive’s BIN.
      • Go to the machine’s Advanced System Properties (right-click My Computer and select Properties).
      • Click the Environment Variables button.
      • In the System variables pane, scroll down to Path and select “Edit”.
      • Clicking in the Variable Value will put the cursor at the end of the line. Type a semi-colon.
      • Copy and paste the path to the 12 hive’s BIN, typically:
      • C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “MOSS installation complete”. You will be able to roll back to this state if you have problems with the farm configuration.

Farm build and configuration

Start up the virtual machine and launch Central Administration from the Start menu or navigate to it in Internet Explorer.

  • Enable Intranet Settings for the Central Admin site. This option should appear as a prompt directly beneath the tabs.
  • Grant Launch and Activation permission to the local WSS_WPG and WSS_ADMIN_WPG groups in the IIS WAMREG DCOM component. This prevents system error 10016. See KB920783 for more information.
    • If necessary, do the same thing on the oSearch DCOM componet, per KB953137.
  • Enable the MOSS Search service, running under the <MACHINE NAME>SearchService account with “Reduced” performance, using all WFE servers.
    • If the account name is entered without the <MACHINE NAME> prefix, you will likely see this error:
      “An unhandled exception occurred in the user interface.Exception Information: OSearch (SearchService)”.
  • We have not configured any other central administration settings in order to provide the farm in the cleanest state possible. That said, perform any additional configuration here as needed, but be aware that many settings are not suitable for all projects.

Create the Shared Services Provider

Configure the farm’s shared services as prompted by the left navigation. This will step through the creation of the SSP administration and MySite web applications and then the Shared Services web service itself.

  • Create a new SSP administration web application when prompted.
    • Use the host name and load balanced URL that was set up above: http://SSPAdmin
    • Use the application pool identities as created above: SSPAdmin
    • Select NTLM authentication, unless there is a reason not to.
    • Give the content database for the web application an appropriate name, such as WSS_CONTENT_SSPAdmin, according to internal naming conventions.
  • Create a new MySites web application when prompted.
    • Use the host name and load balanced URL that was set up above: http://MySite
    • Use the application pool identities as created above: MySite
    • Select NTLM authentication, unless there is a reason not to.
    • Give the content database for the web application an appropriate name, such as WSS_CONTENT_MySite, according to internal naming conventions.
  • Proceed with the SSP configuration:
    • Use NTLM authentication.
    • Specify the SharedServices application pool identity.
    • Do not use SSL, as this traffic is not leaving the server.
    • Typically in a stand-alone devlopment environment it should be OK to use the default SSP database naming suggestions, but adhere to internal standards where they apply.
  • Wait for the configuration wizard to complete. This can take some time.
  • Visit the SSP administration site to confirm that the web application has been successfully created.
  • In Central Administration, navigate to Self-Service Site Management and enabled Self-site creation for the MySite web application.
  • Visit the MySite link in Central Administration to confirm that the web application has been successfully created.
  • Log in to the SSP Administration site and take these steps:
    • Specify a default content access account: ContentAccess
    • Grant full personalisation services rights to the local administration account.
      • This account can be used to grant rights to yet-to-be-created local users of the system once they receive this build, if desired.

Create the web portal

In Central Administration create a new web application.

  • Use the host name and load balanced URL that was set up above: http://Portal
  • Use the application pool identities as created above: Portal
  • Select NTLM authentication, unless there is a reason not to.
  • Give the content database for the web application an appropriate name, such as WSS_CONTENT_Portal, according to internal naming conventions.
  • Create a root site collection using the collaboration portal template. Make the local administrator account and the Moss Setup accounts site collection administrators – to be changed by local users on receipt of the build.
  • Visit http://portal to confirm that the site collection has been successfully created.

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “MOSS configuration complete”. You will be able to roll back to this state if you have problems with the patching.

Patch current

Start up the virtual machine and patch the environment to whatever state is needed. We typically recommend patching current. During the course of our pilot we used the April 2009 Cumulative Update. When we released the base virtual machine to our entire development team we launched with the June 2009 Cumulative Update. Once patched current, test that all sites are still working as expected.

Full patching guidance is available on the Update Center for Microsoft Office, Office Servers, and Related Products site.

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “June 2009 CU applied”. You will be able to roll back to this state if you have problems with developer tool installation.

Tool installation and export

Developer Tool installation

Start up the virtual machine and install the common development tools for your organisation. These are the standard tools used by our developers. There are also some licensed products that are installed for some users outside of the scope of the base build.

  • Microsoft Office SharePoint Designer 2007 SP2
  • Microsoft Visual Studio Team System 2008 Developer Edition (we created a separate snapshot for users that need Visual Studio 2005 rather than running them concurrently)
  • Microsoft Visual Studio Team System 2008 Team Explorer
  • Microsoft Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider
  • TFS Power Tools
  • Microsoft Visual Studio Team System 2008 Developer Edition SP1
  • Microsoft Visual SourceSafe
  • WSPBuilder Extensions 1.0.5
  • StyleCop
  • Fiddler2
  • Sandcastle
  • Sandcastle Help File Builder
  • HTML Tidy
  • PDF X-Change PDF Viewer
  • Firefox with Firebug
  • Safari
  • Chrome
  • Opera
  • SharePoint Manager 2007
  • Microsoft Silverlight
  • Adobe Flash for IE
  • Adobe Flash for Firefox, Safari and Opera
  • Microsoft Forefront Client
  • Test Mail Server

On completion of installation, defragment the disk and wait for completion.

Shutdown and snapshot

Shut down the virtual machine and take a snapshot. Rename the snapshot with an appropriate name, such as “Developer tools installed”. You will be able to roll back to this state if you have problems with the farm configuration.

Snapshot branches

If you will be using different versions of Visual Studio (or anything else) it’s worth creating distinct branches for each version. You could adopt an approach like this:

  • Install all of the independent tools, shut down and take a snapshot, renamed to something like “Developer tools except VS installed”.
  • Install Visual Studio 2008 and patches. Defragment, shut down and take a snapshot, renaming to something like “Visual Studio 2008 installed and patched current”.
  • Apply the “Developer tools except VS installed” snapshot. Install Visual Studio 2005 and patches. Defragment, shut down and take a snapshot, renaming to something like “Visual Studio 2005 installed and patched current”.
  • The two Visual Studio snapshot are now siblings – children of the “Developer tools except VS installed” snapshot node. A third sibling could be created in this same manner for Visual Studio 2010 Beta 2 (for instance).

We install Visual Studio last in the installation sequence in order to maintain consistency among these variants as deep in to the snapshot tree as possible. To give another example, I’ve just built a SharePoint 2010 Beta environment with Visual Studio 2010 Beta 2. In that environment there was only one instance of Visual Studio but two SharePoint branches – one for SharePoint Foundation and another for SharePoint Server 2010. In that tree I installed all developer tools and Visual Studio before installing either SharePoint edition. If you have similar branching needs, plan to install those items last and structure your snapshot trees accordingly.

Export

You may choose to export the entire virtual machine rather than the final snapshot, depending on how standard you want the final build to be. If a developer can role back to an earlier state then the standardisation of the build is at risk. In our case, we’ve exported the final snapshot (or each of the final sibling nodes in the snapshot tree, since some users use Visual Studio 2005). This state is vanilla enough that it can be used as a common starting point for a wide range of projects. It has even been used as a starting point for projects that extend beyond SharePoint to accessibility solutions, Commerce Server and BizTalk.

This is not to say that this build fits all sizes, but it does fit most of them while obtaining the benefits outlined in the first post in this series. Some of the limitations of this approach are discussed in the next part of this series.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.