Many small to medium-sized organizations start using SharePoint in a “two-tier” server farm topology.  The two tiers consist of:

1. Tier 1 – SharePoint Server with all web page serving and all Service Applications running on it
2. Tier 2 – A SQL Server to store the SharePoint databases – the SQL Server could be dedicated to the farm or it might be shared with other non-SharePoint applications.

Visually, this topology looks like this:

My experience is that this farm topology can frequently support companies with hundreds of employees.  Of course, it depends a lot on the specifications of the hardware, but with late-model quad-core Xeons running on the two servers and 8 – 16 GBs of RAM on each one with RAID built with 15k RPM SAS drives in the SQL Server, this configuration with SharePoint Server 2010 can perform very well in many organizations that have less than 1000 users.

At some point, an organization that started with this two-tier topology may want to scale out to the next level which is a three-tier topology.  The three tiers would be:

1. Tier 1 – SharePoint Server dedicated as a Web Front-End (WFE) with only the web application(s) and the search query service running on it
2. Tier 2 – SharePoint Server dedicated as an Application Server with all of the other service applications running on it, but no web applications or query service
3. Tier 3 – SQL Server for the databases

Visually, this topology looks like this:

There are many different reasons why a company might want to scale out to three-tiers from two.  Some kind of performance improvement is frequently what drives it.  However, it may not be the obvious one of desiring better page serving times for the end users.  For instance, I frequently see companies do this to move the search crawling and index building process to a different server that is more tuned for its unique resource requirements and can do a more efficient job of crawling and indexing the company’s content.  Perhaps in the two-tier approach their crawl\index component can’t get enough hardware resources to crawl through all of the content on a timely basis.

One more point.  Many organizations will also choose to add a second WFE when they scale out to a three-tier farm.  (I don’t show this in the diagram above).  The second WFE will be configured exactly like the first one and some type of network load balancing (NLB) mechanism will be put in front of the WFEs to intelligently route user traffic to the two servers to balance out the load.   In this scenario, the three-tier farm diagram above would be modified to add a second WFE and the total number of servers in the SharePoint farm would be four.

Getting From Here to There

Here is a screen shot of all of the service applications that run on the SharePoint 2010 server in a two-tier farm when you install SharePoint Server 2010 Enterprise edition and run the out-of-the-box Configure Your SharePoint Farm Wizard and choose to provision all service applications:

(2nd Reminder: for this post, I am working under the assumption that you have used the SharePoint 2010 “Configure your SharePoint Farm” wizard and have opted for it to provision all of the SharePoint Server 2010 **Enterprise Edition** service applications).

Your goal is to add a third server to the SharePoint 2010 farm and have it take over running all of the service applications in the list above, with the exception of the three that have been circled.  The three that have been circled in the screen shot are the ones that are necessary for the original server to function as a dedicated WFE with query processing. 

The Search Query and Site Settings Service and some of its associated functionality in the SharePoint Server Search Service are technically not required on a WFE, but it is the best place to put them.  The reason is that this is the process that takes the user’s search query and looks it up in the indexes.  The indexes are files that the query processor needs local access to and are stored on the file system of the server(s) that is running the query service, not in SQL Server. 

So, for best performance it is recommended to run the Search Query and Site Settings Service on the WFEs that are serving the pages.  The crawling and index process is a separate process whose job it is to build the indexes and push them up to the query servers.

The Search Topology configuration settings in SharePoint 2010 dictate what functionality of the SharePoint Server Search Service runs on what server in the farm.  So, while the SharePoint Server Search Service needs to run on both the WFE and the Application Server in this example, it will be possible break out the functionality that it performs on each.  We will want it to perform query-related functionality on the WFE and crawling/indexing functionality on the Application Server.  Later in this post I will show you how to do this.

Now, on to the actual steps to doing the work:

Step by Step: Scaling SharePoint 2010 to Three Tiers

Step 1 – Build a new SharePoint Server with exactly the same software

I’m talking about taking a fresh physical or virtual server that has Windows Server 2008 (R1 or R2) running on it, and installing all the same SharePoint Server 2010 software on it that is installed on the existing SharePoint 2010 server in your existing farm.  That includes the full RTM Enterprise edition, whatever patches have been applied in your farm since RTM, and any other separate products that have been installed on your existing server such as the Office 2010 Web Applications and its patches.

Step 2 – Run the SharePoint 2010 Products Configuration Wizard on the new server and join the existing farm

I recommend installing all RTM software and all patches that have previously been applied to the farm BEFORE running the SharePoint 2010 Products Configuration Wizard from the new server’s Start menu.  This means that you will want to respond NO to the prompt to automatically run the wizard until you have installed all software packages on the new server.  This will save you from having to run the wizard multiple times.  Run it once – after you have installed all software and patches on the new server.

When you do run the SharePoint 2010 Products Configuration Wizard, you will run it on the new server that will be your application server.  The wizard is going to help you join the server to the farm and get all of the software configured and running that you installed in Step 1.

Here are what the pages of the wizard look like as you go through the process:

Oops, you forgot to install a piece of software on this new server that is already installed on the other server.  The wizard has caught your error and is not going to let you proceed until you get this done.

Exit the wizard and go install the software – in this case, the Microsoft Office 2010 Web Apps.

OK, you got the missing software installed and have restarted the wizard.  The next screen asks you for the Farm PassPhrase.  This is a special password you created when you originally created the farm.  You have to enter it here in order to join this server to the farm:

If you click on Advanced Settings above, the next page asks whether or not you want to use this server to host the Central Administration website (sort of implying that you could move it from your existing SharePoint 2010 server to the new one). 

I haven’t tried selecting the second option in SharePoint 2010.  In MOSS 2007, according to this blog post you needed to remove the Central Administration web application from the original server before you got to this step on the new server. In the context of scaling out by adding an application server, that is probably what you would want do.  If you choose to go this route, just make sure you have good backups before you delete the Central Admin site from the existing server.

For this walkthrough, you are going to leave Central Administration on the existing server:

Now the server has been joined to the farm and is a full-fledged farm member.  But, the Configure Your SharePoint Farm Wizard in Central Administration needs to run to add the service applications that exist in the farm to this new server.  So, it automatically fires up your browser and asks you to run the Farm Configuration Wizard:

After you start the wizard, it will just run for a while without any input from you and return this page if everything was successful:

Step 3 – Verifying that everything is running properly on the new server

It’s a good idea at this point to go verify that the new server is showing up as a member of the farm with a healthy status.  To do that go to Central Administration > System Settings > Manage Servers In This Farm and find the new server and verify that it has a “No action required” status:

