Groundhog Day: Configuring Back Connection Host Names using Group Policy

Quite some time ago I posted coverage of the DisableLoopbackCheck registry key and how it impacts SharePoint. It’s amazing just how often this comes up on the Interwebz. Scarily the common advice given is to turn this feature off. And that’s bad advice. In my original post I detailed why. In a nutshell: OK in test/dev, NOT OK in Production.  Yesterday my buddy Bob Fox posted a follow up, DisableLoopBackCheck? Let’s do it the right way. His post details how to configure a list of names which won’t be checked.

This is all good, but what if you have more than one box? Fiddling with the registry is no fun on a single server, never mind ten! Another buddy Gary Lapointe put together a nifty STSADM command to do this. This is also pretty cool, but as an STSADM extension its tied to the SharePoint infrastructure, and it also suffers another problem – it requires local machine administrator rights to work. What we’re really after is an automatic way to seamlessly apply the configuration.

So how would we go about doing this “properly” and in an automated fashion? After all it’s just a couple registry keys. There are a multitude of approaches (VBS, .REG, Powershell etc) but they are all actions that must be performed on each server or if not have to then be tied to an implementation.

Say we have a Farm of machines and we want to configure them all. Well it’s very very simple. We use Group Policy. I’m frequently amazed how few SharePoint administrators understand Group Policy. I often hear the response, “but we’re not using Group Policy to manage our SharePoint Servers”. I’ve got news for you, you are. A SharePoint Farm requires a Domain. Therefore your servers are managed by Group Policy! Probably not very well with the default settings mind.

So the answer is Group Policy, great! But how do we do it? Well what we really want is a custom Administrative Template, which provides us with a GUI for managing the settings centrally and applying them automatically (without requiring local admin rights on the SharePoint machines). Something like this would be just the ticket:

The trouble is we can’t do this. The BackConnectionHostNames value is Multi-String. And the ADM infrastructure doesn’t support Multi-String! You can’t hack it so it uses a regular String either. That leaves us with deploying a .REG file at start-up via Group Policy. That's a crap option because it’s a start-up script and those are evil, plus managing Multi-String values in a text file isn’t fun.

The good news is with Windows 2008 domains we can set Registry Values using Preferences, Windows Settings, but the UI is pretty awful and it’s not really the right approach.

What we really want are a couple of lines of PowerShell to configure the policy. And yes, that’s all we need! One PowerShell Script and a text file of the names you wish to exclude! That’s it!

But first we need an Organizational Unit on which to apply the Group Policy. You should be doing this already, but you can see below I have an OU called SPFarm1, that contains the two machines in that Farm:

Hopefully the picture is becoming clear now why Group Policy is so compelling. I can have multiple farms each within a different OU with different lists of hosts to ignore (along with a whole host of other configuration you may need). Sound like a good idea for your HyperV rig running dozens of test farms? I thought so!

Then we need a Group Policy on that OU. To create this we load up Group Policy Management. Expand the domain until the OU is displayed. Right click the OU and choose Create a GPO in this domain, and Link it here.

Give it a sensible name and click OK. Now we have a group policy to which we can apply configuration.

Great, now we have a Group Policy defined. If we wanted to we could edit the policy here and expand out the Computer Configuration –> Preferences -> Windows Settings -> Registry Node. But it’s not very nice and we have to drill down into the keys we are interested in and so on. This UI simply doesn’t scale that well.

Thanks to the new PowerShell cmdlets in Windows Server 2008 we can do all that in a single operation. First we need a text file with out host names, one per line. For example:

www.sharepoint.com
intranet.sharepoint.com

Save this file as c:\names.txt, then you run the following PowerShell to register the Group Policy cmdlets:

Import-module grouppolicy

This command sets disables Strict Name Checking so you can use a list of names:

Set-GPRegistryValue
     -Name "SPFarm1"
     -Key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
               services\LanmanServer\Parameters"
     -ValueName "DisableStrictNameChecking"
     -value 1
     -type dword

This command adds the addresses to ignore using the text file we created above:

Set-GPRegistryValue
     -Name "SPFarm1"
     -Key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
                   Control\Lsa\MSV1_0"
     -ValueName "BackConnectionHostNames"
     -value (Get-Content("c:\\names.txt"))
     -type multistring

