Planning for SharePoint 2010

Below is a plan-in-progress of a WSS 3 to SharePoint Foundation 2010 upgrade process.

The architecture of our SharePoint farm has been in flux.  Hopefully the current plan is looking something like the final version…

Instead of Windows SharePoint Services 4.0, we
are getting “SharePoint Foundation 2010”. I am on the
fence about the product re-branding, not that my opinion matters

The Search Server that was built on top of WSS 3
(Search Server 2008 Express) keeps its name, becoming “Search
Server 2010 Express”.

Proposed architecture:

  • two Web Front End (WFE) servers, running Search Server 2010 Express with Office Web Apps.  Web Apps service applications will run all Web Font Ends.
    • SharePoint will be exteneded to one IIS web site
    • The Web Application will be in “classic” mode (not bloody claims!)
    • Windows authentication will be be primary authentication method (Kerberos disabled)
    • Basic auth will be supported for clients that cannot support Windows authentication.
    • One WFE will host SharePoint Foundation Search services (for indexing of help contents)(still needed?)
    • Both WFE systems will serve as backup query servers for the SP Search Service.
    • Should we add “search center” on a separate web application?
  • One Search Server Express host.
    • This system will run the Search Crawler service, as well as serve as the primary query/index server.
    • Note that Express cannot scale out to include additional query/index servers.  We will need to upgrade to the full Office Search Server or SharePoint 2010 Standard to scale out.  Search queries will not be fault tollerant.
    • We plan for this system to include SharePoint and file server results in Windows 7 desktop search results, as well as add additional crawl stores without killing the WFE systems.
    • This server cannot participate in the SharePoint Foundation Farm, per license requirement of Search Server Express.  It would be considerably easier to have the Search Server be a non-WFE server in the farm, but attempting this generates license errors and prevents search from working at all.
  • Re-use our existing SQL Server 2008 R2 mirrored servers, currently hosting the WSS 3 environment.
    • Question – should we move our blob data out of the content databases using the SQL File Stream provider at this time?
    • -or- should we be considering use of a third-party product such as “StorePoint” to handle blobs?
  • f5 load balancers on the front end, using a Layer 4 / Direct Source Routing config (SSL terminates at the WFE servers, not the F5, return packets go directly to the client)
    • This may change if we decide we need to extend SharePoint to multiple IIS sites and route based on browser “user agent” or source IP.

