Spell Check Fix Clarification

The MOSS 2007/WSS 3.0 spell check bug (that supposedly IS fixed in SP1, but I'd like to know how they fixed it) has had work arounds documented several times, but I'm not sure any of these were complete. Neither will this one be, but I have two observations I would like to share.

• You do not need to have any special permissions on the root of your site collection (just read).
• Spell check can also be broken with inadequate permissions in the %windir%\temp on the web front ends.

The standard "fix" is to have a document library called "Spelling" off the root of each site collection, and in that library you need a junk document named "Custom Dictionary.txt." It doesn't matter what is in this document. The users need to have at least some (read?) access to the root, but to this Spelling document library they need these permissions (and nothing more):

1. View Items
2. Browse Directories
3. View Pages
4. Use Remote Interfaces
5. Open

With this access, depending on what they have in the root, they may not be able to see the list, and they defeinitely cannot even open it in Sharepoint. They are unaware it exists.

The other problem we have seen is that on the %windir%\temp folder (usually C:\Windows\Temp) on each of the web front ends, the Network Service needs the following permissions:

1. Traverse Folder/Execute File
2. List Folder/Read Data
3. Read Attributes
4. Delete
5. Read Permissions

Being cruddy work arounds, I'm not sure how well these are documented anywhere. These are the steps we have had to take to keep working. It is a shame that the SharePoint community has had to endure bugs like this. Unfortunately I am pretty sure most of us will not be taking SP1, so we won't see how they fixed this problem.

Backup/Restore "Duplicates" and Broken "Content and Structure" (Settings.aspx)

This took a couple hours of staring at things and looking at every side of everything. I had used STSADM to back up a site and restore it to another site collection. This went pretty well, except for two problems:

1. Two of the lists showed up twice in the "All Site Content" (viewlsts.aspx) and
2. Content and Structure (settings.aspx) would error

#1 Symptoms
I tried deleting one of the lists. Oops. It deleted both (there really only was one). Hooray for the Recycle Bin!
The allitems.aspx for each list showed two web parts for the list (this is significant).

#2 Symptoms
You could navigate to any of the lists and stuff if you opened Content and Structure from another subsite, but you could not get to the root of this site.

Fix:
Delete the extra (duplicate) webparts from the allitems.aspx and all three problems went away.

Why? Ha! You tell me! But I am happier, and the users are happier. I'm just not very warm and fuzzy (welcome to my life with SharePoint).

How to Move the Central Admin Site, Even if You Already Screwed it Up

Revised! And also see http://bobklass.blogspot.com/2008/07/moving-central-admin-again.html
Moving the Central Admin site the right way is easy:

Run config wiz on old, removing
Run config wiz on new adding


But what if you did something to screw that up, like:

Start Central Admin on new server (through Central Admin)
Stop Central Admin on old server (through Central Admin)
Run Configuration Wizard on new server

which would leave you with NO Central Admin server?

You will have to try a little harder if you really want to screw things up. To fix it:

Run Config Wizard on new and REMOVE central admin
Run Config Wizard on the old and remove central admin
Run Config Wizard on new and ADD central admin

Similarly, you probably could redo the old Central Admin if it were screwed up and then do it the right way once everything was back the way it should have been. The right way:

Run config wiz on old, removing
Run config wiz on new adding

That's all fine, but sometimes SharePoint just won't do things the right way. My production server didn't present the option to remove the Central Admin site (why?) until I removed it from the farm and added it back (and the first time I ran the Config Wizard it took over an hour!).

But then it looked like the "right way" wasn't working. Upon close inspection, everything seemed to be where it should be. The problem was that the alternative access mapping for Central Admin needed to be changed (it still showed the old server). So just put in an explicit address and include ../default.aspx and navigate to the maintenance page, or just use ../_admin/AlternateUrlCollections.aspx and then change it to your new Central Admin server.