Want the whole thing as a .ps1 script you can run? just collapse them together. Of course the first PowerShell Command is only necessary the once. The second one will update your list of names. As you change your names, just change names.txt and rerun the second command. Then your SharePoint boxes are updated by Group Policy, or you can run gpupdate.exe if you are impatient.

Note: You need to restart the machines on which policy is applied once you have applied DisableStrictNameChecking for the first time.

Simple. Easy. And no disabling of a pretty reasonable security feature. That’s platform hygiene, you know it makes sense!

Now Available: Interacting with the Excel Web Services API for SharePoint Server 2007

An article I worked on recently has just been published to MSDN. The article walks developers through the basics of getting started with the powerful Excel Web Services API for building BI and Calculation based services on SharePoint Server 2007.

Get a quick start with the Excel Web Services API, which enables interaction with published Microsoft Office Excel 2007 workbooks in Microsoft Office SharePoint Server 2007 from a remote application. Learn considerations around session state, security, and performance. (6 printed pages)

Many thanks to Randall Isenhour, Kimberly Hope and the MSDN crew for their help in producing this content.

MSDN: Interacting with the Excel Web Services API for SharePoint Server 2007

The best SharePoint Conference ever is back, with a vengeance!

No disrespect to the SharePoint Team at Microsoft. They put on a *great* show. But well, ya know, it’s an official Microsoft conference, and some things are just done better by the community. Last year in April I flew into London exhausted after a crazy six weeks in Redmond for the SharePoint Best Practices Conference. Despite really needing a months holiday, it was simply the best conference experience I’ve had in over 15 years. A *great* show, great content, great people, great organisation and great fun. By a country mile, the best SharePoint related conference ever.

And it’s back, with a vengeance! Renamed the SharePoint 2010 Evolution Conference (there are no best practices for an unreleased product you dig?). The same venue, the same crew organising. The only real question is will it beat last year? It has it’s work cut out, but with 6 tracks running with 75 sessions and over 65 speakers from all over the world. The speaker list is just mind blowing! And the content has been carefully selected, this is not a level 200 marketing event, it’s the real deal.

This year I’m cutting back my conference speaking schedule but this show is too good to ignore. I have the honour of presenting three sessions at the show:

Multi Tenancy in SharePoint 2010

Brand new content for SharePoint 2010 Evolution! SharePoint 2010 delivers compelling new infrastructure features for those wishing to host multiple customers on a shared platform whilst retaining confidentiality, integrity and availability. This session will cover how multi-tenancy can benefit all sizes of deployment from a basic farm to the largest such as SharePoint Online. Learn how to approach the design of a multi-tenant deployment and to configure and operate multi-tenant infrastructure, create Member Sites, Subscriptions, Feature Packs, and Service Application Partitions. Related features such as Host Named Site Collections and Claims Identity will also be covered. This session will be split 50/50 between lecture and demonstrations.

Claims Based Authentication in SharePoint 2010

Brand new content for SharePoint 2010 Evolution! This session covers the new Claims Based Authentication support in SharePoint 2010. Whilst coverage of the Claims Based Identity infrastructure will be included, the focus is primarily on Authentication (User Sign In). Learn about the key components for leveraging Claims Based Authentication, the various shapes and sizes of Claims Providers and their required configuration. See the new Forms Based Authentication and Multi Authentication Mode in action. Learn how to design your Authentication approach and there could even be a Kerberos related surprise included! This session will be split 65/35 between lecture and demonstrations.

Note this is not a rehash of my previous Claims Based Identity sessions.

Implementing Multilingual Solutions with SharePoint 2010

Brand new content for SharePoint 2010 Evolution! Multilingual solutions present significant design and implementation challenges for SharePoint practitioners both on the Intranet and the Internet and thankfully SharePoint 2010 delivers some significant improvements in this space. See the new Multilingual User Interface (MUI) feature in action across SharePoint Sites and Metadata. Learn how to approach designing support for content translation within SharePoint Server. The improvements to the core Variations engine and the new end user focused features will be covered along with design guidance and advice for supplementing Variations with custom code. This session will be split 60/40 between demonstrations and lecture.

Note this is not a rehash of my previous Multilingual or Variations sessions.

