The MOSS-pit

A colleague of mine encountered this error when attempting to configure a new SharePoint install from scripts.

After some soul-searching and much swearing, we found the error to be caused by SharePoint not liking its accounts to contain Fully Qualified Domain Names. He had specified all of the accounts (farm creation acc, search accounts, app pools etc.) to be something like "Domain.Qualifier\AccountName".

The resolution was to specify the accounts like "Domain\AccountName".

As this was scripted, we decided to simply roll-back the environment to the previous snap-shot, then re-run the scripts with the accounts changed, however it is probably possible to delete the SSP, change the accounts using STSADM commands and then recreate it. These posts would help if that is the tack you decide to take:

- http://www.stationcomputing.com/scblogspace/Lists/Posts/Post.aspx?List=ec6ce151%2D566a%2D499e%2D94a5%2De153fafda404&ID=35

- http://support.microsoft.com/kb/934838

Note: you may need to ensure your NICs have NetBIOS support enabled for them to recognise the unqualified accounts.

I recently had a requirement to use a scripted approach to create a SharePoint farm that used Kerberos authentication.

A quick bit of research pointed me towards the excellent resources made available by Gary Lapointe (see his blog at http://stsadm.blogspot.com/).

Gary has created and made freely available a huge number of really useful custom STSADM commands and Powershell commandlets, as well as going through the code used to create them. It really is an excellent resource he has created, and well worth spending some time going over all the information that he has very generously compiled and offered there.

One of the items Gary has on the site is his Install scripts (http://stsadm.blogspot.com/2008/03/sample-install-script.html) which creates a Kerberos based MOSS farm, including creating and configuring the SSP and search, a portal web application, a mysites web application and a team sites web application.

This is all achieved with batch files that cal PSCONFIG and STSADM commands, with a few of his own custom STSADM commands being used – very helpfully, these commands are provided as a WSP which is installed as a part of the farm creation scripts. Very neat.

These scripts follow Microsoft's "Plan for Administrative and Service Accounts (Office SharePoint Server): Least-Privilege Admin Requirements when using Domain Accounts" (http://technet.microsoft.com/en-us/library/cc263445.aspx ).

I thought I would quickly go through the steps I followed to build my development vm using these scripts (note: these aren’t a comprehensive set of steps, for example I don’t indicate when I performed Windows updates and took vm snapshot’s etc., but rather cover the main items that must be completed in order to successfully create a Kerberos authenticated farm).

In order to enable Kerberos, many accounts used during the install process require Service Principal Name’s (SPN’s), and being entrusted to delegate authority. To make these changes, you require access to the ADSI Edit MMC snap-in. Instructions on how to install this if it is not available on the machine can be found at http://technet.microsoft.com/en-us/library/cc773354(WS.10).aspx

To Create an SPN

1. Log on to your Active Directory domain controller using the credentials of a user that has domain administrative permissions.
2. In the Run dialog box, type ADSIEDIT.MSC.
3. In the management console dialog box, expand the domain container folder.
4. Expand the container folder containing user accounts, for example CN=Users.
5. Locate the container for the SQL Server Service account, for example CN=mosssqlsvc.
6. Right-click this account, and then click Properties.
7. Scroll down the list of properties in the SQL Server Service account dialog box until you find servicePrincipalName.
8. Select the servicePrincipalName property and click Edit.
9. In the Value to Add field, in the Multi-Valued String Editor dialog box,enter the Service Principal Name string – which takes the form of: {Protocol}/{host and FQDN}:{Port}, e.g. “MSSQLSvc/mosssql:1433” or “HTTP/intranet.development.com” * – and click Add.
10. Click OK on the Multi-Valued String Editor dialog box, and then click OK on the properties dialog box for the SQL Server service account.

*One little “gotcha” that you may need to be aware of when creating a Kerberos authenticated farm is that SharePoint 2007 only supports Kerberos web applications running of the default ports. This is why I have not had to supply port numbers in the SPNs used by the application pool accounts.

Setting an Account as Entrusted to Delegate Authority

1. Start the “Active Directory Users and Computers” MMC snap-in.
2. In the left pane, click Users.
3. In the right pane, right-click the name of the user account, and then click Properties.
4. Click the Account tab, under Account Options, click to select the Account is trusted for delegation check box, and then click OK.

Ok, so to create my environment, the steps I followed were (note: these steps assume that the current account being used to perform the installation is a member of the local administrators group):

1. Create the vm, install the operating system and activate the Application Server, Domain Controller and DNS roles (I cover these steps in a bit more detail in this post: http://suguk.org/blogs/the_moss-pit/archive/2008/12/22/16362.aspx).
2. Create the SQL Server service account (svc-sqlsvr) as a domain account, give it an SPN of MSSQLSvc/{host and FQDN}:1433, and enable it for delegation.
3. Install SQL Server and all related SP’s.
4. Grant the current account performing the install sys_admin privileges on the database.
5. Create the following domain accounts, setting the one’s with SPN’s to be trusted for delegation (format: Account Name -- SPN -- Comments):

spadmin -- [none] -- Used to generate emails from the farm to users. Requires an email address to be specified like no-reply@{email}.{server}

spfarm -- HTTP/{host & FQDN}:{Admin port} -- [no comment]

sspapppool -- HTTP/sspadmin.{FQDN} -- Should not be a member of the Administrators group on any computer in the server farm.

sspsvc -- [none] -- This account should not be a member of the Administrators group on any computer in the server farm.

sspsearch -- [none] -- Should not be a member of the Farm Administrators group.

sspcontent -- [none] -- Should not be a member of the Farm Administrators group.

sspuserprofilesvc -- [none] -- Requires read access to the directory service, and Manage User Profiles personalization services permission.

sspexcelsvc -- [none] -- used for running excel services on the ssp

sphelpsearch -- [none] -- Should not be a member of the Farm Administrators group.

spcontentsearch -- [none] -- Should not be a member of the Farm Administrators group.

spportalapppool -- HTTP/portal.{FQDN} -- Should not be a member of the Administrators group on any computer in the server farm.

spmysitesapppool -- HTTP/mysites.{FQDN} -- Should not be a member of the Administrators group on any computer in the server farm.

spteamsiteapppool -- HTTP/teams.{FQDN} -- Should not be a member of the Administrators group on any computer in the server farm.

siteowner1 -- [none] -- Should be modified here and in the scripts to be a sensible account for your env.


6. Install MOSS, but don’t run the config wizard.
7. Install the MOSS infrastructure update (this is required to enable Kerberos), and the service packs.
8. Create your DNS entries to support the four web sites (sspadmin, portal, mysites, teams)
9. Run the Gary Lapointe’s farm creation scripts.

I then found a few more things I had to do to complete the farm install:

- configure the index server in central admin (Operations->Services on server->Search Indexing->Office SharePoint Server Search

- configure the default access account (SSP Admin->Search Administration->Default Content Access account)

Fix up the license type reset that happens when you install SP2 (CentralAdmin->Operations->Convert License Type)

- Go over the rest of the settings in the SSP and Central Admin to make sure they suit your needs (eg. crawl schedules and rules, profile import sched's, usage analytics etc.)

Following this process established the SharePoint farm which included the creating Central Admin, the SSP and three web applications.

A (rather major) memory leak has been found in SharePoint, caused by the failure of SPHttpApplication objects to be properly cleaned up - read all about it in Todd Carter's great post The Sharepoint Sasquatch Memory Leak

I have quickly whipped up a WSP that implements Todd's fix and thought I would attach it here for anyone else who might find it useful.  It simply deploys a DLL to the GAC which implements the classs he describes in his post.  I have done it as a WSP so that the DLL will be auto deployed to all web front-ends used by the web application it is deployed to.

The install process is as follows:

1) Install the wsp to the central admin solution store (using "stsadm -o addsolution -filename [filename]

2) From Central Admin, deploy the solution to your targeted web application.  This will deploy the SPHttpApplicationLeakFix DLL to the GAC on all the web front-ends for that web application.

3) Go onto all the web front-ends and change the global.asax file (found at: '\InetPub\wwwroot\wss\VirtualDirectories\[Web App Dir Name]'). The two lines that need to be modifed are:

they should be changed to:

That's it - at this stage your sharepoint web application should still load and behave as normal, though hopefully its w3 worker process won't be consuming the huge levels of memory it was previously!

A zip containing the WSP and a small readme is attached to this article.

 

NOTE: Now the update contains the wsp - apologies for the complete balls-up ;)

Another really short bog entry - another pointer to someone elses blog! This is a great little walkthrough re: creating a development vm with DNS and AD and Mail - http://blogs.msdn.com/johnwpowell/archive/2008/07/07/walkthrough-build-a-windows-sharepoint-services-3-0-development-virtual-pc-with-sql-server-active-directory-and-e-mail.aspx

Havent blogged for ages - must get back into it soon. Anyways, here is a nice blog entry on setting up FBA for SharePoint 2007 using IIS7: http://blog.summitcloud.com/2009/10/enable-forms-based-authentication-for-sharepoint/

• SPUtility.FormatDate
  
  Allows you to format a given date to any of the SPDateFormat types
  
  

  DateTime curDate = DateTime.Now();
  DateTime regionDate = web.RegionalSettings.TimeZone.UTCToLocalTime(web.ParentWeb.RegionalSettings.TimeZone.LocalTimeToUTC(curDate));
  return Convert.ToDateTime(SPUtility.FormatDate(web, regionDate, SPDateFormat.ISO8601));

  
  
  
• Get the 12-Hive filesystem path
  
  Returns the filesystem path for the 12-Hive, or any of the folders beneath it.  This is typically (though not always) going to be C:\Program Files\Common Files\Microsoft Shared\web server extensions\12
  
  

  //Get path to features directory
  //Would typically return "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES"
  string featurePath = SPUtility.GetGenericSetupPath("template\\features");

  
  
• Get Full (absolute) URL
  
  Converts a relative Url into an absolute Url
  
  

  //Get url to list item
  SPListItem item = spList.Items[1];
  string itemUrl = SPUtility.GetFullUrl(spSite, item.Url);

  
  
• Redirect to page
  
  Send a HTTP redirect to the client's browser
  
  

  //Redirect to specified page, adding querystring
  string url = "http://portal/TestResults/Pages/results.aspx";

  string queryString = "successflag=passed";
  
  SPUtility.Redirect(url, SPRedirectFlags.Default, Context, queryString);

  
  
• Send email
  
  Lets you send an email from the context of the given SPWeb
  
  

  //Send email from current SPWeb
  SPWeb web = SPContext.Current.Site.OpenWeb();
  string subject = "Email from the " + web.Title + " web";
  string body = "The body of the email";

  SPUtility.SendEmail(web, false, false, "someone@somewhere.com", subject, body);

  
  
• Transfer to SharePoint success/error page
  
  Allows you to transfer the browser to the ootb error and success pages
  
  

  //Transfer to Error Page
  SPUtility.TransferToErrorPage(ex.Message);

  //Transfer to success page, and specify url to move onto after "Ok" clicked
  SPUtility.TransferToSuccessPage("Operation was completed", @"/Docs/default.aspx", "", "");
  
  
  
  

There are a bunch of others on there, and although they are not really very well documented, they are certainly worth a look through.

• ssp
• mysite
• moss

• the time zone
  
• upload file size limit (may need to be increased)
  
• recycle bin status (ensure default values are appropriate for you)
  

• User Profiles - configure the profile importing so that the full import (weekly) and incremental import (daily) take place at an appropriate time (when you vm will actually be on).
  
  
• Search settings - click on "Content source and crawl schedules", and then on the auto generated "Local Office SharePoint Server Sites" content source.  This should show 4 start addresses - http://moss, http://mysite, http://ssp and sps3://mysite. 
  
  Click the "Create a schedule" link under the "Full Crawl Schedule" dropdown, and specify a weekly time for a full crawl of the content to be done.  This can be resource intensive, so best if you plan it for a time when you know your vm will be active, but you probably wont be using it (weekly team meetings time is ideal).
  
  Repeat this process for the incremental crawl schedule, but make it a daily crawl - I tend to make it repeat every 20mins.

• Backup up the web app: use STSADM to backup the web app to a file with the command
   
          stsadm.exe -o backup -url -filename
         
      You can add a "-overwrite" flag as well, which indicates that if the file already exists it should be overwritten - probably not necessary for most ad hoc backups.
  
  
• Web.Config: grab a copy of the web.config to get an custom settings and safecontrols
  
  
• Hive-12: next, you need to grab a copy of the production's have 12 directory so that you pick-up any additions/customizations here.  The directory is (generally) found at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE
  
  
• Solutions/DLL's: last step is to add any of the customized solutions used on the production farm to your dev environment. 
  
  If you have the solution packages to hand then great, put them on your vm and install them using "stsadm -o addsolution" - this way you get them added to the dev farm's solution store correctly, and the web.config gets updated appropriately.
  
  If you don't have them, a dirtier way of getting the functionality across is to just copy the custom DLL's from the GAC and/or bin directory onto your vm, and update the web.config yourself.
  

• Safe Controls
• Any additional custom ConfigSections
• Custom Errors section

 

And thats it - hopefully now you should have a replica of your prod environment on your vm, ready for you to start developing against.

 

• Title - unused, but always sensible to leave this field in your custom lists, as some SharePoint functionality expects it to be there.
• Level1
• Level2
• Levelx - The level columns hold the node names for that level of the tree control.  The root node of the tree is the name of the list
• HoverText - Tooltip text to be displayed when user hovers over that node
• ShowCheckbox - if that node should display a checkbox or not
  

 
(click to see a version that isnt squashed down)

 

How to create the Custom Field

When creating a custom field, there are 3 aspects that must be addressed:

1) The Field Type Definition
2) The UI and logic for adding your field to a list
3) The UI and logic for your field when an item in that list is being edited