Take a moment to breathe deep and pat yourself on the back .  You have done a lot of work to get to this point.  You now have a three-tier SharePoint 2010 farm. 

But, there is more work to be done so that your three-tier farm has only the web page serving and query processing services running on the WFE and all of the other service applications running only on the Application Server.  Until you get that accomplished, the job is not done. 

(Note: the farm will work and be fully functional if you stop here.  You will have the same Service Applications running on multiple servers and SharePoint 2010 will automatically use this topology as a load balancing technique for the Service Applications.  There may be some environments where this is desired.  But, most organizations will want to separate the web-serving services and the application-serving services to provide a better balance for the farm as a whole as opposed to just load balancing the Service Applications.)

Step 4 – Re-configure the servers to run the services that are appropriate for their individual roles

You want the Web Front-End to run these (and only these) services:

1. Microsoft SharePoint Foundation Web Application (this is what turns IIS into a SharePoint “page-serving” machine)
2. Search Query and Site Settings Service (the process that takes the user’s query string and looks it up in the index)
3. SharePoint Server Search Service (but just the functionality that is necessary for the query processor)
4. Central Administration (assuming you didn’t decide to move it to the Application Server)

You want the Application Server to run these (and only these) services:

1. Access Database Service
2. Application Registry Service
3. Business Data Connectivity Service
4. Excel Calculation Services
5. Managed Metadata Web Service
6. Microsoft SharePoint Foundation Incoming E-mail
7. Microsoft SharePoint Foundation Workflow Timer Service
8. PerformancePoint Service
9. Secure Store Service
10. SharePoint Server Search (but just the scheduled content crawling and indexing building functionality)
11. User Profile Service
12. Visio Graphics Service
13. Web Analytics Data Processing Service
14. Web Analytics Web Service
15. Word Automation Services
16. Word Viewing Service

If you can get this done and everything works properly, you will have achieved your overall goal.

(Important Note: Step 1 above is really the only step in the process that can be done during normal working hours.  Everything else has the potential to impact the availability of the system to the users.  If everything goes smoothly, it is possible to do Step 2 through Step 4 in two to four hours.  Of course, it is highly recommended to have solid backups in place before starting Step 2.)

For the most part, the re-configuration of the services involves stopping a lot of services on the WFE server (using the Services on Server page in Central Admin) and verifying that they are running on the new server (which they probably are because the Configure Your SharePoint Farm wizard started them up when you ran it in Step 2).  Then, you will want to make one last pass over the list of services running on the Application Server and make sure that the Microsoft SharePoint Foundation Web Application Service and the Search Query and Site Settings are not running on it.

Adjusting the Search Application Topology

The exception to the statements of the previous paragraph is the search-related services:  SharePoint Server Search Service and Search Query and Site Settings Service.  Search is complicated enough that it has its own topology configuration settings.   You need to use this capability to place the query functionality of the SharePoint Server Search Service on the WFE and to place the crawling\indexing functionality of the service on the Application Server.

Since this is a little more complicated than the other Service Applications, go ahead and do this one first.

Navigate to the Search Administration home page in Central Administration.  Scroll down to the bottom of the page until you see the section titled Search Application Topology:

This part of the page shows you what servers the following four components of the Search service are running on:

• Search Administration component
• Crawling component (this is the crawling engine that crawls your content and builds full-text indexes from it)
• Database component (as the crawling engine crawls through the content, it stores the full-text indexes in SQL Server.  It also compiles the full-text indexes into special non-SQL files that can be propagated up to the WFE)
• Query component (this is the component that receives the user’s query and looks up the results in the special files that have been propagated to the hard drive of the WFE)

The Server Name column shows that the Search Administration, Crawl, and Query components are currently running on the existing server (SPS-INTRANET in the example).  The search-related databases are running on the SQL Server.

You want to do the following:

1. Move the Search Administration component to the new Application Server
2. Move the Crawl component to the new Application Server
3. Leave the Database component running on the SQL Server
4. Leave the Query component running on the WFE

To accomplish this, click on the Modify button to go to the Topology for Search Service Application page:

By hovering your mouse over the component lines, you can bring up a drop down menu and select Edit Properties for the components you want to move to the new server. 

Do this now for the Search Administration component:

Now do it the same way for the Crawl component (screen shot is the same as the one above).

Once you have changed the server assignments for these two components, you need to kick of the actual transfer of responsibilities by clicking on Apply Topology Changes:

The actual transfer of responsibilities begins:

When it is finished, you will be returned to the Search Administration home page and you should see that the components have been transferred as directed and all of the search-related servers should have a status of “Online”:

Note:  I am not sure why, but this page never shows anything in the Status column for the Databases component.  So, it is normal for that column to be blank for that component.

Transferring the remaining Service Applications

All that is left is to use the Services on Server page in Central Administration to make sure the list of services running on each server matches your master list from above:

You want the Web Front-End to run these (and only these) services:

1. Microsoft SharePoint Foundation Web Application (this is what turns IIS into a SharePoint page-serving machine)
2. Search Query and Site Settings Service (the process that takes the user’s query string and looks it up in the index)
3. SharePoint Server Search Service (only the functionality that is necessary for the query processor)
4. Central Administration (assuming you didn’t decide to move it to the Application Server)

You want the Application Server to run these (and only these) services:

1. Access Database Service
2. Application Registry Service
3. Business Data Connectivity Service
4. Excel Calculation Services
5. Managed Metadata Web Service
6. Microsoft SharePoint Foundation Incoming E-mail
7. Microsoft SharePoint Foundation Workflow Timer Service
8. PerformancePoint Service
9. Secure Store Service
10. SharePoint Server Search (only the scheduled content crawling and indexing building functionality)
11. User Profile Service
12. Visio Graphics Service
13. Web Analytics Data Processing Service
14. Web Analytics Web Service
15. Word Automation Services
16. Word Viewing Service

To do this, you use the Server drop-down control to select the server you want to adjust, and then use the Start/Stop link in the Action column to turn on/off the services.

Here is what your Services on Server page should look like once each has been properly adjusted fore each server:

For the Web Front-End (SPS-INTRANET in this example):

For the Application Server (SPS-APPSVR in this example):

If you navigate to the Servers in Farm page of Central Administration, you will see a more succinct view of your new farm topology:

Step 5 – Testing and Verifying

Even though you are ready to head out the door and head home since you are probably doing this on a night or weekend, it is really important to fight the urge to leave too soon.  You really need to do some basic testing and verification before you leave.  It will be a lot better to find out about any problems now rather than when the next business day has already started.

Here is what I recommend doing before you leave:

1. Browse to each of your SharePoint web applications and log in with your user account and make sure you can hit the home page of each of them.
2. While you are there, try to open up and edit a document in the browser using one of the Office 2010 Web Apps (Word, PowerPoint, Excel or OneNote).
3. Browse to your My Site and verify that everything is working normally.
4. Add a unique phrase to a test page somewhere in one of your Sites (I always use the phrase “jabborwocky” ) and then go run an incremental Search crawl from Central Administration.  After the crawl completes, go back to your Site Collection and search for the phrase.  Verify that it comes up in the results.
5. Run an incremental User Profile Synchronization from the User Profile Administration page.  While it is running, logon to the desktop of the new Application Server, and find this program and run it:  c:\program files\microsoft office servers\14.0\synchronization service\uishell\miisclient.exe.  This is the Forefront Identity Management (FIM) client application that you can use to see the details of the AD synchronization process.  Several jobs will be run by FIM.  Verify that they all complete successfully with no error messages.
6. In Central Administration, go into Manage Service Applications and click on Managed Metadata Service and select Manage in the ribbon.  Verify that the Term Store management interface loads and that you can add/change/delete a Term Set and some Terms.
7. Finally, reboot your WFE and Application Server.  When they come back up, check your Windows System and Application event logs on those servers and verify that there are no SharePoint-related critical or warning events that you haven’t seen before you scaled out to three tiers.
8. Browse to your primary web application one more time before you head out the door.

I hope this blog post is a good resource for those SharePoint Server Administrators who find themselves needing to scale out to the next level!

The problem:  Having to install SharePoint on a server OS has been a consistent cause of complaint for years within the SharePoint community, especially for developers.  The proliferation of virtualization technologies (such as the free Virtual PC and VMWare Server for client OS’s, and Virtual Server and Hyper-V for server OS’s) have helped to soothe the pain – but didn’t make it all better for many.  The picture has gotten more complicated with SharePoint 2010.  Now 64-bit hardware and operating systems are required for SharePoint 2010 all SKUS, which significantly narrows the options for desktop lab environments.  Hyper-V is the only Microsoft virtualization technology capable of running 64-bit guest machines, but it only runs on a Windows 2008 Server host machine. 

I have so far been running my Win2k8 SharePoint 2010 guest virtual servers on a spare desktop machine running Win2k8 with Hyper-V.  This is a more traditional development environment for SharePoint, and it is still nice from several perspectives.  1) I have snapshots to do the ‘I was never here’ trick easily if (when) I mess something up, 2) I can give the VMs more RAM than I could on my laptop, and 3) I can run more than one VM to simulate an actual farm.  However, it’s not a very portable environment.  It would be very handy as I travel to have a simple single-server farm that I could boot my laptop into wherever and whenever I felt the need. 

Even if your laptop or desktop is 64-bit, most of us probably aren’t running a server OS on it.  I did try using Windows 2008 Server as my laptop OS for a couple of months, but the performance load of Hyper-V and the SharePoint guest resource requirements caused a significantly slower environment than I was prepared to accept for my everyday use.  I know there are low-cost alternatives using VMWare’s free product, but that still would still have the duplicate host / guest resource issue.  I also wanted to see if it was practical to use Microsoft software because of my familiarity level with it. 

Two solutions:  There are two new developments (one in SharePoint 2010 and the other in Windows 7) that open some new doors to the desktop / laptop dev environment.  TechNet now documents that 1) SharePoint 2010 offers an option for installing on a client OS – at least for development use, and 2) that a pre-installed and configured vhd can be mounted as a secondary bootable drive on a Windows 7 PC.

In this post, I will document my experience mounting a pre-installed Win2k8 R2 server vhd as a bootable drive on my Windows 7, x64, 4gb RAM laptop.  In a previous post, I documented my experience installing SharePoint 2010 directly on Windows 7.

Now Windows 7 natively allows us to boot into vhd files instead of just the physical drive partitions.  That’s pretty significant and will probably have big implications for many admins and developers.  It is not as simple as installing SharePoint 2010 directly into Windows 7, but it has distinct advantages.  For instance, we can have multiple versions of the server stored as separate vhd files for different testing scenarios.  We can also make a temporary copy of any vhd file before booting into it to maintain kind of a quasi-snapshot capability.  It also offers me more of an ‘apples to apples’ comparison to a production farm (since it’s on a server OS) and allows me to use hardware on the PC that doesn’t work in HyperV – like wireless network cards, for instance.

Mounting a bootable vhd drive in Windows 7 – The nitty gritty

1. Log into your existing SharePoint virtual machine, and run the following sysprep command within the virtual server:
   c:\windows\system32\sysprep\sysprep.exe /generalize /shutdown
   
2. Once the sysprep command completes and the virtual machine shuts down, copy the server’s vhd file onto the physical drive of your PC.  Mine was copied to C:\VHD\2010AllinOne.vhd.
3. BCDEdit is a command-line utility new to Windows 7 that allows you to edit the Boot Configuration Data, including creating a boot menu for multiple operating systems or at least disks. 
   Open a command prompt with administrative privileges, and type bcdedit /enum.  This will print out to the screen the current setup of your Windows 7 bootloader, which probably has only a single boot option.
   
   
   You’ll notice that there is a Windows Boot Manager section, and currently only one Windows Boot Loader entry.  That’s about to change. 
4. Type the following command to create a new item in the boot menu named “2010 All In One” that we will use for our 2010 lab environment by copying the existing one:
   bcdedit /copy {current} /d “2010 All In 1”
       
   The /copy command created another boot menu entry and assigned it a new GUID.  (Every Windows Boot Loader entry has its own GUID, even though you have to look very closely to see the difference).  However, the new boot menu entry is not wired up to our VHD file.  So, we need to add another two related commands to tell the new menu entry where to point.  The GUID can be typed if you really want to, but I suggest copying it. 
5. If you right-click on the GUID in the last line output to the command prompt and choose Mark, then you can highlight the GUID with your mouse.  The ENTER key copies it to the clipboard.
   
   
   
   The following are the complete commands to type and paste into the command prompt.

   bcdedit /set {pasted guid} device vhd=[C:]\VHD\2010AllInOne.vhd
   bcdedit /set {pasted guid} osdevice vhd=[C:]\VHD\2010AllInOne.vhd
    

6. Finally, we need to force the new bootloader entry to auto-detect the VM’s Hardware Abstraction Layer.
    

The end result should be a dual-boot menu with a choice for Windows 7, your native OS, and 2010 All In One, your SharePoint lab VM.  In my case, I have SharePoint 2010 installed on both Windows 7 and Windows 2008 R2 – all running natively on my 64-bit HP laptop with 4 gb of RAM.  So far, things are working very well for me.

NOTES: 