I’ll also be at the IT Pro Ask the Experts session MC’d by Bob Fox on the last afternoon.

There will also be a few surprises, which of course I can’t tell you about now!

If you work with SharePoint and are in Europe, you simply must attend this show. But hurry up, space is filling up rapidly and it will soon be sold out. Register now!

MUST READ: SharePoint’s Sasquatch Memory Leak

Over on the rather natty looking new blog from PFE extraordinaire Todd Carter, there are details of a serious issue with SharePoint that everyone should be familiar with. Check it out.

Todd's Blog | SharePoint’s Sasquatch Memory Leak

Tips and tricks for running SharePoint Server 2010 on Windows 7

Whilst I was one of the most vocal advocates for the ability to run SharePoint Server on the client OS, it wasn’t really something I ever thought I’d want to run myself. I understood why it was of critical importance to enable this scenario, but I’m a farm guy, topologies are my bag. When the beta release came about I slapped it on a old machine just to see it working and left it at that. I also checked out the quality documentation over on MSDN which provides the convoluted steps to get it singing. Such steps are a good thing, you need to really want to install it on your client – no one can say that it will get installed by accident. :) So it’s all good and that’s that, I’ll carry on doing my stuff as I was. Or so I thought.

Like everyone else, I’ve been heads down trying to get up to speed with all the new SharePoint PowerShell cmdlets, and revitalising my long lost shell scripting prowess (that’s a joke by the way, those who worked with me back in 1998 know the score!). The trouble is when I’m working away on documentation or in email (or worse, Visio and PowerPoint) or helping folks out on IM, I don’t want to have to load up a VM just to verify some scripts. Sure I can use the excellent references, but I like to test things actually work (no really). Running SharePoint on Windows 7 is a great way to do this without the burden and delay of firing up a VM or a bunch of them.

Recently there’s been a bit of debate about the pros/cons of running it on the client OS. All good stuff, but the common complaint is that it’s just too much overhead, it’s too bloated and is too resource hungry. Part of the problem is that it installs in the deadly “Standalone” mode. Standalone mode installs everything, lock stock and two smoking barrels plus uses a bundled version of SQL Express. There are ways to get it up and running in “Farm” mode, which I won’t detail here. If you want to run in a real Farm mode you should be on a real server OS IMO. I know some folks like ‘proper’ SQL and all that, but one of the key reasons for having a client install option is to lower the barrier to entry.

Which brings me back to the main point of this article. I’ve an old (in computer terms) Sony Vaio with 4Gb RAM and a Core Duo. Sony steals 0.81Gb of the RAM for nefarious purposes. A pretty low spec laptop, and one which is probably pretty common out there in the real world. It’s very easy as a grossly overpaid SharePoint person to slip into assuming that an 8Gb laptop is a ‘minimum’ setup. The reality is I’m lucky and can afford decent kit. There are millions of developers that don’t have such luxury.

So back to my crappy laptop. Remember the 3.19 Gb RAM I have available? Well I’ve got it running happily on that no problem. Very happily indeed as it turns out. I’m just using one Web Application and it’s very, very responsive. Certainly good enough for playing around and getting up to speed. With the application pools and services spun up Task Manager shows 70% of RAM used (that’s just 2.18Gb).

The thing is standalone provisions every service, and you really don’t need them! By judicious use of Services on Server you can tweak things very easily to have SharePoint 2010 running real nice. For example, how likely is it you wish to use the Document Conversions Service? No, I didn’t think so! :)

Here are the services I have stopped in Services On Server:

• Claims to Windows Token Service
• Document Conversions Launcher Service
• Document Conversions Load Balancer Service
• Microsoft SharePoint Foundation Incoming Email
• Microsoft SharePoint Foundation User Code Service (Sandbox Solutions)
• SharePoint Foundation Search
• User Profile Synchronization Service (this one isn’t provisioned by the Standalone setup)
• Web Analytics Data Processing Service
• Web Analytics Web Service

Note: to run elements of Central Administration such as Services on Server that make machine changes you must be running the browser instance as a machine administrator (UAC elevation).

Now of course you may wish to use some of these services, especially User Code. But you can simply enable them for the scenario you are working on and perhaps stop some others. The point is you don’t necessarily need them all running all the time. Web Analytics is definitely one you don’t want running on a hack and slash box, this is a real resource hog.