(Note: you could have a fourth section here if you wanted to customise the way your field was displayed when the list item properties were viewed, but I was happy for the tree node path to be displayed as text, so no customization was required).

The WSP package associated with this post installs the following files:
- …\TEMPLATE\CONTROLTEMPLATES\TreeListControl.ascx
- …\TEMPLATE\CONTROLTEMPLATES\TreeListEditControl.ascx
- …\TEMPLATE\XML\FLDTYPE_TreeList.XML
- TreeListControl.dll (to the GAC)

 

1 - The Field Type definition

There are two parts to defining your field - the code implements your field type, and the FLDTYPES_name.XML file that contains all the information SharePoint requires to implement your custom field.

1) The code that implements the field type

The class for your custom field is going to override one of the existing SPField types.  My class here, “TreeListControl.TreeListField” (contained in FieldDef.cs),  inherits from SPFieldsMultiLineText.  The major change to this class that mine is making is the addition of a “Dictionary” collection to hold the property values for the field:

 

//Dictionary of property values
private static Dictionaryint, string> dictUpdatedPropertyValue = new Dictionaryint, string>();

//Properties in a delimited string
private string _delimitedPropertyValues;

 

When users choose to add this field (say as a custom column in a list) they are asked to set some properties about (the source list for the tree, number of levels, etc.).  These values need to be stored by your custom field so they can be used later on when implementing the field.  The dictionary collection is used to store these property values.  Until the values are put in the dictionary, they are held in a the _delimitedProperty values string.

 

