Preliminary Results from the MOSSPit User Survey

So here are a couple of preliminary results from the MOSSPit (Utah’s SharePoint User Group)…  I found these quite interesting!

The two largest audiences are definitely the Developer (#1) and the Farm Administrator (#2).

Again, Development appears to be one of the biggest interests within the User Group.  Additionally, SharePoint Designer (#2) and Web Services (#3) were of high interest.  In 4th place there was a 4-way tie between Automation and Scripting, InfoPath Forms, Security, and SQL Server Reporting Services.  Overall, there was a fair amount of interest across the board on most topics, however.

If you are in the Utah area, and want to participate in the MOSSPit Survey, check it out and let us know what you think!

April MOSS Pit Presentation...

We had a great presentation last month from Doug Davis, the Product Director for SharePoint at Quest Software at the Utah SharePoint Users Group. He utilized a slide Deck of some infamy that Joel Oleson has presented numberous times. You can get a copy of it from the MOSSPit.

This upcomming month we will be fortunate enough to hear from Ryan Day, of IHC. Ryan will be showing us how to do some pretty cool stuff with the "out-of-the-box" SharePoint Web Parts. There will also be food and great give-aways! Don't miss it!

MOSS Pit (Utah SPUG) Workflow Presentation

Adam recently got us an updated copy of the presentation he gave last month for the MOSS Pit, the Utah SharePoint User Group.  You can get a copy of it here. 

He also sent in a great write up on the presentation he gave with Screenshots and he detailed what went wrong at the end of the presentation, and how to avoid it yourselves!  Check out a copy here.

Thanx Adam!

MOSSPit Branding Presentation

Today I presented at the Salt Lake City SharePoint User Group on SharePoint Branding... I've included my slide deck, and some of my speaking notes in the slides here, if you'd like a copy.

The 4 categories hit upon (high level, with a few specific examples) were Out-of-Box Styling, Theme Modifications, CSS Override, and Custom Master pages and CSS.

Thanx to the whole MOSSPit crew for pulling together the meeting, and supporting this communitee effort!

Excel Services and Web Gardens

I haven't seen too much on this, and it caused me some pain, so I thought I'd share...  We use very large Web Servers (24GB) with Web Gardens to utilize all that memory. 

The problem comes in with Shared Services.  Most Shared Services operate perfectly fine in a Web Garden.  Excel Services, specifically with Charting, is an exception.  For some reason, perhaps performance related, ECS will generate Charts using two separate requests to the Shared Services, one for the workbook, on for the Chart Image. 

The problem is that when sending in the second request, more likely than not you will get a difference process thread in the Web Garden than your original request.  This creates a disconnect, as they are not separate autonomous requests, but are linked.

The result is a wonderful ECS error on your page that says "Failed to Download Excel Services Chart".  This is backed up by MOSS log files that indicate that a "SOAP exception occurred" during "ExceuteWebMethod" in GetImage.  The actual error will show as a session timeout (because of inactivity).

The fix is simple.  Shared Services cannot have multiple threads.  You can set this in the properties of the Application Pool.  Just go to your IIS manager (on each WFE server) and right-click the Application Pool for Shared Services.  On the Performance Tab, change the Threads value back to "1".  No more Web Garden for Shared Services.  You can Web Garden your Content Web Apps without and surprises, just not your Shared Services.

You can see the full Log entries in this Discussion Board...

Automated Farm Installations, part 3

So here is the last installment in this series, the Extra's...  In Part 1 we installed the product and did the base configuration... In Part 2 we configured the SharePoint Server Shared Services and got rid of that annoying Red warning test on the Central Admin Site.  In this installment, we are going to look at above and beyond functions, like:

• Creating additional Web Apps
• Enabling Self-Service Creation
• Alternate Access Mappings
• Managed Paths
• Installing Features and/or WebPart Packs
• Attaching Content DBs

Creating additional Web Apps is very simple.  We use the same command we used earlier, ExtendVS.  This is valuable in many places.  For a new farm, you can have it create your root web as well, although this is generally something I recommend against.  The reason is that configuring your Web Application Creation Scripts without the Root Web prepares your script for Disaster Recovery in the future. 

If you have existing content and are using your install scripts to recover, you must make sure that you do NOT create the root web... Doing so will prevent the ability to recover your original root web via attaching Content DBs.  I use this as a standard, and manually create the Site Collections (either via GUI or STSADM Script with CreateSite or CreateSiteInNewDb).

Again, if you are preparing your script for DR, I recommend creating the Web App with a dummy Content DB, and adding a command to remove that DB at the end of the script, after your attach DB command(s).  If you want to remove that DB manually, make sure you add a comment at the end of your DR script to remind yourself, or you may be in for a surprise a few days after a DR recovery!

Self-Service Creation is for "team" or self-provisioned environments, and is enabled using the EnableSSC command: 

stsadm -o enablessc -url http://sharepoint.domainname.pri:80

This is handy to enable automatically on setup, but for DR purposes, you have to remember that this cannot be enabled unless the root web exists.  If recovering Content DBs, you need to create the Web App with no Root Web, Reconnect the Content DB(s), and then enable SSC, once the Root Web is online again.

As you setup your Web Applications, it is good to configure any Alternate Access Mappings you may need (ie, Extranet, Intranet, etc.)  The AAM can be configured per Web App by script using the AddAlternateDomain command, which looks a bit like this:

stsadm -o addalternatedomain -url http://sharepoint.domainname.pri:80 -incomingurl http://intranet:80 -urlzone intranet

Which would allow your SharePoint site to respond to http://intranet as well as http://sharepoint.domainname.pri.  This does not do anything for name resolution though.  All DNS/NetBIOS resolution is still up to you to configure on your network, this just allows SharePoint to respond to it when it reaches your servers.  A number of different "urlzone" parameters can be used here, including intranet, internet, and extranet.

In the same vein, configuring the Managed Paths of a Web App are also important.  Including all Wildcard Inclusions or Explicit Exclusions will save you time and heartache, especially in the case of minimal documentation.   Reattaching a Content DB with a Site that lives on a Managed Path that is not configured will not appear accessible until the path has been added to the Web App.  I strongly recommend making each Managed Path change by script (rather than manual) and adding that to your master DR script as your first form of documentation.  Additional environmental documentation is definitely desirable, however, if you are religious about your inclusion of all farm configuration changes to your DR script, you now have enough to get by.

Managed Paths are modified using the "AddPath" command.  It looks something like this:

stsadm -o addpath -url http://sharepoint.domainname.pri:80/project -type wildcardinclusion

Also make sure to remove the "sites" wildcard inclusion if you don't normally use it, or you will find they sprout up quickly in an SSC environment.

With all the Web Apps created and configured, you are almost ready to attach Content DBs.  Before doing that, you should install any solutions required by your farm.  Installing solutions (and deploying them) is something that, like Managed Paths, should always be carefully documented.  I include all custom code (non-OOB software) in this category.  If there is a Feature-set that is a commercial product with a full installer, I put a set of comments detailing what versions and service packs of that product are installed, with an echo line to remind the script-runner that there is additional activities required at that point.  If it is required prior to the content being restored (or earlier in the process), I recommend inserting the echo statement with a pause.  The ideal would be a silent install option scripted right in, but that is not always possible.

For those third-party and home-grown Feature-sets that are compiled in to SharePoint Solutions, you can install them with the "AddSolution" command, and deploy them with the "DeploySolution" command:

stsadm -o addsolution -filename MyCustomFeature.wsp

stsadm -o deploysolution -name MyCustomFeature.wsp -url http://sharepoint.domainname.pri:80 -force -immediate

Lastly, attach your Content DBs to your farm again using the "AddContentDb" command.  I strongly recommend issuing an IISReset command prior to this to make sure all changes have taken affect.  the Command is formatted like this:

stsadm -o addcontentdb -url http://sharepoint.domainname.pri:80 -databasename WSS_Portal_Content_01 -databaseserver DBServerName\NamedInstance -sitewarning 50 -sitemax 70

This can also be used to deploy schema changes with less farm disruption for larger farms... When deploying schema change patches and service packs, the first node must finish updating the entire farm before things come back online.  This can take hours for larger databases, even on big hardware.  To minimize this impact, the DB's can be removed from the Web App, taking all the sites offline, then the patches can be applied, then the DB's can be re-attached.  this updates the schema in the Content DBs one at a time, bringing each online and accessible after it has finished the update.  Although the total time is about the same, the downtime for the farm is less, as you can selectively bring the most critical data online first and roll-through the DBs in a business-criticality order.

Well, this does it for the automated installation series... Hopefully your gotten something useful out of it, as I did while learning about this process.  If you want to automate the process of making these scripts, take a look at the CodePlex project I've been working on for this... It is still in an Alpha state, but try it out and see what you think:

NSOT SharePoint Office Server Installation Script Generator

Automated Farm Installations, part 2

In part 1 I went over some of the basics of why an automated installation is a good idea for not only Development and testing labs, but for QA/Staging environments and even Production.

Part 1 detailed the initial steps in creating a farm, including the scripted installation of the product (copying the binaries) and initial configuration (setting up the farm).  In this section, I'm going to talk about the different steps required to finish the installation, or the user configuration.  These are the parts of the farm setup that are not done by the wizard if you install SharePoint manually, but are required to "complete" your installation.

One of the things that always seems to annoy developers is that nagging message on the Central Admin page that says in Red "Your Farm is not configured properly!" (I think it is actually stated nicer, but I haven't seen it for a while).  These are the steps that are required to make that go away, and "complete" the installation of MOSS.

Indexing/Search - You must configure the Index Server options so you have both the crawl and query functions active in the farm.

Shared Service Provider(s) - you must install and configure at least 1 Shared Service Provider.  This is the service mechanism used by MOSS to provide User Profiles, Indexing, and other Shared Services, such as BDC, Excel Calculation Services, Forms Server, and Web Rendering. 

Outbound SMTP Server - you must configure the Outbound mail SMTP address for the farm so it knows how to communicate with users and admins.

Excel Calculation Services - You have to enable the ECS role on at least one server in the farm.  This allows Excel sheets to be web-rendered.

1st: Required steps to configure Index Server

The Index server is made up of two services, the WSS Search Service, which searches help content, and the MS Office SharePoint Server Search service, which searches user content and other sources.  These can be configured with simple STSADM commands.

First, configure the Windows SharePoint Services Indexing Service.  This needs to be done on the server that will hold this role.  This is done with the STSADM SPSearch command:

stsadm -o spsearch -action start -farmserviceaccount domain\searchaccount -farmservicepassword Password

The parameters mean the following:

-action start: gives the directive to start the indexing on this server.

-farmserviceaccount and -farmservicepassword: The identity and password for searching.  This does not have to be your Farm Admin account.

Second, configure the Office SharePoint Server Indexing Service using the STSADM OSearch command, again, on the server that will hold this role, like this:

stsadm -o osearch -action start -role indexquery -farmcontactemail admin@SharePoint.pri -farmserviceaccount domain\searchaccount -farmservicepassword Password -defaultindexlocation d:\index

And the parameter descriptions:

-action start: again, the action tells the service that this farm member will be starting this role.

-role x: The role is what part of the search functions will be running on this machine.  you can specify index, query, or indexquery for both roles.  For those unfamiliar with this terminology, indexing is the crawling portion of the search role, that will search web pages and create indexes to be searched.  Querying is the user-request side of the index service, the side that handles all search requests from a user and provides a list of results.  My example shows both roles being assigned, however you can separate these by using this command on multiple servers in the farm with the role specified.  An example might be to make all your load balanced Web Front End (WFE) servers Query servers, to handle user requests.

-farmcontactemail: the email address of the admin for the farm.

-farmserviceaccount and -farmservicepassword: the identity information for the indexing service.

-defaultindexlocation: the location for all the locally stored index files, used to add index results by the index role, or to parse results by the query role.

And that's all there is to it.  you now have a functional indexing service installed.  One thing to note is that this does not configure the actual crawling of content, just the infrastructure to support crawling.  you must still specify any custom content sources and crawl schedules in the SSP admin console.

2nd: Required Steps to Install the Shared Service Provider. 

Here is what is required to install an SSP:

1) A Web App for the SSP

2) A Web App for MySites (can be a bogus/mock one if you do not plan to deploy MySites)

3) Configure the SSP

