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.
When I initially created our SharePoint 2010 beta development environments, I built them in a Workgroup, for many of the reasons that I chose to do so in 2007 (see the Workgroup Development section in Part II of my series on SharePoint development environments). Now, the SharePoint 2010 Configuration Wizard (psconfigui) throws an error when choosing the Complete install option in a Workgroup. I was able to get past this error by following the suggestions on the Microsoft From the Field blog, but a few weeks down the road we’ve pinned down two issues (as confirmed by Neil, the author of that post).
- Search will crawl successfully in this configuration, but the query role will never initiate. Queries from web applications that consume this Service Application will produce an error, which you will be able to trace to an application event log 6398 error and the key event in ULS, “The SDDL string contains an invalid sid or a sid that cannot be translated.” As Victor Magidson from Microsoft puts it on this Technet thread, this error occurs when a, “topology activation job is trying to create a propagation file share.” In short, the query role never finishes initialising so it will never serve queries. This only occurs on the single server Complete installation and deleting/re-creating the Service Application yields the same result.
- The User Profile service application will also be useless*, but it always would have been since you couldn’t import users from the local user database in 2007 either. However, this has wider implications in SharePoint 2010 because of the social computing features, which developers probably won’t be able to live without.
All this means that I need to consider rebuilding our development environments in a domain or we need to use the Simple installation. In the past I always avoided the Simple installation because it uses system accounts like Network Service for application pool identities, so it took some re-acquaintance to identify some of its limitations. It has no configuration options (thus the use of local system accounts), the User Profile Service Application does not start (presumably per Forefront Identity Manager 2010 installation issues as seen in other topologies) and it uses SQL Server Express (which developers aren’t very fond of), so we’re unlikely to pursue this option. Accordingly, we’re reviewing the ways that we can re-create the development environment in a domain.
Why don’t I just make the development machine a domain controller? This isn’t clear-cut and there are benefits to the simplicity of it, but ultimately I think it’s a bad idea because:
- Domain Controller security is bad for development. It means developers will be coding as Domain Admins and they will be doing so on a machine with Domain Controller security policies. This is just a mess.
- SQL doesn’t like to run on a DC.
- Running a DC, SQL and SharePoint on the same machine creates a massive load of service start-up contention and sometimes the environment will start from an unstable point because dependent services will not be ready when a depending service tries to start.
- This also increases start-up time considerably, which is a big concern when using Hyper-V on a laptop, where we don’t have Sleep/Hibernate.
- Adding Visual Studio to this mix causes known performance issues. The machine simply can’t keep up with doing all of this.
Why won’t we use a central development domain? Because then we can’t clone the VMs. We don’t just clone standard builds, we also use the same VM for each developer/consultant/architect on a single project. We may opt for this approach eventually, but I think the investment in automation is pretty considerable for it to be efficient with our team development requirements.
So I’m probably going to separate the DC on to a different server for now. I’m unlikely to add a third server for SQL, as even though it might be faster, I think the complexity of managing networking and snapshots across three servers is undesirable for developers, if we can get by with two.
All of this underlines the reasons why I didn’t publish any SharePoint 2010 build guidance yet. Some things don’t become clear until you get your hands dirty. I’ll revisit this topic as soon as I feel comfortable that we’re pinning things down, but for now we’re still adapting our methods.
*I’ll note that I haven’t properly tested Claims Based Authentication against a single server complete installation, so it’s conceivable that you could import non-A/D users in to this configuration, but you’d still need to live without Search.