Another tip to improve performance for this scenario is to ratchet back the Diagnostic Logging levels and disable Usage Data Collection & Health Data Collection (both from Configure web analytics and health data collection). This will help reduce contention on the SQL Express instance and file I/O significantly. Of course should you get into debugging you will need to fiddle with the diagnostic logging levels some, but why log stuff until you need to? Health Analyzer will moan about things not being configured but so what? It’s a hack and slash box! You could even disable that timer job as well.

Now, the setup I have isn’t running SharePoint Designer or Visual Studio yet (I will try that next), and of course if Outlook (or worse Tweetdeck) is open, things get very dicey, but my key point is that SharePoint 2010 on Windows 7 performs a lot better than it’s being given credit for. It’s all about platform hygiene at the end of the day, if you manage your box you will be rewarded. If I had all 4Gb in this machine I could easily have a couple Office apps up and running alongside it no problem at all.

Back in the day with Site Server and CMS I always used batch files to stop and start the relevant services when I needed SS and/or CMS up and when I didn’t. You can do the same thing for SharePoint 2010 with Emmanuel Bergerat’s excellent Stop and Go PowerShell scripts.

There you have it, some fairly basic tips and tricks for getting great performance from SharePoint 2010 on your Windows 7 machine even with limited hardware resources. I may follow up with more on this in the future, but there are so many interesting topics and such little time…

Oh and on another note, did you see that 74 yard interception touchdown? Hoo ya! Red beans and ricely yours.

TechNet Misinformation: How NOT to use Kerberos for SharePoint Authentication

I’m somewhat aggrieved this morning, as I found a new article from TechNet entitled “Using Kerberos for SharePoint Authentication”. Now while this article is not supposed to be the be all and end all it is very depressing that still now, in 2010, such inaccurate and in some cases 100% wrong information is being put out there by the vendor. This is especially true given the work I have done in this space over the last 18 months.

So what’s wrong with it?

Well one of the reasons people find this area difficult is nobody seems willing to really understand it in order to explain in a nutshell and in addition will skim over fundamentally important aspects. Moreover these bogus articles usually never describe a topology – mainly because the test rig is usually a single MOSS server! This article is no exception, with no clear scenario or requirements. Whilst it does a decent job of covering the core concepts, it then however goes on to detail incorrect configuration steps and completely misses some!

• Kerberos AuthN for SQL is not required unless you wish back end SQL connections to be Kerberos or make use of additional delegation scenarios.
• There is zero requirement for a SPN for a computer host name unless you are running a SharePoint Web Application using one (which you shouldn’t be).
• There is no information about how to configure Kerberos for the Shared Service Provider(s) other than a link to more info elsewhere on TechNet
• There is never a requirement to set computer account delegation unless you are implementing “advanced delegation” scenarios such as Analysis Services
• There is no requirement to set user account delegation unless you require delegation. It is not required for Authentication only.
• You never have to touch Component Services Impersonation Level unless you are implementing delegation for Analysis Services.
• DCOM activation has absolutely nothing whatsoever to do with Kerberos for SharePoint AuthN.
• IIS7 configuration should be applied on a per Web Application basis.
• KMA will not work in single MOSS server scenarios.
• SharePoint 2007 in Integrated Mode? Are you kidding me?!!!
• Network Service is not the same as a Computer Account!!!
• It even recommends “trust this user for delegation to any service”!!!!
• Kerberos doesn’t actually make SharePoint faster. Performance can be a reason to deploy, but is heavily scenario specific.

So there you have it. Not good. It appears this article cobbles together misinfo already out there. Regular readers will notice some of the myths above are those I spend a great deal of time explaining. A great shame, seeing as the real deal has been delivered for so long. This article just proves how ridiculous it is to attempt to distil Kerberos for SharePoint into 3,000 words. Let’s hope that TechNet do the right thing in the future.

[UDPATE: Following discussions with TechNet Magazine, the article will be updated in the near future. Sweet :)]

Application Pool mis-configuration in SharePoint 2010

As I’ve previously detailed there is a significant oddity with how SharePoint 2010 Beta creates Application Pools in IIS for the hosting of Service Applications and especially the two most important services in your farm, the STS and Topology. As mentioned these application pools are named with GUIDs.

