SharePoint (MOSS) 2007 Service Account Requirements

What service accounts do you need for a SharePoint / MOSS Farm installation, or a simple single-server installation on your dev box?

The answers are many and varied, and the documentation from Microsoft tends to be hard to read and convoluted to say the least – you really really really have to want to trawl through it to get the information you’re after

As far as what service accounts you need, whether they need to be domain accounts or local accounts you can find out from the documentation (obviously), having done that, you can decide to really go to town and plan an elaborate service account matrix or you can use just 2 accounts.

I’ve gone for a middle ground approach (unless needs demand otherwise) and planned a simple set of service accounts, reproduced here, which you can either use as-is for a simple farm deployment, or you can build on for a complex deployment.

I’ve also provided a link to the simplest, most readable document from Microsoft, that I came across while researching my own service account requirements.

Anyway, here’s the links;

• MOSS Farm Level Service Accounts Matrix.xlsx
• MOSS Farm Level Service Accounts Matrix.xls
• Office SharePoint Server Security Account Requirements.doc (from the Office Website)

SharePoint Feature for .NET 3.5 Web.config Changes

Leading on from this post, and this post, I created a SharePoint Solution/Feature combo to update Web Application web.config files with the changes neccesary to support;

• .NET 3.5 SP1
• Ajax Control Toolkit
• Microsoft Data Vizualization Chart Controls

The Web.config changes don’t require that you have Ajax and MSChart installed on your WFE’s so you can deploy the solution even if you don’t need the Ajax/MSChart stuff.

Alternativly you can modify the Visual Studio/WSPBuilder solution and change it yourself to remove those bits.

Download the Visual Studio/WSPBuilder solution here, or download just the SharePoint WSP here.

Delete a Folder from a Sharepoint Document Library

This is an update to a post I wrote on deleting list items from document libraries, prompted by a comment made on that post asking how to delete Folder(s) from within a document library.

Initially I replied by suggesting the use of the SharePoint object mode, as shown below;

SPWeb web = new SPSite("your site's url").OpenWeb();
web.Folders[“document library name”].SubFolders.Delete(“folder name”);

However, the commenter indicated that he could not use the object model as the code would be executed on a remote client machine, which left the SharePoint Webservices.

I’d not previously attempted to delete folders using CAML before, and as it turns out the CAML is exactly the same as if we were deleting list items, see the post on deleting items from document libraries, but the CAML for deleting a folder named Folder2 in some document library is shown below;

<Batch PreCalc='TRUE' OnError='Continue'>
    <Method ID='1' Cmd='Delete'>
        <Field Name='ID'>2</Field>
        <Field Name='FileRef'>http://pccal01/mortality/Test/Folder2</Field>
    </Method>
</Batch>

I’ve shown the CAML above with spaces and such for display purposes, your CAML should not contain white space or CR characters. In the second example shown below, the folder name contains a space, "Folder 1", in this case the FileRef parameter should not be URL encoded, or contain _x0020_ replacements etc.

<Batch PreCalc='TRUE' OnError='Continue'>
    <Method ID='1' Cmd='Delete'>
        <Field Name='ID'>1</Field>
        <Field Name='FileRef'>http://pccal01/mortality/Test/Folder 1</Field>
    </Method>
</Batch>

Note: The ID parameter is required to be present in the CAML query, but it is ignored by the webservice, you can safely just set its value to “1″.

These CAML commands can be submitted to SharePoint using the UpdateListItems method of the Lists webservice found at  http://{sharepoint site URL}/_vti_bin/Lists.asmx

Using the SharePoint SPWebConfigModification Class

I’m working on a feature to provision core dependencies for my applications and tools into the SharePoint environment, which inevitably involves changes to the web.config files on Web Applications across the farm.

This post has proved really useful when using the SPWebConfigModification class.

SharePoint / MOSS and (ASP.NET) Server Side Code

It’s well documented that ASP.NET pages when hosted in SharePoint / MOSS should not include server-side / inline code scripts such as shown below, for various security related reasons.

<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
     // some C# code which does stuff!
}
</script>

More importantly, SharePoint does not allow such pages to be shown. If you try to run such a page you’ll get shown a “helpful” error messages such as;

An error occurred during processing of {some file}. Code-blocks are not allowed in this file.

So far so good, obviously, if you have an ASP.NET page in SharePoint, your code-behind should go into a compiled assembly and placed in the GAC, and your aspx page references the GAC’d assembly. What wasn’t so obvious at first (at least to me!) is that other aspects of an ASPX page are also considered “code”, such as;

• The AutoEventWireup attribute of the Page directive
• Macro code such as <%= someControl.ClientID %>

The later I use quite a lot in a pages client-side JavaScript.  Any how, to get around these problems isn’t insurmountable, you can manually wire up event handlers for Page events by overriding the Page OnInit() function, and the later can be fixed by creating and registering a startup script with the Script Manager to create client-side Javascript variables containing ASP.NET client-side control ID’s, e.g.

private void RegisterControlClientIDsScript()
{
	var script = new StringBuilder();
	script.AppendFormat("var fcdi_rdAreaVariation='{0}';", rdAreaVariation.ClientID);
	script.AppendFormat("var fcdi_ddlAreaFacet='{0}';", ddlAreaFacet.ClientID);
	if (script.Length > 0)
	      ClientScript.RegisterStartupScript(GetType(), "PageStartupScripts", script.ToString(), true);
}

But, you can instruct SharePoint to allow server-side code in Pages, I do this for pages of this kind, like I said all “code” goes into a GAC’d assembly. To do this, enter a fragment such as shown below into the <SharePoint>/<SafeMode>/<PageParserPaths> section of web.config.

<PageParserPath   VirtualPath="/mortality/tools/*"
		AllowServerSideScript="true"
		CompilationMode="Auto"
		IncludeSubFolders="true" />

Reset IIS and fill your boots

The VirtualPath attribute can target all files within a specific folder (as shown, using the wildcard *), including (or not) subfolders, or the VirtualPath attribute can target a single file (replace the wildcard with the filename itself).