I also added the following properties to allow me to access the dictionary:

 

///
/// Access the delimited properties for the control
///

public string DelimitedPropertyValues
{
    get { return dictUpdatedPropertyValue.ContainsKey(ContextId) ? dictUpdatedPropertyValue[ContextId] : _delimitedPropertyValues; }
    set { this._delimitedPropertyValues = value; }
}

 

 

And very importantly, I override the base field rendering control, so that my TreeList control will be rendered:

///
/// Override the field rendering control to use the custom TreeList control
///

public override Microsoft.SharePoint.WebControls.BaseFieldControl FieldRenderingControl
{
   get
   {
      Microsoft.SharePoint.WebControls.BaseFieldControl TreeList = new TreeList();
      TreeList.FieldName = InternalName;
      return TreeList;
   }
}

 

 

The rest of the functions in this class are quite straight forward, and simply used for maintaining the values stored in the dictionary.

2) The FLD_type.XML

 

 This file defines the field for SharePoint, and gets deployed to …\12\TEMPLATE\XML. most of the fields in here are pretty self-explanatory, though I would like to highlight a few of them:

 

Field Name="ParentType">NoteField>

Setting the parent type of the field to “Note” allows this field allows us to avoid the 255character limit that most of the other parent fields type’s have - a Note field has no character length restriction.