• If you get a BSOD when you try to boot into the VHD, it’s probably because you didn’t use the Generalize option when you did the sysprep command.  (I, um, have ‘a friend’ that did that once…)
• This boot to vhd trick allegedly will work with a Windows Vista client OS too – with a little hacking.  I won’t go into it here, but Google “windows 7 vhd dual boot vista bootmgr bcdedit” and you’ll find several brave adventurers who can take you down that path if you wish.
• I worked under the assumption that many developers / admins would already have a test server built as a VM by the time they stumbled across this procedure.  So these instructions show how to repurpose an existing VM onto your client PC in a dual-boot scenario.  If you do not have an existing SharePoint 2010 vhd file, here’s a link to a TechNet blog post with a webcast that describes how to create the vhd dual-boot environment with nothing more than a blank hard drive, a Windows 7 DVD, a Windows 2008 R2 DVD, and a dream…
• You can use a dynamically-expanding vhd file, but it does something at boot time that may surprise you.  It automatically expands to its full size.  Interestingly, it contracts again to it’s smaller size when you shut it down.  That means you don’t have to maintain enough space for the full drive, but you do have to free up enough space for the entire drive before you try to boot into it.

The problem:  Having to install SharePoint on a server OS has been a consistent cause of complaint for years within the SharePoint community, especially for developers.  The proliferation of virtualization technologies (such as the free Virtual PC and VMWare Server for client OS’s, and Virtual Server and Hyper-V for server OS’s) have helped to soothe the pain – but didn’t make it all better for many.  The picture has gotten more complicated with SharePoint 2010.  Now 64-bit hardware and operating systems are required, which significantly narrows the options for desktop lab environments.  Hyper-V is the only Microsoft virtualization technology capable of running 64-bit guest machines, but it only runs on a Windows 2008 Server host machine.  Even if your laptop or desktop is 64-bit, most of us probably aren’t running a server OS on it.  I did try using Windows 2008 Server as my laptop OS for a couple of months, but the performance load of Hyper-V and the SharePoint guest resource requirements caused a significantly slower environment than I was prepared to accept for my everyday use.  I know there are possibilities for running 64-bit guest machines on a client host OS via VMWare, but I wanted to see if it was practical to use Microsoft software because of my familiarity level with it. 

Two solutions:  However, there are some new developments in SharePoint 2010 and Windows 7 that open some new doors to the desktop / laptop dev environment.  TechNet now documents that 1) SharePoint 2010 offers an option for installing on a client OS – at least for development use, and 2) that a pre-installed and configured vhd can be mounted as a secondary bootable drive on a Windows 7 PC.

In this post, I will document my experience installing SharePoint 2010 directly on my Windows 7, x64, 4gb RAM laptop while I’m home fighting the flu this week.  In another post, I will look at mounting a pre-installed Win2k8 server vhd as a bootable drive.

Installing SharePoint 2010 on a client OS – The nitty gritty

This is the simplest solution for creating a desktop lab environment for SharePoint 2010.  There is no longer a need for a virtualization product, which means fewer resources are needed with no guest OS to provide for.  Bamboo Solutions created a helpful utility for installing WSS 3.0 and MOSS2007 on Windows XP / Vista – so this is not a new idea.  However, this tool doesn’t work on SharePoint 2010.  Fortunately, there is a native (although not obvious) way to accomplish this in the 2010 product line that is documented in the first link above.  It basically boils down to editing a config file and manually installing the pre-reqs.  Here’s the procedure I followed.

****  UPDATED:  This is now confirmed to work for both MSS 2010 and SharePoint Foundation (the replacement for WSS) in the public beta released to MSDN on 11/16/2009.  However, step 4 below is now a necessary addition to the process.****

1. Extract all files from the SharePoint.exe installer file from which you intend to install SharePoint (for any other SharePoint 2010, the replacement for WSS, the filename will likely be OfficeServer.exe instead of SharePoint.exe).  This is done with the /extract:directoryname switch, as shown below.  This may prompt you with one of the wonderful UAC ‘are you sure’ boxes.  If so, just click Yes and move on.
    
2. The result will be a folder with the entire set of installation files for SharePoint 2010.  Go to ExtractedDirectoryName\Files\Setup, and open the Config.xml file using Notepad.
    
3. Insert a new line in the <Configuration> section, as shown below:
   <Setting ID=”AllowWindowsClientInstall” Value=”True” />
    
4. While you have the file open, change to the key in the PIDKEY Value entry from the ‘Please enter key…’ text to your actual MSS 2010 license key.
   (If you don’t do this, you will likely get an error message in step 12 below that says your ‘config.xml is not valid, run setup again without using a setup configuration file, or fix the configuration file’.)
   
5. Close and save the file.
6. Now we must install the prerequisites manually.  (The fancy new pre-req installer doesn’t work on a client OS.) 
   First, run all of the installer files found in the subfolders under the ExtractedDirectoryName\PrerequisiteInstallerFiles directory with the exception of the Speech and SpeechLPK folders (ChartControl (for Office Servers only), FilterPack, sqlncli, sync):
    
7. Download and install the Microsoft Geneva Framework Runtime for x64.
   (This is a tricky one.  Most of the downloads you find with Google are not the correct version for the public Beta, and the one you may have used with the SharePoint 2010 Technical Preview doesn’t work either.  If you don’t have the correct version, you won’t be able to complete the SharePoint 2010 Products Configuration Wizard in step 13 below.  The download available at the link above worked for me with the public Beta.  The key is to have the following DLL version in your c:\Windows\Assembly folder:  Microsoft.IdentityModel 1.0.0.0) 
   
8. Download and install the ADO.NET Data Services v1.5 (runtime only), or whatever is the most current version when you’re reading this.
9. Download and install the SQL Server Analysis Services – ADOMD.Net, or whatever is the most current version when you’re reading this.
10. Install the IIS pre-reqs by entering (or, lets be honest – copying and pasting) the following command without any line breaks:

    start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;
    IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;
    IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;
    IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-HealthAndDiagnostics;
    IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;
    IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;
    IIS-RequestFiltering;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;
    IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-IIS6ManagementCompatibility;
    IIS-Metabase;IIS-WMICompatibility;WAS-WindowsActivationService;WAS-ProcessModel;
    WAS-NetFxEnvironment;WAS-ConfigurationAPI;WCF-HTTP-Activation;
    WCF-NonHTTP-Activation
    

11. Restart your PC.
12. Run the SharePoint installer file setup.exe in the root of your ExtractedDirectoryName.

    (Microsoft recommends configuring only a ‘Stand-Alone’ SharePoint instance on Windows 7, but it will allow you to choose advanced and Complete in order to specify a SQL Server if you wish.)

