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_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

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.1\Source, 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 Files\Common Files\Microsoft Shared\web server extensions\12\

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.

Why we’ve chosen Hyper-V

There are broadly five decisive factors: performance, management features (like snapshots), cost, 64-bit OS support and a full host OS (not just a virtualisation administration console):

• Hyper-V is now in its second iteration and has proved to be one of the best-performing virtualisation technologies on the market. With laptops we need to take advantage of every performance gain that we can find.
• Perhaps most importantly, and most often overlooked, Hyper-V is free if you’re already running Windows Server 2008 or Windows Server 2008 R2as a client OS
  • While I work for a Microsoft Gold Partner and Hyper-V is a key part of Microsoft’s future strategy (full disclosure), I believe that most SharePoint developers will have at least an MSDN subscription and a license for a Windows Server operating system, so I believe this is compelling for most SharePoint development environments
• Hyper-V is one of the few virtualisation technologies that supports 64-bit guest operating systems and within that narrow range of choices, it is one of the few that allows a user to log on to a host machine and control virtual machines within it concurrently
  • For instance, VMware ESXi is also a high-performance Type-1 hypervisor that supports 64-bit operating systems, but there is no host machine other than a virtualisation administration console
    • It also has associated costs (support, management tools, etc) that we would prefer to avoid
  • With Windows Server 2008 R2 and Hyper-V, developers can use client tools within a familiar operating system while accessing virtual development environments at the same time
    • This is also true of VMware Workstation, but it’s a Type-2 hypervisor and will have relatively poor performance
  • We need to have 64-bit OS support for Windows Server 2008 R2 and SharePoint 2010 – both of which do not have 32-bit flavors

Our approach

Workgroup development

By building our virtual machines in a Workgroup, we no longer need to worry about SharePoint installation/(re)configuration difficulties, as we will import the same identical virtual machine on everyone’s Hyper-V host. This would not be possible if the virtual machine was a member of a centralised domain because the domain controller would receive chatter from many identical machines and everything would quickly start to unravel

Alternately, we could run Active Directory Domain Services within a virtual machine, but this has a performance overhead that is best avoided unless it is absolutely necessary. Additionally, developing on a domain controller is not ideal

While developing in a Workgroup presents challenges for profile imports, these are far from insurmountable when LDAP directories like AD LDS or SQL users can substitute in many scenarios. The only evident need is a scenario where Active Directory Domain Services (more than just user accounts) are required, and that’s certainly not going to be true of enough projects that it should form a part of the base build. To this end, as requirements for Domain Services are identified we will provide new builds, as they are likely to be very project-specific

Networking

Internet Connection Sharing network

In order to isolate identical virtual machines from each other and from network resources, I’ve created a Hyper-V internal network dedicated to receiving Internet Connection Sharing (ICS) from one of the host’s active network connections. This is an internal network like any other Hyper-V internal network – it just so happens that the host’s adapter on this network will be receiving ICS from another of the host’s connected adapters. Any connection can share to the ICS network – even if Hyper-V doesn’t natively support external networks of that type. Depending on the need, we will share to this ICS network from:

• Hyper-V host external connections (by default)
• Wireless
• Mobile broadband
• VPN

ICS also introduces a layer of NAT between the guests and the physical network, preventing inbound connections to guests over these networks. This is desirable as it is how we achieve physical network isolation, and is the reason why we’ve chosen ICS over Bridging. In the ICS Settings we enable outbound RDP, HTTP and HTTPS connections over ICS by default, although it may be useful to enable other common outbound network protocols like FTP and SMTP. Outbound connectivity from our guest virtual machines is primarily used for connecting to TFS over HTTPS.

Internal network

We have also created a Hyper-V Internal network to support “always on” communication between the host machine and the guest virtual machines. Guest virtual machines can also communicate with each other over this network.

We cannot rely solely on the ICS connection. Guest virtual machine IP addresses on the ICS network will change because they receive them via DHCP from the host’s ICS connection. This is just how ICS works. The host’s ICS adapter becomes a gateway on 192.168.137.1. Any Hyper-V guests on that network pick up DHCP from the host and are automatically assigned an address on the 192.168.137.xxx (255.255.255.0) IP range.