Field Name="FieldTypeClass">TreeListControl.TreeListField, TreeListControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f525b76b9e4fb66Field>

This defines the assembly and class therein that implements this field.

 

Property Schema with single field to hold the custom properties for this field -->
PropertySchema>
   Fields>
      Field ID="DelimitedPropertyValues" Hidden="TRUE" Name="DelimitedPropertyValues" DisplayName="(Hidden) DelimitedPropertyValues" Type="Text" /> 
   Fields>
PropertySchema>

As the comment indicates, the property schema section is where we define our field type has an additional hidden field used for holding our properties.  This “PropertySchema” was meant to allow you to define multiple property fields (one per property), but there is a bug that prevents this from working.  Hence, we store one property, which in actuality is a delimited string of all our properties.

 

 

 

 

 

 

 

2 - UI and Logic for adding your Field to a List

 

This basically refers to presenting a screen to allow a user to set or change the properties that your custom field uses, and storing these property settings.  So it deals with our “DelimitedPropertyValues” property above.

My Tree control is going to have 10 properties:

1. Site (string) - the name of the site holding the list of data that defines this tree.

2. ListName (string) - the name of this list holding the tree data.

3. Levels (int) - the number of levels this tree has.  user will select list via a dropdown.

4. SortByAlpha (bool) - whether the nodes in this list will be sorted alphabetically, or be displayed the way they occur in the list.