Unfortunately when creating a Web Application, SharePoint 2010 uses the SharePoint only property Display Name for the STS application. The STS application is required as part of every SharePoint 2010 Web Application and lives at /_vti_bin/sts.

As the Web Application is being provisioned SharePoint uses the display name, SecurityTokenServiceApplicationPool. This of course doesn’t exist in IIS and so the loading of this application pool for each web application will fail every time IIS starts up. This will result in a 5048 Warning from WAS within the System Event Log (for each Web Application):

Whilst this is just a warning, the consequences are pretty serious, as this application cannot start (it has no valid hosting application pool) it will be ignored and functions that rely on it will fail. Ooops!

Here you can see the mis-configuration in IIS:

For now the fix is simple, for each Web Application we can set the Application Pool correctly using Internet Services Manager (steps below) or APPCMD. We should expect this mis-configuration to be fixed in the future RTM of SharePoint 2010.

1. Right click the /_vti_bin/sts application within the Web Application
2. Click Manage Application
3. Click Advanced Settings…
4. In the General Settings section click the ellipses (…)
5. In the Select Application Pool dialog, select the correct application pool:
   (to determine which one to use run the following PowerShell Get-SPIisWebServiceApplicationPool | select Id, Name and use the GUID which corresponds to SecurityTokenServiceAppplicationPool)
   
   
6. Click OK twice
7. Repeat for all SharePoint Web Applications
8. Restart IIS (iisreset)

Don't be mad! This is a BETA!

Application Pool Manager v3 (for SharePoint 2010)

We are pleased to announce a new release of the popular Application Pool Manager. This version (v3) has been produced to support SharePoint 2010. We don’t have much in the way of fancy new features in this release, but we do have some good ideas for a future release around April and are always keen on other ideas we could incorporate.

The most important thing about this release is that it is targeted at SharePoint 2010 only. As such it only supports IIS7. This has allowed us to remove all of the legacy IIS6 code and the shims necessary to support both versions of the web server. This means (hopefully!) smaller and more efficient operation.

So just to be clear v3 runs on IIS 7 only (Windows Vista, Windows 7, Windows Server 2008 or R2). For SharePoint 2007 development, you should continue to run version 2, which of course also supports Windows Server 2003 (IIS6).

Version 3 supports the new “v14” version of the SharePoint services, and we have also included the ability to restart the User Code and Tracing services:

APM displays application pools using their SharePoint Display Names, rather than the actual names in IIS, for which SharePoint uses a GUID:

From the main settings dialog, there is also the ability to display a “mapping” of the SharePoint Display Name to the GUID used as the Name in IIS:

Hopefully you will find this new version useful in your SharePoint 2010 development, you can download the application over on the main APM Download page.

More on SharePoint 2010 Application Pools

Blimey! My recent post about worker processes generated a large number of follow up questions. Instead of answering all of these individually, this post will cover the details and perhaps be useful as a reference in the future.

Before I get started there is one thing which perhaps is obvious, but needs to be made clear: SharePoint 2010 is a beta release. It is always possible that things change come the final RTM release. That’s the point of a beta really!:)

I am going to assume the same setup characteristics from the example in the previous post.

What are the Application Pools that SharePoint 2010 creates?
This has been the most common question. My previous post deliberately ignored one and also skimmed over some details as well. Once we’ve installed SharePoint, run the Configuration Wizard and the Farm Configuration Wizard, we will have six Applications Pools in addition to those on the machine already. These are detailed below.

1. SharePoint Web Services Root
   Identity: LocalService
   Status: Stopped
   
   This guy hosts the SharePoint Web Services IIS Web Site and is on every machine in the farm. This is the host web site for Service Applications, it is analogous to the old “Office Web Services”. Service Applications WCFs are hosted in here as Applications which can (and should) be run in a different Application Pool. Whilst the IIS Web Site is important for bindings and other configuration, it’s absolutely OK that this Application Pool is stopped. If you try and browse the site, you will get a 503.
   
2. SharePoint Central Administration v4
   Identity: SharePoint Farm Account
   Status: Started
   
   This one is pretty straightforward. It’s responsible for Central Administration on the machines hosting it. It will include at least three applications (root, images, inc) plus an app for each Language Pack you have installed
   
