In my previous post I introduced some of the peculiarities of designing SharePoint 2010 environments for Amazon’s EC2, specifically focused on the AWS platform, storage, snapshots and provisioning. In this post I continue this exploration, moving on to cloning and networking considerations.
The Amazon Web Services (AWS) have been around for a while now but there’s been surprisingly little use or abuse in the SharePoint community, from what I’ve seen. A notable exception to this is Andrew Woodward’s novel and interesting approach to Exchange BPOS migration via Amazon EC2. But that doesn’t talk much about SharePoint on Amazon, so in these posts I’ll give an introduction to the design constraints that pertain to SharePoint 2010 development environments on EC2. Even if the Amazon Web Services aren’t appealing, a lot of the issues discussed here will apply to consumption of other Pay-As-You-Go infrastructure services, presumably including the forthcoming Windows Azure VM role AKA Hyper-V Cloud. In this first post I focus on the platform, storage, snapshots and provisioning.
Cloning isolated VMs vs. scripted installation
One of the challenges we’ve always faced with SharePoint development has been the tension between cloning actually identical environments versus automating the deployment across distinct environments (or worse, repeating the installation manually). In the first case we save time by eliminating reconfiguration and this ensures a consistent experience for each user. This is particularly beneficial for software development. These benefits can also be obtained by scripting installation/configuration/deployment but there’s a considerable overhead associated with developing and testing those scripts. As SharePoint 2010 is still quite new and we’ve been working on projects for some time now, we didn’t have the luxury of waiting for those refinements and we needed to take advantage of these efficiencies as we had done with SharePoint 2007 projects.
With SharePoint 2010 RTM looming, I’ve stumbled across an architectural change that may surprise some people – namely, that SharePoint 2010 no longer supports multiple-server farms without a domain infrastructure. In SharePoint 2007 it was possible to create SharePoint farms in a Workgroup, so long as all of the user accounts for the services and application pool identities were named the same and had the same password. You could even manage users with an Active Directory Lightweight Directory Services (AD LDS) or Active Directory Application Mode (ADAM) LDAP directory (albeit with some fairly limiting restrictions). However, it was possible to use these farms for testing or when an Active Directory infrastructure was undesirable (as some people see it in a DMZ). Now, it is still possible to do a Simple installation on a single server without full domain services, but it is no longer supported on multiple servers, and the Simple installation comes with its own planning considerations, to which I’ll return in a bit. First, there’s another wrinkle regarding the single server Complete installation.
I’ve recently been involved in MOSS 2007 farm topology discussions with a client that was interested in using the Split back-to-back topology. After a lengthy troubleshooting and escalation process we’ve identified some problems with this TechNet extranet farm topology guidance in conjunction with Microsoft Tier 2 support. In short, the TechNet document identifies some supported topologies that span domains, but this incident has raised questions about:
- The acceptable placement of server roles in those topologies.
- Supported domain trust directions.
- Alternate Access Mappings requirements.
- Picking people from other domains.
This is an account of the relevant issues and the steps that we took to reach our conclusions. Continue reading “SharePoint Server 2007 cross-domain farm topologies”
In the first five parts of this series I covered the project objectives and the system design, then turned my attention to the Hyper-V host image build, automated deployment and the guest virtual machine build. In this post I review some of the questions and issues we’ve encountered after a few months of working this way and some overall reflections on the approach. Continue reading “Building a SharePoint 2007/2010 development environment — Part VI: Issues and Results”
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… Continue reading “Building a SharePoint 2007/2010 development environment — Part V: Guest Build”
In the first three parts of this series I covered the project objectives and the system design, then turned my attention to the Hyper-V host image build. In this section I will look at automating deployment of that host operating system. This is lengthy, but there’s a lot to cover.
Having agreed the project objectives and designed the system, I turned my attention to the Hyper-V host image build. This is a high-level build guide with start-up time and baseline memory consumption benchmarks at key milestones. These benchmark figures were taken from the Windows Server 2008 R2 Release Candidate build and are admittedly a bit imprecise. However, they do provide an overall indication of system performance as things were added to and removed from the installation. Although I do not have precise figures on RTM improvements, I spot-checked a few of these benchmarks when I rebuilt the system on RTM. Start-up times improved slightly at each milestone. In fact, the final benchmarks came in at 100MB less idle memory used in the RTM release. Continue reading “Building a SharePoint 2007/2010 development environment — Part III: Host image build and performance benchmarks”
In the first part of this series, I introduced the pros and cons of various SharePoint development approaches and the objectives of this system redesign. In this part I will focus on design choices and conclusions, starting with the core technology.
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): Continue reading “Building a SharePoint 2007/2010 development environment — Part II: Design”