As we rely on HOSTS file entries for RDP connections from host to guest and for browsing to guest SharePoint sites from the host, we need fixed, reliable IP routing and name resolution, so we use this second network for that purpose. The hosts and guests have both been built with fixed IP addresses on this range.

Because this is a Hyper-V internal network, there is no risk of network collisions on these IP ranges (which are identical for all users). Internal traffic never leaves the machine.

Project builds

By providing self-contained environments, our technical leads and/or architects can now customise the base builds to create project-specific virtual machines that can be exported to all members of a team, reducing system/configuration inconsistencies. In practice, the build lead/architect will export the final snapshot of the project environment, which all team members will use as a starting point for project development. As the project progresses, updated builds can be released in this same manner.

Clean hosts

Host machines will be cleaned of development tools and data, allowing quick provisioning. Development tools will not need to be reconfigured, as they will reside in virtual machines that can be exported/imported to any host. Guest base build virtual machines will be provided with as much SharePoint configuration as possible in order to make them light on reconfiguration, disposable and re-deployable.

Project resumption

Project-specific exports will reduce the need for storage of multiple virtual machines – as much as possible. We will retain one virtual machine export in public storage per-project. This will reduce the amount of time involved with resurrecting environments after project completion.

Optimisation

Host machines are built on Windows Server 2008 R2, optimised as much as possible and reduced to the lightest weight achievable. The build will broadly include:

• Hyper-V R2
• Microsoft Office applications
• All browsers
• No development tools (these will all live in guest machines)
  • The only exception to this is the Team Foundation Client which TFS administrators manually install. We have not been able to pick domain users from within a Workgroup environment

Content provisioning

By deploying a single project-specific virtual machine, we can bake content in to the project build, ensuring consistency and reducing the overhead associated with re-deploying content.

Improved testing and reduced volatility through the use of snapshots

By using snapshots we are able to test code and configuration changes without volatility. The benefits of this technology include:

• Capturing restore points at milestones in a server build
• Capturing a stable state before attempting volatile configuration changes
• Capturing a stable state before testing code changes
• Creating an initial restore point after importing a virtual machine and re-configuring network adapters (when required) and making other preferential settings
  • This saves re-importing and reconfiguring network adapters if a machine needs to be rolled back to its initial state
• Exporting a virtual machine to capture a problem when trouble occurs
  • An exact instance of a problem can be captured and shipped out for support, without having to re-create the problem in a distinct environment. This will only apply tot self-contained environments, however

Local source code storage on the host machine

Before our pilot started we identified that storing the local copies of source code within changing snapshot states could create problems. At the same time, we found it desirable to put the development tools inside our virtual machines in order to get around remote SharePoint development difficulties and to keep the host build uncluttered. To resolve this conflict, we adopted this approach:

• Created a share on the host machine and granted ownership of that directory to a new user account that is used solely for this purpose
• Created a new user account with the same name and password in the guest virtual machine
• Mapped a drive from the guest to the host’s new share, using the internal network’s IP address and these new credentials
• Launched Visual Studio and downloaded project source code, pointing to the newly mapped drive as the location for the local source
• Created a new Code Group for the mapped drive to enable trust for code execution

These steps are covered in more detail in the build guides that will follow in later posts. This is just an outline of the approach to extracting the local code from the snapshot state, which should be adaptable to other development systems with snapshots. For instance, we’ve found it necessary to download code to a unique location within this directory for each each user, as TFS tracks the network locations that code is checked out to. This is easy to get around, as each user just specifies a unique directory name. If this were insufficient for project requirements, this TFS behaviour could possibly be “fooled” by using NTFS junction points. We’ve not seen a need for this yet, but we’re confident that with this additional option we should be able to store local source code in this manner, and this has been validated by our project experience with Hyper-V to-date.

Summary

These are the high-level design choices that emerged early in the consultancy and research, which have remained largely unchanged to-date. These choices represent one design that has been validated for our needs, which has some shortcomings like any approach. Some of these issues will be covered in the final post in this series.

The information in this post has not covered implementation in any detail, but do not fret. In the next section I will cover the step-by-step build guide for the Hyper-V host laptop.