3. SharePoint Web Services System (which is named with a GUID)
   Identity: SharePoint Farm Account
   Status: Started
   
   This guy hosts the Topology Service Application, which is known as the Application Discovery and Load Balancer Service Application.
    
4. SecurityTokenServiceApplicationPool (which is named with a GUID)
   Identity: SharePoint Farm Account
   Status: Started
   
   The guy hosts the Security Token Service Application, required internally even on a single server farm as well as for supporting inter-farm operations, and external Claims.
   
5. SharePoint Web Services Default (which is named with a GUID)
   Identity: SharePoint Services Account
   Status: Started
   
   This is the big daddy. It hosts all the other Service Applications. You will have as many applications in here as you do service applications deployed unless you configure their hosting manually.
   
6. SharePoint – 80
   Identity: SharePoint Services Account
   Status: Started
   
   This is the default application pool used to host end user Content Web Applications having used the Farm Configuration Wizard to get up and running quickly.

Should I stick with those, I should I do it “properly”? 
It’s Beta – so yes, you should really, unless you are looking at “advanced” farm topology and other design aspects. If you are a developer, step away from the console! Also, be patient and wait for the real RTM guidance. But the bottom line is the first four are required. You don’t want to be fiddling about with them. The last two are what the Farm Configuration Wizard produces and in a real world deployment you would certainly not create the last one, and you would probably change up the service apps one as well.

What is up with the crazy GUIDs?
Horrible aren’t they! An IIS Application Pool can have but one unique identifier, it’s Name, for which uniqueness is enforced. It works perfectly. However SharePoint has decided to use GUIDs for this Name. Within Central Administration the Application Pools are displayed using a SharePoint only property – Name, which is actually a Display Name (e.g. SharePoint Web Services Default).

Moreover, the GUIDs used are, wait for it, yes – unique. These aren't “well known GUIDs” like class ids. They will be different on every installation. It would appear the GUID love from SQL server has found it’s way into IIS thru the back door.

One hopes this will be changed in the future. In the meantime if you want to find out which App Pool in IIS is which App Pool in SharePoint (crazy I know!) without fiddling around in the Internet Services Manager, you can do so with the following PowerShell:

Get-SPIisWebServiceApplicationPool | select Id, Name

Does SharePoint 2010 still “manage” aspects of the Application Pools such a recycle times?
Yes. This is the same. Avoid fiddling with these settings (e.g. Regular Time Interval) there are a couple dodgy blog posts out there by people who should know better recommending you change these settings. Don’t! They are in there for a reason and besides the SPF Web Application Service is responsible for their management. There are some settings which are tweak able, but it’s way too early for guidance here, and besides such tweaks are only useful in production environments.

Hopefully this helps address the questions I have had in response to the earlier post. I’ll be posting more on SharePoint 2010 process isolation in the future.

Microsoft SharePoint Connections 2010, Amsterdam

I’m honoured to be one of the speakers at the upcoming SharePoint Connections 2010 event in Amsterdam, The Netherlands on the 18th and 19th January. It promises to be a great show with lots of great 2010 content and speakers. The general goal of the event is to deliver highlights from the SharePoint Conference earlier this year in Las Vegas to the European audience as well as offering significant networking opportunities. Its all going down at the RAI conference centre just outside Amsterdam city. The RAI isn’t a casino, but it is an excellent conference facility!

I will presenting the following sessions:

• MSC27: Claims Based Identity in SharePoint 2010
  You will learn about the major investments in Claims based Identity in SharePoint 2010. You will understand how to use SharePoint in an heterogeneous identity environment for both sign-in and services (SOA). We will discuss the new identity architecture, learn about all the components and how to manage and operate them. In addition, we will go over the design decisions you will need to make as you plan the interop between SharePoint and external systems/web services.
• MSC34: Implementing Multi-Lingual Solutions on SharePoint 2010
  This session will discuss key success strategies for building multilingual Internet, extranet or intranet sites leveraging Variations and the new Multi-lingual User Interface. Key topics covered include: 1. Core technical concepts 2. Planning considerations 3. Information architecture and site structure 4. Hierarchy creation 5. Variations logic 6. Navigation and Web Parts 7. Multi-lingual User Interface benefits.
