Friday, 28 September 2007

Using stsadm to add users to a SharePoint group

At first glance, the stsadm adduser command seems a bit of a pain when adding users into SharePoint because you have to specify a userlogin, useremail and username variable when using the command - these are not optional.

However, I have found that when I use dummy names for the useremail and username variables, the user profile database in MOSS overwrites them once the user has been added to the group. So, I used the following stsadm command to add users to a SharePoint group, which can be useful when you have bulk users to add from a CSV file:

stsadm -o adduser -url http:// -userlogin -useremail test@test.com -group "" -username "Test User"

For example,

stsadm -o adduser -url https://portal.edulink.internal -userlogin EDULINK\phil.childs -useremail test@test.com -group "Corporate Users" -username "Test User"

Once added, wait a few seconds and the e-mail address and user name changes from test@test.com and Test User to the correct one specified in the user profile database. Make sure that you test this with one user first though, before creating a script to add 1000 users all at once!

Thursday, 27 September 2007

Catalog 'index file on the search server Search' error on WSS 3 Search service

Everything was running fine for a couple of months and then the following error started to appear on the index server every five minutes:

Event Type: Error
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2424
Date: 27/09/2007
Time: 13:40:01
User: N/A
Computer: EP-SP-INDEX01
Description:
The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again.

Context: Application 'Search', Catalog 'index file on the search server Search'

There are lots of articles on this, one of them with a list of 15 suggestions to resolve the problem! However, I managed to find an article from Ivan Wilson at http://guru-web.blogspot.com/2007/08/wss-30-content-indexing-update-cannot.html that solved it for me (thanks, Ian). Ian says as follows:

"I fixed this by going to Central Administration – Operations – Services on Server. I selected the Windows SharePoint Services Search entry. I then changed the Service Account username and password to match the Content Access Account details. Click OK on the bottom of the page and wait five minutes."

"Once I saw that the error was no longer being logged I went back and set the Service Account back to its original username and password. Still no sign of the error. I also verified that WSS was indexing content again."

So that is exactly what I did. I had two service accounts - one called SP_WSS_SearchSVC and SP_WSS_SearchCA, so I entered the SVC account for both the service account AND content access account, restarted the service and it worked.

The only thing that differed from Ian's findings were that when I returned it back to having the SVC account as the service account and CA account as the content access account, the error reappeared straight away, except that it also reported a one-off error with trying to read the Central Administration site, as follows:

Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
Date: 27/09/2007
Time: 13:50:01
User: N/A
Computer: EP-SP-INDEX01
Description:
The start address cannot be crawled.

Context: Application 'Search index file on the search server', Catalog 'Search'

Details:
(0x80131534)

Not sure why all this started (it may have been after some SQL maintenance plans were run), so it's probably something to do with permissions somewhere, but rather than spend an age trying to discover what it was, I ended up using the service account for both services and content access - There shouldn't be any security implications of doing this because both accounts are only Domain Users, with identical SQL permissions, and this is only for indexing the WSS help files anyway. The only difference is that the service account is being used to run the Windows service, which gives it slightly more permissions on the Index server itself.

Wednesday, 26 September 2007

Getting the Document Conversions Service running on a server farm

I have two front-end Web servers and an Index server and I want to install the Document Conversions Load Balancer and Launcher service on the Index server. I chose this configuration rather than load balancing the Launcher service across the front-ends based on the recommendations in this article: http://technet2.microsoft.com/Office/en-us/library/f7d7b652-10cc-4c99-8c05-0cc4341d4d941033.mspx, and also because resilience of the Document Conversions service was not required.

I also followed the instructions titled "Configuring document conversions in a server farm" at the bottom of this article because the registry entries did need be set manually. After doing this, the Load Balancer service started fine but the Launcher service just hang on "Starting".

I then found another article (not referenced at all in the first article) called "The Document Conversions Launcher Service status on a SharePoint Server 2007 Web front-end server displays "Starting" but does not start or stop" at http://support.microsoft.com/kb/941212. I went through the instructions on this article and the Launcher service started successfully.

This article mentions the problem if you are trying to start the Launcher service on a second Web Front-End server - but in my example, I was trying to start it on the Index server.

Monday, 10 September 2007

Nothing appears in the site collection usage reports pages

Had the problem where the MOSS usage analysis processing logs were being created correctly in the default LOGS folder, but nothing appreared in the site collection usage reports pages.

Strangely, I could also successfully create reports in SharePoint designer and view the usage reports for each individual site at /_layouts/UsageDetails.aspx.

Well, surprise surprise it was a permissions issue. To get it working I added the local WSS_WPG account to the LOGS folder and gave it Read/Write/Modify permissions. However, even though there are log files dating back 1 month, the usage reports page only shows data from when I added the WSS_WPG account to the logs folder, so you will need to wait 24 hours before the first data appears.