5. ShowSetNull (bool) - if a “Set this value to be null” link should be displayed beneath the tree.

6. ShowCheckboxes (bool) - if this tree should render checkboxes on nodes as defined in the list holding the tree data.

7. CheckBoxDisplay (string) - a string indicating if the checkboxes should be displayed on “All Nodes”, “Leaf nodes” or “List Defined” nodes.  User will select which one via a dropdown.

8. AutoCheckSubnodes (bool) - if a node containing subnodes is checked, should they all be automatically checked also.

9. ExpandCheckedNodes (bool) - if the tree should load in an expanded state, showing all nodes that have been checked.

10. ShowHoverText (bool) - indicates if the tree control should show the hover text as defined in the list holding the Tree data.

 

So, the first thing I need to do is to create a control that allows the user to set all of these properties when they use my custom field. 

 

In my fileset, the control is the TreeListEditField.ASCX file, and it gets deployed to …\12\TEMPLATE\CONTROLTEMPLATES.

 

The majority of this control is fairly straight forward, simple ASP.Net controls like Labels and TextBoxes to gather my property values, but you may not be familiar with the controls that enclose these, ie:

wssuc:InputFormSection runat="server" id="MySections" Title="Tree List Details">

       Template_InputFormControls>

             wssuc:InputFormControl runat="server">

                    Template_Control>

 

 

The “InputFormSection” control & “InputFormControl” are SharePoint controls that creates the standard look and feel that SharePoint forms have.  So, with those encasing my control (made up of labels, textboxes, dropdowns etc), I end up with something like this:

 

(click to see an image that is not squashed down)

 

 

Great, so now I need to put together the code that is going to be associated with this control.  All this code really needs to do is to create the correct DelimitedPropertyString for the values set by the user in the control.  So (for example) if they have checked a checkbox, put a “True;” in the delimited string.

 