13. When the installer finishes and you begin the ‘SharePoint Products and Technologies Configuration Wizard’, a popup will warn you that this use is not supported for production environments.  Click OK and proceed through the wizard.

NOTE:  If you need to install SharePoint in using the ‘Complete’ option to be able to use the full version of SQL Server, you will not be able to use a local user account in the config wizard.  This is possible with the New-SPConfigurationDatabase PowerShell cmdlet, though.  I’ll blog about using that cmdlet in a later post.

These are some notes from a helpful session today at the SharePoint Conference 2009 in Las Vegas delivered by Christophe Fiessinger and Jan Kalis from the Microsoft Project Server team.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish.

What exactly is Project Server 2010, anyway?  To put it as simply as possible, it is meant to provide project and portfolio management on a large scale.  That means collaboration, schedule and resource management, and reporting.

We got some good news and some bad news.  Project Server now requires the full version of SharePoint 2010, not just the free Foundation product.  However, out of the box, the Project 2010 Professional client program can sync with any SharePoint task list.  So, you may not always need Project Server to share and collaborate on projects and integrate with the full client.  Project Server includes the ribbon interface to simplify matters, and allows you to do much of the simple day-to-day entries and changes through the web interface.  The new enhancements in Excel Services, Performance Point Services, and other SharePoint reporting pieces provide excellent BI capabilities.

Project Server now functions as an add-on service application in SharePoint 2010.  There is therefore a lot of flexibility in farm topology, and it is now fully compatible with load-balancing and high-availability.  It no longer uses ActiveX, meaning you don’t have to touch desktops for upgrades and updates.

System Requirements:

• Same as SharePoint 2010, plus
• SharePoint 2010 Enterprise
• Project Professional 2007 / 2010
• Excel 2007 / 2010
• IE 7 or 8 (other browsers not supported)
• Exchange 2007 (optional, but server to server integration is now available)
• Team Foundation Server 2010 (optional, but it is now integrated OOTB too)

Deployment Process

1. OS / updates
2. SQL Server / updates
3. SharePoint Server 2010 (not included with Project Server anymore)
4. Project Server 2010
5. SharePoint Configuration Wizard and Farm Configuration Wizard
   (Minimum Service Applications:  Project Server, Excel Services, Performance Point Services, Secure Store Service, State Service (for charting))
6. Central Admin Configuration
7. Project Web Access Admin Configuration
   (Time reporting periods for time tracking, base security by roles, Cube Building Service, Exchange integration)

PowerShell is supported through the entire process.

Should SharePoint and Project be run in separate farms or separate?  Depends…

Together:

• Server consolidation
• Administration and maintenance
• Leverage high availability and line of business integration
• But, update testing is more complex
• SharePoint Admins need more training
• Additional licenses required if the farm is large (Project will require a license on every server in the farm)

Separate

• Isolated update requirements
• No dependency on intranet farm availability
• Change management is simpler
• Security isolation
• Can still share a SQL server
• But, additional administrative tasks
• Duplicate governance

Capacity planning will not be terribly different than the 2007 version, although the new service applications that are available may affect the performance if you enable them all.

Upgrading

Do not skip the normal, boring analysis of your existing environment.  Project Server is complex and needs to be tested.

Project Server 2003 needs to be migrated via 2007, although it does not have to be brought all the way to production.

Project Portfolio Server 2006 / 2007 has 3 options:

1. Map functionality, develop desired functionality on 2010, and then use the gateway to transfer the data.
2. Finish existing projects in PPS 2007, and start new projects in 2010.
3. Use side-by-side with Project Server 2010, syncing via the gateway.

Project Server 2007 is direct and streamlined OOTB, with two options:

1. In-place Upgrade (remember 64-bit is required for SharePoint 2010, though)
2. 4 or 5 Database Attach (the upgrade occurs during PWA provisioning)

Backward Compatibility Mode is automatically enabled in all cases after upgrade, which allows 2007 Project Pro SP2 clients to work seamlessly.  Project Pro 2003 or older clients are just out of luck.  Multiple client versions on the same PC are supported as long as they are not running at the same time.  Backward Compatibility Mode makes it possible to attack the server and client upgrades separately.  You should always do the server first, because the 2010 client will not work with the 2007 server product.  Once all clients are up to 2010, backward compatibility can be turned off so that full functionality becomes available.  Here’s what is suppressed in Backward Compatibility Mode:

• Manually scheduled tasks are not available on the server or client
• Tasks cannot be set to Inactive
• Font strikethrough not available
• All Departmental custom fields enforced on Project Professional 2007

The 2010 file format has changed, and older client versions will not be able to open the new files.  The only way to convert or use them is to download the Project Pro 2010 Trial product.  This is due to the fundamental changes the Manual Scheduling introduces into project plans.  Opening these files in prior versions would be confusing or misleading to 2007 users, even if a converter was provided.

These are some notes from a helpful session today at the SharePoint Conference 2009 in Las Vegas delivered by Srini and Burzhin (I typed too slowly to get their last names), product engineers from Microsoft.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish. In the interest of full-disclosure, this is a pretty new topic for me personally.  Therefore, it is possible that some of these notes represent things a bit differently than how the presenters intended.  The RBS team blog is available here: http://blogs.msdn.com/sqlrbs to find things in their own words.

BLOBs are Binary Large OBjects – a container of unstructured bytes of data.  SharePoint data that is not meta-data (documents – most other list items are completely meta-data) is stored in BLOBs in SQL databases.  BLOBs typically account for 60-70% of all content storage.  Most SharePoint operations act against the meta-data, not the BLOB data – until you go to click on the link and open the document.  By default, BLOB data is stored in the content database with the meta-data.

This model works well, but it does have some pain points.  SQL storage is inherently expensive, especially if it’s on a SAN.  The more data existing in SQL, the more performance load there to retrieve it.  Large data sets are slow to backup and recover.  SQL data is difficult to guarantee retention and deletion for compliance.  So…, Remote BLOB Storage (RBS) will solve all of our problems and bring about world peace by allowing us to store BLOB data outside of our content databases.

Previously with 2007, EBS (External BLOB Storage) meant that third-party providers were responsible for both managing external BLOB storage and creating the API libraries to interface with SharePoint.  The objective now is for SharePoint, itself to provide a common set of API libraries to do so.  The result is a downloadable add-in component that can be registered for a SharePoint farm via the SQL 2008 R2 Feature Pack (see below).  EBS is supported in 2010, but is deprecated.  Migration from EBS to RBS can be performed via PowerShell commands.

RBS is fully managed code, can be scoped to individual content databases (instead of at the farm level), can be configured and managed via PowerShell, supports many providers (including third-party), and supports migration both ways.  It ships with a native RBS FileStream store provider.