Frist, to script the creation of the Web Apps, we turn to the STSADM command ExtendVS, and it ends up looking something like this:

stsadm -o extendvs -url http://SharePointServer:9100 -ownerlogin domain\SPFarmAdmin -owneremail mossadmin@domain.com -exclusivelyusentlm -donotcreatesite -description "SSP - 9100" -databasename SSP_Content -apidname "SSP - 9100" -apidtype configurableid -apidlogin domain\WebAppAccount -apidpwd Password

So here's what it means...  ExtendVS is the STSADM command for creating WebApps.  It is used for both extending existing ones in IIS, as well as creating new ones.  The primary difference is whether it already exists in the metabase as a Web App, or if it is an unknown name.  Here are the parameters described:

-url: this is the url and port for the Web App. If no port is specified it does default to 80.  By default this will not create a host header, just the URL of the Web App.

-ownerlogin: this is the owner of the Web App... I've heard various theories on who this should be, but I prefer this to always be the Farm Admin Account that you use to create the farm.

-owneremail: same as above, really.  Just contact info.

-exclusivelyusentlm: this is for the security level on the Web App.  If you will be setting up Kerberos, then you do not want this option, however if that is a long way off, or possibly never, use this flag.

-donocreatesite: by default the ExtendVS comand creates a Site Collection at the root ("/").  For MySites and SSPs, this will break the WebApp so it cannot be used correctly, so you need this flag.  This is also handy if you are scripting for DR or restoration purposes, in which case you already have a root site you will want to restore later, so do not want another one to conflict.