A proposed upgrade process:

  • Deploy new Server 2008 R2 systems
  • Install VMware Tools, Windows Updates, local utilities
  • Install a MS Loopback Adapter on each WFE.
    • Configure the adapter to host the primary SharePoint ip address, but use a 32-bit netmask (
    • Use NetSH to enable forwarding of sharepoint traffic to the loopback adapter
  • Run the stsadm pre-upgrade check on the production server… fix any errors (see my separate blog post on this topic…)
  • Install SharePoint Foundation 2010:
    • Run the prerequisite installer.  It may be necessary to run the prereq checker/installer more than once.
    • Download SharePoint Foundation, Office Web Apps, SharePoint Foundation 2010 SP1, Office WebApps 2010 SP1, and the latest Cumulative Update for SharePoint Foundation 2010 and Web Apps and/or the full Office Cumulative Update package (October 2011, at the time of this post).
    • Extract the SPF installer using the “/extract” switch on the downloaded installation package.
    • Extract all service packs and cumulative updates into the “Updates” folder of the SPF installer.
      • I found it necessary to compare the contents of the Office/SPF/WebApps Cumulative Update download packages to ensure that I had all of the update packages required for my server.  Time consuming!
    • Run the SPF installer
  • Configure SPF 2010:
    • Run the SharePoint Products Configuration Wizard
    • Set up service accounts for SharePoint processes: (Note that
      each service account must have “read” rights assigned
      to “Authenticated Users” in ADUC.  This really
      is necessary, at least for both the “access” and “service” accounts, even after SP1!)
    • SharePoint Search Service
    • Tracing: Tracing is a new option… we may want to enable
      tracing for the farm with a central trace file storage
      location, but not at this time
    • Mobile browser configuration:
      We have noticed some problems displaying Office Web Apps in current Android browsers (Android 3.0-4.0 releases), so we need to force the native Android browser to render SharePoint using the “mobile” interface.  This is easily accomplished by editing the “compat.browsers” file in: “c:inetpubwwwrootwssVirtualDirectories[sharepointSiteDirectory]App_Browsers”.  We locate the XML stanza for the browser id=”AndroidSafari”, then comment out: “”.  This will cause all Android native browsers to render the mobile interface, not just the ones identifying that they are “mobile” (i.e. Tablets as well as Smart Phones).
    • Central Administration|Outgoing Email Settings
      • Set Outgoing email “from” and server info for
    • Central Administration|Diagnostic Logging
      • Need to determine appropriate settings.
    • Central Administration|Configure usage and health data collection
      • Configured automatically, and now sends collected data to SQL.
      • We should tune it down from the default of “log everything” after shaking out the initial bugs.
    • Central Administration|Edit Authentication (Central
      Admin->Security->Specify Authentication Providers)

      • Select each applicable zone, then:
      • Enable anonymous access
    • Application Management|Web Applications|General

      • Set time zone
      • Define 5Gb default quota, assign it as the default.
      • Blog API – allow authentication???
      • Set maximum file upload size
        • IIS also needs to be configured to allow uploads of the size listed here.
    • Application Management|Web Applications|General
      Settings|Outgoing Email

      • Add server name and from address.
    • Application Management|Web Applications|Self-Service Site

      • Enable and require secondary admin
    • Application Management|Web Applications|Blocked File Types
    • Update per exceptions made for v3.
    • Application Management|Web Applications|User Policy
      • Add “admin” rights to our admin groups,
        “read” rights to our “read” groups.
    • Application Management|Web Applications|Anonymous Policy
      • Should we be denying Anonymous Write by policy? If so, what are
        the implications for Anonymous surveys?
    • Central Administration|Alternate Access Mappings
      • Set public URL for the server.
    • Search Server
    • FeedReader (from Smiling Goat) – still needed?
    • Old application templates from “Fab 40”…
      what to do with these?
    • Configure max WebDAV upload size in IIS.  Under Server 2008 R2 and SPF 2010 SP1, it appears that this gets set automatically.  Hurray!  The Doc I used for WSS 3:
      And some newer references:
  • Attach copy of production database:
    • Must use:stsadm -o addcontentdb
      -databasename [name] -databaseserver [server]
      (as you cannot attach an older version of a SharePoint database
      though the Central Admin web interface.)
    • Wait… wait… wait.
    • And we now have a mostly-functional version of our SharePoint farm running on 2010 infrastructure.
  • Force Visual Upgrade of Sites:
    • $webapp = Get-SPWebApplication http://sitename
      foreach ($s in $webapp.sites) {$s.VisualUpgradeWebs() }
  • Assign rights to the content database to the service account that runs the Office WebApps  service application pool.  For us, this is named “Service Application Poll – SharePoint Web Services Default”
    • I am not sure exactly how much permission needs to be granted to the service account.  “DBO” works, certainly.  Read-only likely would be adequate.
  • Convert existing external user accounts to use the new guest domain, using PowerShell.  I need to do more research on this, some thoughts below…  Note that “move-spuser” seems to update user info for all profiles in SharePoint, but that user display names appear to be site-collection (or perhaps even web site) specific.  So, as long as we can ennumerate all sharepoint users, move-spuser will take care of all login names.  However, display names will have to be updated per-site.
    • create an array that maps existing external users to new guest users use, then
      get an array of all sites:
      $sites = get-spsite -limit all
      we will need to loop though all sites to get their “webs”
      $u = get-spuser -identity $olduser -web
      to grab a user. Then for that user, use:
      move-spuser -Identity $u -NewAlias “GUESTusername” -IgnoreSID -Confirm:$false
      to update the username.  Use:
      $u.Name = “New Display Name”
      followed by:
      to update the users Display name as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s