From the user’s perspective, SharePoint 2010 does all of the dancing transparently.  They’ll never know something is different.

From the administrator’s perspective, there are new PowerShell cmdlets that talk to the relevant SQL stored procedures for installing, configuring, provisioning, and maintaining RBS.

From the third-party provider view ,there is now no need to write the BLOB store libraries. 

Implementation

The RBS add-in must be installed first in SQL (the SQL RBS 2008 R2 with FILESTREAM Provider)

RBS and Provider DLLs must be installed on all WFEs

RBS must be enabled and configured using PowerShell:

• site.contentdatabases.rbssettings.enabled
• GetProviderNames
• SetActiveProvider (1 BLOB store to many content database)
• Migrate (copy entire BLOBs in or out of the db with no downtime)

Backup and Restore

This will by necessity be more complicated with multiple stores for SharePoint.  However, it is workable by following some simple restores.

1. Always start SQL backups first (the windows can overlap)
2. Always start BLOB restores first (the windows can overlap)

A longer BLOB retention policy can make it realistic to back it up less frequently than your SQL backups.  The RBS Maintainer keeps track of deletions and propagates them to the BLOB store.  Deletions don’t have to be concurrent from SharePoint to BLOB.  You should retain BLOBs long enough to allow you to restore the previous version of the content database without also restoring the BLOB store.

Performance

RBS seems to add little to no performance overhead in internal Microsoft testing with 128 users.  In fact, with larger files – it may have a slight advantage.  Third party providers may vary a bit, but are expected to cause no more than a 5 – 10% degradation and less for larger files.

These are some notes from a session today at the SharePoint Conference 2009 in Las Vegas delivered by Ryan McMinn, an Access Services guy at Microsoft.  It was nice to get more specific information about getting FBA to work, but it was also a little frustrating to not get much information about setting up SharePoint to trust external claims providers.  It’s touted as the best answer for partner collaboration, and I anticipate it to be a big winner for sites the interact with large numbers of individual contributors (think LiveID users), and earlier sessions pointed to this one as having all of the implementation details – but it seems like most of we get are concepts and generalities so far.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish. 

Design Considerations and Business Requirements

• Account Management
• Network Access and entry points
• Single Sign On
• Information Disclosure
• Antivirus
• Rich Client Experience

Target Audiences

Remote Employees – Need to use their internal identity.  Need access to Line of Business apps, collaboration, and publishing content.

Partners – Need to use both internal and / or external identities.  Need access to limited sites and data (no other partner data).

Vendors and Customers – Need to use external identity.  Need access to targeted and segmented content for collaboration and / or publishing content.

We must also think about zones and Alternate Access Mappings (or host named site collections).  The Default zone should be the most secure (SSL), because it is the fallback zone in case of problems

Authentication Issues

Claims Based Authentication can use Windows Integrated, Forms Based (ASP.Net or LDAP), or SAML.  When you create a web application, you pick between Windows Classic or Claims Based.  You can still use separate zones for different authentication methods.  However, if you choose Claims, then multi authentication can be used in the same zone (as long as they use the same protocol – HTTP or HTTPS).  This is much like what Outlook does with RPC over HTTP (using Windows Integrated when possible, and prompting when not).  The authentication page first asks which method you want to use for login.  This happens in the browser or in the rich Office clients.

There is not yet any documentation about how to configure the SharePoint STS to trust external claims providers such as LiveID or external federated domains.  The short version is that they must be installed into the store, and then PowerShell commands are used to register them for use.  Microsoft requests us not to go into production with Beta2 Claims Based functionality, but will provide instructions to test it there and wants us to do so.

There are some specific steps necessary to make FBA work in 2010.

1. Setup the authentication provider
2. Setup the web app to use the authentication provider
3. Add authentication provider to the web.config files of:
   • Central Admin
   • Web Application
   • STS

This can be done via PowerShell (if you are upgrading an existing web application you should do this BEFORE attaching the database for upgrade).

1. new-spauthenticationprovider –aspnetmembershipprovider “membership” –aspnetroleprovidername “rolemanager”
2. new-spwebapplication –name “my web app” –applicationpool “claims app pool” –applicationpoolaccount “domain\appool” –url http://servername –port 80 –authenticationprovider “membership”

ForeFront Unified Access Gateway 2010 (formerly IAG, Intelligent Application Gateway, which apparently is the yet again renamed replacement for ISA 2006) allows you to leverage existing servers without replication, a DMZ, or more servers.  It uses wizards to publish sites, do link translation, supports AAM, and path blocking.  It can also apply more specific rules (upload, download, edit…) based on identity, role, and endpoint device (corporate desktop vs. home PC).  It can also handle authentication with multiple directories and 2-factor tools, and provides excellent single-sign-on.

Forefront Identity Manager 2010 synchronizes identities and passwords across systems, automates user provisioning and management, and can be used to delegate this ability to partners.

Forefront Protection for SharePoint 2010 scans for viruses and malware, filters inappropriate content, and notifies administrators for infractions.

These are some notes from a REALLY great session today at the SharePoint Conference 2009 in Las Vegas delivered by Daniel Kogan, the Metadata Service Program Manager at Microsoft.  Lots of good, detailed information here.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish.

Our content types are now free to roam throughout the enterprise!  We also now get the ability to standardize and manage our meta-data tagging easily across different content types, usage scenarios, and storage locations.  Now, tags can be hierarchical just like your site or folder structure.  They can also be localized by language.

There are several questions we need to consider when we begin to contemplate this type of standardization.  They are similar concerns to what we had to consider when planning content types and site columns within a site collection, but obviously the issues can be far more complex when the scope increases across the enterprise.

Is it the same?

Does this have the same structure, policies, defaults everywhere in the enterprise?  Are things of content type “A” always the same?

What is it?

Do I trust it, recognize it?

Where is it?

Searching, navigating…

What happens to it?

Retention, workflow…

Terminology:

Hub – A site collection designated as a “souce” from which we share content types

CT Syndication – Publishing, sharing, pushing one or more content types across site collection, web app, and farm boundaries

Taxonomy – a hierarchical tree

Folksonomy – informal flat list of adhoc values

Term Store – DB that contains taxonomies

Groups – a security boundary within the term store and above the term set

Term set – a hierarchical section in the term store that contains many individual terms – e.g. Months, or Regions. (max 1000 total per store)

Term – a node in the taxomy with an ID and many text labels (30,000 per term set, max 1million total)

Tagging – applying metadata to an item (authoritative or social)

Keywords – not just a text string, a reference to a node in the hierarchical term store.  This is particularly powerful, standardizing tags for future use.  As you enter keywords, a suggestion list displays showing the entries in the hierarchy.

