Ludo's LRT blog

Here in the LRT team at MMU we would love to use AD (global security) groups to target SharePoint web parts.  We are using MOSS 2007.

Unfortunately, it doesn’t quite work, although it used to some time ago.

Here’s a pictorial guide to what happens when we try to create a new AD group and use it in SharePoint:

1. Create a new global security group in AD.mmu.ac.uk.  Incidentally, inside our own LRT container. 
2. Populate the group with a number of users who already have access to our test SharePoint web portal.
3. Pick a shared web part, edit its properties, go to Advanced.
4. Under Target Audiences, try typing in the name of the new group and clicking the ‘tick’ icon to have it recognised.  It isn’t recognised, so SP underlines it in crinkly red and italicises it.
5. That can’t be right!  The group is right there in the AD!  Just to check, let’s delete the group name, then click on the ‘book’ icon next to the text box and look in there.
6. The ‘find audiences and groups’ dialogue box opens.  Select ‘Distribution / Security Groups’.  Try typing part of the name of your group and click on the magnifying glass.  The group is not found.
7. OK, let’s try all the above again from step 3 onwards, but first we’ll go to the SSP and do a full profile import.
8. Nope, still doesn’t work.

However, some groups that we have created do eventually appear in SharePoint, only with not as many members as they should have.  For instance, the group ‘hlss-election’ wasn’t appearing before.  Now it appears, with only one member.  It isn’t recognised in the ‘Target Audiences’ box if I type it in and click ‘Check Names’, but it is available using the ‘Browse’ feature (book icon).

If we ‘Browse’ the book, we can see that hlss-election has one member.  However, in AD it has three members.

One thing that might be of note is that I had added some text to the group’s Description field in AD Users & Computers before the last import.  This was suggested as being important in a blog post we found on the subject (look for Jason in the comments).

–Ends–

This is a “reprint” of an article originally published on a private wiki not open to the public by me in July 2009.

Add & Deploy
To install a SharePoint solution called solution.wsp from C:\MMU Web Parts\ on your SharePoint farm (you should be able to run these commands from any web server in the farm):

Add:
stsadm -o addsolution -filename "C:\MMU Web Parts\solution.wsp"

Now deploy it to the web application of your SharePoint site:

Deploy:
stsadm -o deploysolution -name "solution.wsp" -url "https://my.mmu.ac.uk" -immediate [-allowgacdeployment]

Enumerate current solutions

If you’d just like to see which solutions are installed on your SharePoint server farm:

stsadm -o enumsolutions

But this spits out a lot of XML that’s very difficult to read on the command line (or at all). Here’s a Perl script to run to get enumsolutions without all the surrounding flim-flam:

@o=split /</,`stsadm -o enumsolutions`;
while(<@o>){
chop;
print qq[$_\n] if /^Name=.*wsp/;
}

or on the Windows cmd line:

perl -e "@o=split /</,`stsadm -o enumsolutions`; while(<@o>){chop;print qq[$_\n] if /^Name=.*wsp/;}"

Retract & Delete

To uninstall a SharePoint solution from your farm run both of these commands:

stsadm -o retractsolution -name "solution.wsp" -url "https://my.mmu.ac.uk" -immediate

stsadm -o deletesolution -name "solution.wsp"

Lastly, here’s an improved Perl one-liner for taming the tidal wave of XML output from enumsolutions.

Last week K installed a web part only to find that errors were reported during the deployment.

The web part seemed to actually work – good.  But the solution couldn’t be removed from the farm, making improving the app difficult.

K tried installing a later version of the web part  under a different solution name.  This time, the deployment never completed!  It looked as though we wouldn’t be able to install any more web parts until this was sorted out.

Naturally, the web part was one that we also needed to improve urgently because a feature of the code was having a detrimental effect on one particular set of students and staff, as a result of a WebCT announcement that had been written that was >4k in size.

How we fixed it:

K found some advice online from a reliable source that suggested we needed to restart the Timer service on one of the SP servers.

We looked at the Timer Jobs in CA > Operations to determine what impact this would have on the site and decided current users would experience no apparent impact.

When we looked at Timer Job Status, we saw that for both of the solution deployments, only one server – JDEAPP2 – was experiencing problems, while the others were fine.  This would presumably cause a problem with farm-wide deployment while allowing the web part to work OK on most servers (including all the front-end ones). So we decided to restart the Timer service on JDEAPP2.  This is a Windows service called ‘Windows SharePoint Services Timer’.

Restart took less than a second.  Going into CA > Operations > Solution Management, we could now see that the stalled deployment had completed, while the original one that errored now presented options to retract or redeploy that weren’t there before.

Job’s a good’un.