To understand the development environment design choices that this article pertains to, it may be worth glancing at the design section of my SharePoint development series before diving in, if you haven’t already followed those posts.
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.
Continue reading “Publishing a network-isolated virtual machine with RemoteApp”
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.
Continue reading “SharePoint 2010 (not) in a Workgroup”
It’s now a week on from Mark Russinovich’s NewSID retirement announcement and I’ve been watching the feedback since. To give a brief overview, it’s long been a tenant of machine cloning processes that a new machine SID should be generated for each clone in order to prevent conflicts. Mark Russinovich wrote the original NewSID tool for Windows NT and as a Microsoft Technical Fellow today, he supposed that it might not be needed anymore and investigated the implications of retiring it. Obviously, if you haven’t read it yet and you work with machine cloning, you should read the article, but if you haven’t found the time to sift through the 168 comments (and counting), this summary might help clarify things:
Continue reading “NewSID myth implications for SharePoint development”
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”