Content Type Syndication

• Each Metadata Service app can publish through a maximum of 1 hub
• It is not a requirement to syndicate or consume from the service
• Content Type with all corresponding columns, policies, and workflow association
• From the hub, you can publish, unpublish, republish, and roll up errors
• From the consuming side you can extend, derive, view errors, refresh from the hub

If you are working on the service in Central Admin, it is created with whatever name you like – configuring where the hub site collection is.  Then a connection service is used to consume from the original service.

If you are working in the hub, you can simply go to the Content Type gallery, click the type and choose to Manage publishing…  In the background, the Metadata Service creates a cab file that is versioned.  So the consuming web apps, site collections, and farms can check regularly for new versions of subscribed content types.

On the consuming side, it shows up like a normal content type – but it’s read-only.

Applying Metadata

Web Browser – Edit Properties, by a business process, location-based (inherit by virtue of where it is stored)

Rich Client – DIP, Backstage (Office menu > Info).  The Office client fetches the term set when it opens the document, so that recently added terms are available.

Once the meta-data has been entered using the term store, the column headings AND left-hand navigation displays the tag taxonomy as a means of filtering or pivoting the library listing.  If that doesn’t create a mental picture for you, it’s kind of like automatic, faceted, dynamic folder trees based on tags.

Managed Metadata columns are like a ‘super choice’ field that looks up in the hierarchical term store and filters exclusively or inclusively.  The user can even add entries to an ‘open term set’, while ‘closed term sets’ are owned by someone and closed to others.

Managed Keyword columns are like a ‘super text’ field where the user can type, and they are given suggestions from the term store.  If their entry doesn’t exist, the system will add it automatically.

The Term Store Management Tool

You find this at Home > Site Settings > Site Administration > Term Store Management

This tool allows you to access  all available term stores, to copy, reuse, merge, delete… individual terms.  Merges ripple through all the millions of documents that use them, and the two are now synonyms of each other (including any natural abbreviations).

These are some notes from a great session today at the SharePoint Conference 2009 in Las Vegas delivered by Sean Livingston, the Upgrade Program Manager at Microsoft.  Lots of good, detailed information here.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish.  Basic upgrade process and tools information was presented in part 1.  (My notes for that session are here.)

The Upgrade Team worked within a specific Upgrade Philosophy that included the following tenets:

• Detect issues early, both in O12 and at start of upgrade.
• Keep the administrators informed as to issues and next steps.
• No data loss.
• Minimize downtime
• Continue when possible (when errors are not fatal, log an error and move on)
• Be reentrant (prevent catastrophic failures that cause complete restoration)

Upgrade Sequence

Stage 1:  Boot strap

1. Config db
2. Admin content db
3. Pre-joined farm
4. Join farm

Stage 2:  Central Admin

1. Local farm
2. Admin web service
3. Admin web application
4. SPIISSite objects
5. Admin content db > Web Templates, Features Upgrade, SPSites

Stage 3:  User Data (performed by a Timer Job ASAP.  This prevents problems if the admin’s Terminal Server session times out and logs off.)

1. Local farm
2. SharedResourceProvider12 Objects > Partner stuff
3. ???? (didn’t type fast enough…)
4. Content databases > Web templates, Features upgrade, SPSites

Within these steps come many smaller actions.  Each of these are marked as successful when complete within the object schema.  If the upgrade is restarted, it resumes after the last successful action in each sequence.

The further you are from the current patch level, the longer the upgrade will take, because it has to perform those actions now.

Miscellaneous

• V2V upgrade DBs set to simple recovery to maximize performance (may not happen in Beta 2)
  So, don’t do any log shipping or mirroring during upgrade.
• DB growth during upgrade (2 to 3 times the normal size including the log)
  • Manually shrink database after upgrade
  • There will be a Health Rule that looks for DBs with large amounts of free space
• SQL timeouts are removed (if SQL server is still up)
• Version Path fallback logic (if dependencies are not in the 14 hive, look in the 12, if not there look in 60)
• Object locking has been reworked to allow multiple db upgrades to run concurrently without interfering with each other (checks for stale locks every 2 minutes)

Read-Only Content Databases allow you to upgrade a copy of the databases on the new farm while users access content.

• This is only for Content Databases
• Must be at least 2007 SP2
• SharePoint reads SQL database lock settings and proactively applies site collection locks so the users don’t see edit functionality in GUI
• If traffic is high, you may need to duplicate your SQL server for the upgrade to have enough resources

Parallel Upgrade used to be done via separate temporary farms.  Now it can be done in separate command windows on the same server.  Microsoft internal testing has found that a single true SQL server can handle up to about 8 concurrent upgrade threads.  If you’re doing it in a limited VM environment, it’s probably more like 2 or 3.

AAM Redirection can now be used with the Content DB Attach upgrade, but it should be seen as the approach of last resort.  This can only be as granular as your content databases are.  It is complex and requires URL changes which means link fixup will be needed and not all clients will understand the changes.

The planning process before you attempt an upgrade should include many things:

• Gather information
  • Pre-upgrade checker
  • WinDiff
    • New server with same version and patch level
    • Compare Web Server Extensions directory
    • Compare IIS directory
    • Compare GAC directory
• Determine impact (stsadm –o EnumAllWebs)
• House-cleaning
  • Stale sites and webs
  • Old document versions
  • Templates, features, and web parts
  • Repair data issues
    • stsadm –o database repair
    • stsadm –o deletelist
• Collect customizations
  • Gather original installation media
  • stsadm –o ExportIPFSAdminObjects
• Test the upgrade
  • Don’t ignore warnings and errors in logs
  • Use real datasets
  • Similar hardware
  • FBA will need to have some changes ALWAYS in your web.config files
    • For the web app
    • For Central Admin
    • For the Security Token Service
  • Make sure you test in both UI modes

Surprisingly, upgrade performance is more affected by number of sites, webs, lists… than it is by database size.  Hardware limitations are also key.

When the upgrade is finished, there are some manual things you will likely need to do.

• FBA configuration
• Unghosted pages
• Over wide lists (too many columns)
• Site templates and list templates will not come forward in the upgrade
  Instances built from the templates are fine, just the templates don’t upgrade.  You will need to recreate the templates (best practice is to do this as user solutions instead of .stp files)

If upgrade fails (hypothetically, of course), the following sequence is recommended for troubleshooting:

1. Go to status page
2. Go to error log
3. Go to full upgrade log (the correlation ID from the error screen is helpful to find the relevant log entries)
4. Test-SPContentDatabase
5. stsadm –o enumallwebs
6. Fix issues
7. Restart your upgrade