• MSC12: Scaling SharePoint 2010 Topologies for Your Organization
  Now that you learned about the new SharePoint Service architecture, come learn about how you architect Services for your organization. We will talk about various Canonical SharePoint deployment types (Internet Presence, Partner Collaboration via Extranets, distributed/consolidated data centers, medium sized organization etc.) and describe how you architect the Services logical topology. In addition to the logical topology, we will drill into how you scale-up/scale-out the physical topology to meet the scale expectations for your organization. Regardless of the nature and scale of your organization, SharePoint 2010 now offers a topology for you!

Along with my partner in crime, “The Doc”, Neil Hodgkinson, I will also be delivering an all day post conference workshop for IT Pros on the 20th January.

• MPS01: SharePoint Server 2010 Administration Workshop
  Prepare yourself for the new world of SharePoint Server 2010 Administration! Come and spend a full day with SharePoint Certified Masters Spencer Harbar and Neil Hodgkinson as they cover the administration and operations fundamentals of SharePoint Server 2010. They’ll cover the gotchas of the install as well as potential pain points you might encounter when upgrading in your organization. After this workshop, you’ll have the key information you will need to install, upgrade, operate and manage SharePoint Server 2010 beta up and running in your organization.

There will also be a SharePint on the Monday evening to mingle with the SharePoint community, and also partake in some real beer. Yes, that’s right – real beer (made in Europe!) at a SharePoint event. Whatever next?! Check out the event site for more information and registration details.

SharePoint Server 2010 Worker Processes

Recently a number of people have asked about the number of worker processes which are alive on a new install of SharePoint Server 2010 and the associated other processes which amongst other things increase the resource requirements (primarily RAM) for running SharePoint 2010 over SharePoint 2007. This post will explain the core changes here and what you can expect to see following the installation and farm configuration.

As with SharePoint 2007, or any other .NET based web application for that matter, your implementation specifics will determine the number of and isolation and security characteristics of the processes running including those that are governed by IIS Application Pools. However SharePoint 2010 does make a number of key changes to be aware of to the partitioning of application pools and therefore their associated worker processes. These changes are not for the sake of it, but rather to lay the foundation for a more robust provisioning and “enterprise ready” platform as well as supporting new features in the product.

As mentioned above, the exact characteristics of your environment such as how you choose to deploy Web Applications and Service Applications will determine the application pools and worker processes on your machines. For the purposes of this explanation it is assumed that you have installed SharePoint Server 2010 on a single machine, and have used the SharePoint Configuration Wizard to create a farm, and the Farm Configuration Wizard to setup your Service Applications and initial Content Web Application. It is further assumed that you have used the default settings to provision all available Service Applications, but not the Office Web Applications.

For this type of setup we will make use of two Service Account Identities, as detailed below:

Once we have run the SharePoint Configuration Wizard to create the Farm, and run the Farm Configuration Wizard to provision our Service Applications, will we have the following Application Pools, which govern a single worker process each (Web Gardens are still not supported/recommended/sensible with SharePoint 2010).

1. SharePoint Central Administration v4
   Identity: SPFarm
2. The SharePoint Topology Service Application (the app pool name in IIS is a GUID, in SharePoint it is SharePoint Web Services System)
   Identity: SPFarm
3. The SharePoint Security Token Service Application (the app pool name in IIS is a GUID, in SharePoint it is SecurityTokenServiceApplicationPool)
   Identity: SPFarm
4. All the other SharePoint Service Applications (the app pool name in IIS is a GUID, in SharePoint it is SharePoint Web Services Default)
   Identity: SPServices
5. SharePoint – 80 (the “Default” Content Web Application created by the Farm Configuration Wizard)
   Identity: SPServices
   

The first three application pools can be considered core or Farm elements, and are present after the SharePoint Configuration Wizard is completed, whereas the last two can be considered Service elements which are present after the Farm Configuration Wizard is run. You can of course use the same account for both the Farm and Service elements, but you will still have five application pools. I strongly encourage that you use separate accounts and practice good platform hygiene. You will not gain performance improvements by using the same account.

