Hi All,

I've got an issue currently with a SharePoint environment and need some assistance from people who know SharePoint inside-out.

Environment

WSS 3.0 - 12.0.0.6303

Symptoms

Adding/Editing user permissions on a root-level site is extremely slow (5-10 minutes).
Browser is stuck loading the edit permissions page '_layouts/editprms.aspx'
Furthermore, the entire Site Collection is effectively offline, i.e. no pages load while above action is being processed.
Thats right, the whole Site Collection is unusable...

Cause

Having a hunt around in SQL, it seems as though the process that's kicked off to update the user's permissions locks
out any other processes, and this process seems to access the 'Deps' table in the content database.

There's no information about what the Deps table is used for (suprise suprise), however in my environment there's alot of records
(tens of 1000's) whose SiteId column is set to the Site guid which is in the process of updating it's user permissions.

A single record in the Deps table looks like the following:

SiteId = <guid>
DeleteTransactionId = 0x
FullUrl = site/subsite/uploadedpage.htm 
DepType = 1  
DepDesc = site/_themes/<THEME>/theme.css 
Level = 1

All the records are for *.htm pages maintaining a dependancy to an applied themes CSS file.
In this environment users have uploaded thousands of htm pages and on all sites a theme is applied.

I replicated this issue on a test server. Out of frustration i deleted all the entries in the Deps table which fixed the problem,
updating a user performs as expected.

So it looks to me like it's a performance issue processing all of these records in the Deps table.
But why is it accessing this information for a user permission update?

Solution

??

Questions

What the hell is going on here..Anyone experienced this issue before?
What is this table used for and why would uploaded htm pages need a reference to a theme css file which they don't use anyway?

This looks to be a bug to me, and i've had a hunt around in the hotfixes to date and haven't found a fix.

 Tom.

A new version of the Access Checker web part is now available on CodePlex.

 Whats New:

- Added a filter control to the Web Part allowing filtering of nodes in the tree.
- Item text in the tree are now colored green/red.

Whats Changed:

- When viewing the permission inheritance of a site hierarchy, the coloring of the nodes is no longer in relation to the current site, it is now in relation to the nodes parent object.
- Client side javascript has been cleaned up in order to improve the loading time of the color-bar.

Whats Fixed:

- Node coloring is now printable.


Tom.

G'day mates.

 I've just released a new Web Part called the Access Checker Web Part (Beta) on Codeplex. It's purpose is to allow site administrators to determine what access a particular user has to content within a Site.

More specifically, you can view graphically whether a user has a particular set of permissions on Sites and Lists.

Background 

In our environment we would receive emails from site administrators fed up with managing permissions for users. A common scenario would be that a user needed to be able to read all content within a site. For a site admin to be certain of this, they would need to visit each list and library permissions page and check that a) the list was inheriting permissions or b) the list has unique permissions and the user needs to be added directly. (Not to mention folder and list item permissions, but that's outside the scope of what this web part addresses!)

Expand this problem out to groups of sites and it gets really scary...

The Web Part solves this management issue for site administrators. The web part will confirm what permissions a user has to each list and site at a certain level in a Sharepoint hierarchy. It can also show the permission inheritance hierarchy for a better understanding of how permissions are setup.

The Web Part is currently in Beta, so i would like to get some feedback on its usefulness and if you have any suggestions on improving this web part i would like to hear about them.

Tom Shirley.

Purpose

Provide a User Interface to administer Sharepoint content using PowerShell.

Background

I received an email recently of some interesting downloads on CodePlex relating to Sharepoint. One that caught my attention was a developer tool called Sharepoint Inspector (SPI), created by Gaetan Bouveret.

SPI is a tool to inspect a Sharepoint farm by drilling down into the various objects and then viewing their properties through reflection. There are other tools out there that do basically the same thing but a) the ones I know of are closed source (meaning I can't mess them up!) and b) Gaetan has devoted quite a lot of effort and started to add functionality to manage certain components within a farm, like activating features, querying site data and managing solutions to name a few.

A tool like this is really a must for all Sharepoint developers and even administrators (In our environment we only have WSSv3 deployed so we don't even get that OOTB MOSS manager tool which provides some management features).

So that's the first operand within the title explained, onto the second… PowerShell.

I've been using PowerShell, a run down and tutorials to get started using it with SP is available here, to do more and more Sharepoint tasks from things as massive as migrating from STS v1 to WSS v3, to little one off's like resetting a bunch of site's themes to creating play sites based off Active Directory user details.

Both operands on the stack, time to push() the operator (post-fix notation).

I thought it would be great if you could select a Sharepoint site from a tree view of your farm and then run a PowerShell script to perform a task on what's selected.

And reducing the contents of the stack brings us to a…

Solution

I've extended Gaetan's SPI to include the ability to execute PowerShell scripts while making available to script writers the current state of SPI, exposed via the class SharepointReferences.

So what this means is you can now drill down to an object and right click to select "PowerShell Actions" which will give you a listing of any available scripts that are defined in a user defined directory.

Each PowerShell script needs an accompanying definition file which is a simple xml file, as an example here is the schema for the Export Web script:

The only thing that needs explaining is the Command element. This element takes the PowerShell command that is to be executed, which calls your script and passes any required parameters.

In order to obtain the parameter values I've defined within a PowerShell runspace a variable called $spRef. This is a reference to the SharepointReferences instance defined in SPI which exposes all of the currently selected Sharepoint objects.

This means that if you wanted the ID property of the currently selected SPWeb object you would type: "$($($spRef.currentSite).id)". This command is then executed in a PowerShell runspace using a technique called Variable Expansion.

I've now been using this method of administration for a little while and so far it's quite handy. I've written some simple import/export scripts which allows an admin to right-click on a SPWeb and export it and its subsites to file, then click on a different location in the Sharepoint farm and right-click import (replace site or import as subsite) the last exported web. It's a time saver when you have requests coming in ad-hoc.

I've asked Gaetan to incorporate it into the original project, so hopefully he we get on this soon so that other people can use this feature. I will update on the status of this shortly.

Tom.

This is a repost of an article i upped on my blog back in Feb 2007

Purpose:

Apply a Sharepoint Theme to any provisioned webs based off any Site Definition via Feature Stapling.

Background:

A pre-deployment task for our implementation of WSS 3.0 is to brand Sharepoint. There are several ways to customize a Sharepoint implementation. One of the simpler methods is to create your own Sharepoint Theme.

Themes, once applied to a Sharepoint web, allow you to skin the look and feel of a significant portion of the pages that users come into contact with whilst using a site. We required fairly minimal customizations which were mostly serviced through custom stylesheets.

In our implementation of WSS 2.0 we used a custom site definition (based off the STS site def) to service our branding needs, along with modifications to bunch of admin pages on the front-end servers.

We could of taken the same approach of creating a new custom site definition which would give us more flexibility in terms of customization, but this approach isn't favourable due to the fact that we wanted all of the OOTB site definitions available for use, not just the standard team site definition.

Yes, we could create a custom site def based off each of the default site defs (STS, MPS, WIKI, BLOG etc), but this approach is no longer necessary for simple customizations due to a new feature in Sharepoint called umm.. Features. A Feature as defined in the SDK manual:

"Features reduce the complexity involved in making simple site customizations, and are robust when upgrades are applied to a deployment. Features eliminate the need to copy large chunks of code to change simple functionality. Features thus reduce versioning and inconsistency issues that may arise among front-end Web servers. Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by simply toggling a particular Feature on or off in the user interface"

Another alternative would be to directly modify the OOTB site definitions. This however is not supported. So what we wanted in a nutshell is a way to skin any type of Sharepoint site with as few modifications to Sharepoint files as possible.

The solution also had to have three main features: 

Req 1. Our custom Theme needs to be applied to sites automatically. (The standard process to apply a Theme is a manual one, 'Site Actions->Site Settings->Look and Feel->Site Theme')

Req 2. Any changes made to the custom Theme post deployment, must be reflected in existing sites that were provisioned after this solution was deployed.

Req 3. Modify as few Sharepoint files as possible

Solution:

A quick rundown of the solution is as follows:

1. Create a custom Theme. CSS importing is used to get around Sharepoint caching a copy of the Theme's css file, which would violate Req 2.
2. Create a Sharepoint Feature that applies a Theme to a site when a site is provisioned.
3. Create another Feature that staples the previous Feature to all site definitions. This idea came from Chris Johnson's blog.
4. Deploy the second feature at the Farm scope, which attaches the first feature to all sites within the Sharepoint farm. For ease of deployment i have used the WSS Solution framework.

Detailed Description:

1. Creating a Theme is detailed here WSS 3.0 SDK - How to: Customize Themes  or alternatively read Shane Perran's blog. In order to utilize the css 'indirection' method see Bil Simser's "Automagically updating themes" blog entry

2.

Feature.xml

ApplyTheme.cs

3.

Feature.xml

Elements.xml

4.

I have attached the VS 2005 solution. All you need to do is replace the GUIDS and Public Keys, sign the assembly and fix up any broken references. Oh and change names of classes, dll, etc so they mean something to you.

See the Sharepoint Solutions Team blog for an example VS 2005 solution, explaining all the files in the project and also check out Andrew Connell's HowTo on creating Solution files.

To deploy the Solution, here is a script that was posted by Daniel Larson on the SDK page Deploying a Solution.

@set PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%
stsadm -o deactivatefeature -name MyCustomTheme -url  http://localhost
stsadm -o retractsolution -name MyCustomTheme.wsp -immediate -allcontenturls
stsadm -o execadmsvcjobs
stsadm -o deletesolution -name MyCustomTheme.wsp -override
stsadm -o execadmsvcjobs
stsadm -o addsolution -filename C:\MyCustomTheme.wsp
stsadm -o execadmsvcjobs
stsadm -o deploysolution -name MyCustomTheme.wsp -immediate -allcontenturls -allowGacDeployment -allowCasPolicies
stsadm -o execadmsvcjobs  

Limitations:

The solution does not automatically apply the Theme to any sites that have already been provisioned.

Any feedback is appreciated,

Tom.