I have a little logic around the “Load Lists” functionality - I want the user to enter a url to a SharePoint site containing the list holding the tree data, to then click a button to load the lists on this site into a dropdown, and finally to select which specific list holds the tree data.  I ensure that the path to the site is a relative url by removing the root url for the current web application if it exists in the given site url.

 

The OnSaveChange method is used to create a delimited string for all the properties, and then set this string against the controls “DelimitedPropertyValues” property.

 

So that we set these controls to have the correct values when someone is editing an existing TreeList column, the InitializeWithField method must parse the “DelimitedPropertyValues” string and set the state of the controls to be correct as per the values contained in that string.

 

 

 

 

 

 

3 - UI and Logic for your Field when an item in that list is being edited

This is very similar to the previous section, except we are now defining how the column will look and behave when that list item is being edited - that is, that it will display the tree as defined by our list.

 

As with the TreeListEditField control, this is an ascx file that gets stored on the filesystem at …\12\TEMPLATE\CONTROLTEMPLATES.  In the attached solution, this control is called TreeListFieldControl.ascx. 

 

It is made up of three parts - the tree control, a link that can be used to set the string value set by tree control to null, and a label that can be used to show the current string value.  These controls are contained by a “RenderingTemplate” control, which allows us to create our control from these three parts.

SharePoint:RenderingTemplate ID="TreeList" runat="server">

    Template>

        asp:TreeView runat="server" ID="treeList" />

        br />br />

        asp:LinkButton ID="setNullLink" runat="server" Text="Set this value to be null">asp:LinkButton>

        br />br />

        asp:Label  ID="valueLabel" runat="server">asp:Label>

    Template>

SharePoint:RenderingTemplate>

 

 

Ok, so like before, we now need to implement the code that is going to be associated with this control.  This code has quite a bit to do - it must get the properties that have been set against the control, then build the tree control from the designated list, and configure it based on the properties. 

 

I am not going to describe how the code does this in depth, as it is well commented in the cs file, and hopefully is easy to understand, however I want to point out that I use a viewstate variable (“drawnTree”) to determine whether to run the tree creation code, rather then the usual “if !Page.IsPostBack”.

 

This is because we use this control on created web pages (in the “PublishingControls:EditModePanel”), which means a page could be considered a postback (say, after web parts have been added) and the tree control not drawn.

 

And that’s it.  Install the solution to your farm (you can use the ~InstallSolution.bat included to help with this), deploy it to your web application (best to do this through central admin), and then it should be available for use in your lists and site columns.

 

 

 

 

Some things to note:

• The code currently assumes all users will have read access to the list containing the tree control data, if this is not true, you will need to implement some impersonation in the code around where it parses this list and builds the tree

• Because the checked tree nodes are stored as a string showing the TreeNode path, the ‘/’ character cannot be used in any of the tree node names

• I have taken out all of my logging and tracing calls, as these rely on other in-house code libraries. If you want to use this code in a prod system, I suggest you add your own in there

• I have taken out the custom styling classes (css) from the ascx’s, you may want to consider adding in your own

• Although this control works as is, this is really meant as a starting point for you to implement the control you need - an XML file might be a better source for your tree data, you might not like the strict design for the tree data list this control requires, you might want additional tree functionality, etc.

 

The Visual Studio 2008 solution is in the "TreeListControl.zip" attached to this post - contains compiled WSP file, so can be installed and used directly on SharePoint install.

 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

After recieving a number of comments on this tree control, I feel I should point out that, as only the text of the tree node is stored against a list item, changing the value of the tree node by updating list item value that sources the tree nodes will not cause the value to be automatically updated on all the list items it is applied against.

It would be a simple change to make the Tree control store a list item guid rather then the node path string, which would then make this possible.

The company I wrote this for uses an external search provider (not microsoft), and it was easier for them to process a bunch of node paths to provide their search filters, rather then to process a bunch of id's, and perform a lookup back to a sharepoint list, hence this design was used.

To resolve this problem for the company mentioned, we created a web part which allows the user to update the values assigned to list items.  So when they want to change a tree node item, they delete the item in the list, create a new one, then use this web part to change the original items node path to the new items node path - not really an ideal solution, but seems to work well enough.