In most cases, in a test rig type deployment and/or a development box, two of the above application pools will rarely be spun up, and this is why you will often only see three w3wp.exe worker processes in task manager. The Topology Service will only usually be alive when servers are being added to the farm, Service Applications are being grouped/created and/or Services on Server is being configured. Once you have setup your development box, it is highly likely you will never see this guy fire during normal operation. In a real world environment this is not the case as this guy also takes care of application discovery and “load balancing” of service application requests. The Security Token Service Application (STS) is more likely to fire as this is necessary for internal service interactions, but while the worker process is alive there often will be zero running requests.

So we have more (five) worker processes than we did in SharePoint 2007 (usually two). These all consume resources and contribute to the additional RAM requirements for SharePoint 2010. But this is a good thing! Functional decomposition of services is a primary tenant of distributed application architecture sadly all to often overlooked or ignored.

The Topology Service Application (aka Application Discovery and Load Balancer Service Application) being isolated will lead to faster and more reliable farm topology operations, especially in very large farms, and could also be considered a pre-requisite for multi-tenant scenarios. And the STS absolutely *has* to be isolated or it wouldn’t have any credibility whatsoever given it’s role!

I’m not a big fan (putting it mildly) of the way the Farm Configuration Wizard uses the account entered (SPServices in this example) as the Application Pool Identity for the Default Content Web Application, but the wizard is there to get deployments up and running quickly using lowest common denominator defaults. In the real world, on a real farm you are unlikely to be using this wizard at all. And this leads on to some other aspects of this default install/config that also impact the resource requirements for SharePoint 2010.

By configuring all the Service Applications by default you will have other processes running, the best example of which is the Web Analytics Service which will gobble up 90Mb even when it’s idle. In addition if you go ahead and also start some other SharePoint Services from Services on Server (e.g. the User Code Service, aka Sandbox) you will also get more processes (obviously). If you want good performance in RAM limited test/dev environments, especially in VMs don’t be starting Service Applications or SharePoint Services that you don’t need for the current task or project.

Hopefully the above adequately explains why we have more worker processes by default in SharePoint 2010. I’ll be covering more in depth details of process isolation, functional decomposition and farm topology over the coming months.

SharePoint 2010 pre-requisites installer and other setup refinements point the way to more consistent deployments

Small things can make a big difference. But what seems small and simple often isn’t. I personally wouldn’t want to be the guy who looks after the myriad pre-requisites for SharePoint Server 2010. :)

But SharePoint 2010 has a pre-requisite installer, just like SQL Server, and it’s good. In addition there are numerous other setup refinements which are a testament to a key drive of the latest version, enterprise readiness. It was promised and it’s been delivered. Sure, some improvement is always possible. The default name of a content database could use some work!:) Add that to a more robust set of system services and of course PowerShell, SharePoint 2010 seriously ups the game with respect to proven, repeatable and discrete deployments. Customers will have many less excuses to operate a badly configured platform.

But how can an installer bootstrap widget be such a big deal? Well dodgy deployments are costly to customers, partners and Microsoft. Fixing or operating dubious farms and configurations is a stranglehold on the ability for SharePoint to be adopted widely in large enterprises. The IT cost is too high. The vast majority of platform mis-configuration  is attributable to the actions taken within the first two months of a deployment. i.e. when the boxes were built.

But how can we tell if this is working, are we really decreasing the IT cost, and was it worth the effort as opposed to let’s say another feature investment?

Interestingly enough there is an early pointer to the likely success of these investments in platform hygiene. It’s very amusing to see the issues people are running into getting the new SharePoint 2010 Beta up and running. Twitter has amplified the amusement factor somewhat. But all comedy aside, last time around when Office SharePoint Server 2007 hit the public, it was way worse. The helter skelta of the release shades the fact that many more people have been successful in deploying, easily for the most part. And this isn’t because many more people are doing it than before, it’s obviously clear there is real improvement. Oh and by the way, TechNet seriously has it’s act together this time.

It really should be obvious to architects that platform hygiene is essential to be efficient and cut back on waste (IT cost). But winning that argument in a feature driven world is often a almost impossible task. Credit to those who fought for it and those that build it. Another benefit to these improvements is the increased ability to deploy and operate an “Agile Farm”. One that is extremely flexible and efficient. More on Agile Farms in the future.