These are some notes from a great session today at the SharePoint Conference 2009 in Las Vegas delivered by Sean Livingston, the Upgrade Program Manager at Microsoft.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish.  There will be another session immediately following about advanced upgrade scenarios – so stay tuned.

Let’s start with some quick reference information:

Supported Scenarios

• In-Place
• Database Attach – Probably the most common to be used
• Single Click Install (Basic install w/ WID to SQL Express 2008)

Unsupported Scenarios

• Upgrade from earlier than WSS v2 SP2 / MOSS 2007 SP2
• Direct upgrade from WSS v2 / SPS 2003 or earlier
• Side by side installation
• Gradual upgrade (although AAM redirection is still possible, see next session)

There are several preparation tools that come bundled with 2007 SP2 (enhanced in October 2009 CU) to get you ready to upgrade:

• stsadm –o preupgradecheck (-localonly if you want to run against individual servers)
• stsadm –o EnumAllWebs (10/09 version includes features, event receivers, and web parts activated per web)
• SPDiag V2 (in the Admin Toolkit)
• stsadm –o ExportIPFSAdminObjects (for customizations like admin-approved InfoPath Form templates)

The preupgrade check looks for many things and reports on them.  This is done without editing the databases, and the operation is not required before upgrade – both of which are changes from the 2003 > 2007 prescan operation.

• Informational
• Farm servers and databases
• AAM Configuration
• Lists, Site Definitions (with instance counts), Features, Web Parts, Event Receivers to match up GUIDs and find missing elements
• FBA configuration (FBA will have to be reconfigured in 2010, think web.configs…)
• Installed Language Packs
• CAML views/CAML content types
• Issues
• Missing Site Definitions, Features, Assemblies
• Data orphans
• Modified content databases

There are also some new tools available in 2010 to help from the new server:

Test-SPContentDatabase

• Complements the pre-upgrade check
• Compares against a specific web application to look for missing dependencies
• Scans both 12 and 14 databases

Upgrade-SPContentDatabase

• Will resume an upgrade process (B2B or V2V) already in progress
• This DOES NOT attach a database (contrary to the Beta review document distributed in hard-copy at the conference)
• Attaching is done by stsadm –o addcontentdb, or
• Mount-SPContentDatabase (NOTE: Until RTM, this one will force the UI upgrade to 14)
• Upgrade-SPEnterpriseSearchServiceApplication

The new Visual Upgrade Capability by default upgrades using the old Office 12 UI.  It does this by including all of the old master pages and CSS sheets in the new version.  Admins / Owners are then able to do a temporary preview of the new UI, and / or do a final UI upgrade to the new look and feel.

• Farm admin or site collection admin controlled
• Web level setting
• Preview mode is not meant for extensive changes
• Web parts can now be UI version aware to make them automatically render differently per instance
• Some items are not O12 compatible
• MySite host
• Project Web Access site collection
• Report Server web parts

Patch Management has been overhauled, basically because it stunk in many ways in 2007.  2010 now has:

• A new UI
• A new PowerShell cmdlet
• New Health Rules
• Backwards compatibility mode
• Binaries can be ahead of the database(s)
• Defer upgrade for short period of time
• Not intended for long delay (maybe weeks or days)

There are multiple downtime mitigation techniques that can be used to minimize the effect of the upgrade process on end users.  Some of these are valid for both 2007 and 2010, and others are only in 2010:

Both

• Read-only databases (kind of, the UI just trims all of the edit functionality)
• Parallel upgrade farms
• Gradual Upgrade

2010 only

• Single server, multiple db upgrade sessions (works consistently well up to 2 sessions on the same disk spindle, for more you will need to test)
• Content database with AAM redirection

Upgrade logging has also been improved to help us trouble-shoot potential errors and warnings.

• One upgrade log per session
• Errors only log
• Predictable structure for log
• Improved status page
• New history page
• Command line progress indication

Shared Service Providers each get upgraded into separate service applications, and new databases are created as needed.

These are some notes from a conceptual session today at the SharePoint Conference 2009 in Las Vegas delivered by Venke Veeraraghavan from Microsoft.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish.  There is a later session that focuses on implementation details, so there will be more specific notes to follow.

Claims Based Identity is similar to Kerberos in many respects, but it extends similar benefits (and more) to non-Windows accounts.  It involves a trusted authority issuing a token (like a ticket) to a user as they log in.  This token can then be used to authorize access to whatever other system trusts the same authority.  From a SharePoint perspective, it is basically a way to offload / delegate the management of user accounts, profiles, and authentication for your portal users to a third-party.  It is a not a replacement for FBA, but a framework under which FBA can be one of the methods used to authenticate and authorize users.  Since Claims Based Identity is a flexible, framework based on standard SAML tokens – SharePoint doesn’t have to write compatibility with external protocols or identity providers. 

SharePoint 2010 is also now able to assign access permissions based on claims (roughly parallel to attributes) as read from the token.  That’s a lot more flexibility than we used to have.  It seems similar to what we found when working with the Audience Targeting features in 2007, where we could dynamically filter items based on profile properties.  Those prior features were not truly for security – just filtering.  Now, claims allow us to apply actual permissions based on similar criteria instead of strictly using users and groups.

Office client applications are now also able to support non-Windows Integrated Authentication.

There are 2 Important Identity Problems in SharePoint

Sign-In

There are 2 modes for authentication in SharePoint 2010:

• Classic (NT Token) or
• Claims (NT Token | FBA, SAL, LDAP… | SAML Token)

Claims creates a SAML token based on the sign-in, that contains the user’s identity

An IP-STS (Identity Provider Security Token Service) processes logins and manages attributes.  It creates a token and passes it to the user for them to present to the SharePoint STS.

The SharePoint STS (Security Token Service) verifies that the IP-STS creating the token (or FBA login) is trusted by SharePoint as configured by the farm administrators.  It then issues its own token incorporating the identity information from the first, and also adds whatever SharePoint-specific attributes might be necessary or desired.

Services

How do we use the identity outside of SharePoint?

• LOB systems
• External partner services
• Separate SharePoint farms

Claims allow us to accomplish more portability than Kerberos does.  Especially now with the Service Application Architecture, this enables much easier and more efficient ways to share services granularly across farms.  The SharePoint STS runs on every WFE and App server, and examines / trusts the STS on other servers as configured.

Other notes

In Beta2, Claims will be partially supported.  Here’s the list of what IS included:

• Windows-Classic
• FBA-Claims
• Anonymous
• FBA-Claims + Anonymous

The following modes will NOT be ready yet:

• Windows Claims
• SAML-Claims

These modes should be included in the RTM version.