-description: the description of the Web Application

-database: the name of the content DB to be created (this cannot be an existing DB.  Add existing DB's using the addcontentdb function detailed in the upcoming part 3 installment of this series).

-apidname: this is the name of the App Pool for the Web App.

-apidtype: this is either configurableid or networkservice, depending on what credentials you want the app pool to run under.  In most cases this will be configurableid.

-apidlogin and apidpwd: the app pool login and password.

-sethostheader: this one isn't in the example above, but is handy for setting the host header values for the web app based on the url parameter.

So after creating a Web App for the SSP, you'll need to repeat the process for a Web App for your MySites.  Both these Web Apps need to be created prior to establishing your SSP.  Typically in a "more-secure" model you would use separate identities for the Farm Admin, the SSP Web App and the MySite Web App.

To create the SSP itself, once both the SSP and MySite Web Apps are created, you will use the CreateSSP STSADM operation.  Here is an example of the function:

stsadm -o createssp -title "Shared Service Provider" -url http://SharePointServer:9900 -mysiteurl http://mysite.SharePoint.pri:80 -indexserver SomeServer -indexlocation "d:\index" -ssplogin domain\SSPAccount -ssppassword Password -sspdatabasename Shared_Services -searchdatabasename SSP_Search_DB

So here are the parameter descriptions:

-title: the title of the SSP... Make this meaningful, as you may find in larger farms that multiple SSPs are needed for a variety of reasons.

-url: the url of the SSP, including the port.  This is usually fine for oddball ports, as almost all functions of the SSP are server requests, not user requests, so users never see the url.

-mysiteurl: the url of your MySite Web App.  This is needed for the profile and user linkage, as well as the personalization functions of the MySite Web App.

-indexserver: the server that will hold the crawl role for the SSP.  This does not enable the crawl role, but sets the parameters.  You must have the index/crawl role already configured as is noted above.

-indexlocation: the physical file location of the index files on the crawl server.

-ssplogin and -ssppassword: the user and password for the ssp identity.

-sspdatabasename: the name used for the SSP database.  This is not the content DB of the Admin page for the SSP, that was specified in the Web App Extend command.  This is the location of SSP configuration and data (like profile details).

-searchdatabasename: the name used for the index DB.

Once this phase is complete, you have a functional SSP.  The only remaining steps to perform in the SSP that are not yet scriptable are the Profile Import to pull user profiles from a directory source (and schedule updates), and Search details.  Search details include the content sources and crawl schedules.  You'll actually find that those two functions are just about the only manual processes that need to be done in a fully scripted installation.

3rd: The Required Steps to Configure Outbound Email.

Outbound SMTP Email is one of the configuration settings that will give you the red "Your Farm is Broken!" warning, because outbound email is a fairly integrated part of MOSS.  It is used in admin notifications, user notifications for task assignment, workflows, as well as user alert subscriptions.

Outbound email is configured via STSADM using the Email command.

stsadm.exe -o email -outsmtpserver mail.domain.pri -fromaddress SharePoint@domain.pri -replytoaddress noreply@domain.pri -codepage 65001

The parameters are described below:

-outstpserver: This is the address or Fully Qualified Domain Name (FQDN) of your organization's SMTP Relay server.

-fromaddress: This is the address that will be listed as the originator of all emails coming from SharePoint.  You can actually set a Web App version of this, but this is the default.

-replytoaddress: This is the reply to address, which is usually a bogus address like no-reply, or leavemealone.

-codepage: This is the Character Set for email encoding. Most will be using UTF-8, which is 65001.

There are inbound email functions that can be set, but these are not currently scriptable, and also requires local SMTP server configuration on the server that will receive email.  Inbound email is a choice that many are split on.  There is some good functionality with it, but also some bugs and gotchas...

4th: The Required Steps to Configure Excel Calculation Services.

Excel Calculation Services (ECS) need to be started on at least one server in the farm to provide calculation and web rendering for Excel Workbooks.  To enable ECS, use the STSADM ProvisionService command on the server that this role will be activated on:

stsadm.exe -o provisionservice -action start -servicetype "Microsoft.Office.Excel.Server.ExcelServerSharedWebService"

This one is very basic and straight forward, and only has two parameters, the action and the servicetype.  The servicetype is the namespace of the service to start.

These steps will bring your MOSS farm out of the "Red" zone, and ready for use.  There are still many other great scriptable functions that can add to your farm configuration automatically.  In the next installment, I'll go over things like Alternate Access Mappings, Managed Paths, Attaching Content DBs, Deploying Features, and all sort of good stuff like that!  Until next time...!