Buy me an espresso

December 21, 2007

Installing Service Packs (WSS 3.0 SP1 and MOSS 2007 SP1)

Microsoft offers extensive information on the requirements and steps for installing. Unfortunately, in MS style, the information is all over the place and the "high points" are buried in 3000 word articles.

The Important Stuff:
  • You must install the WSS 3.0 SP1 BEFORE the MOSS 07 SP1
  • You must run the SPs on all web and application servers (if you have a seperate server for indexing, Excel, etc ... the SPs must also be ran on those).
  • The SPs do not need to be ran on the DB server.
  • You must use a configuration/installation account for the install of both Service Packs
    • Suggestion: Use GOD for this installation ... SA of the DB server and Administrator rights on the front end web server(s) ... then back out permissions after installation
WSS 3.0 SP1 & MOSS 2007 SP1 Step-by-step (simplified):
  1. Backup the Farm
  2. Remove any orphaned objects using -databaserepair
  3. Quiesce the Farm
  4. Stop the WWW Publishing service
  5. Run the WSS 3.0 SP1 installer
  6. Agree to terms and click Continue
  7. Once the installer is finished the SharePoint Products and Technologies Wizard will appear ... CANCEL THE WIZARD
  8. RUN the MOSS 2007 SP1 installer
  9. Agree to terms and click Continue
  10. Once the installer is finished the SharePoint Products and Technologies Wizard will appear ... click Next
  11. A dialog box will come up saying "You must run setup to install new binary files for every server ..." ... click OK
  12. You will get a warning about services restarted ... click Yes
  13. The Wizard runs and hopefully finishes without any errors
Microsoft Links:

December 19, 2007

Abosulte URLs in the Content Editor Web Part

Overview
For those of you that are unaware, the Content Editor Web Part (when using the Rich Text Editor) will change your image or link URLs to absolute paths (whether you like it or not). Obviously, this has a number of unfriendly consequences. If you are reading this post then you are suffering from one of those consequences ... I won't bore you with a list of the posssible issues this creates.

Solutions

Option 1 - Keep using the CEWP and manually remove the absolute paths on they images and links in the Content Editor Web Part.

Option 2 - Use Telerik's RadEditor Web Part

Option 3 - Use an event handler to remove the absolute path. Dan Attis' Blog

Option 4 - Use the Publishing Control RichHTML fields. You will have to have the Publishing Feature activated on your site for this to be an option. More details here.

December 18, 2007

6641 and 6482 errors ...

Overview
For starters, you should not have any local Administrators running a service or application pool for SharePoint 2007. As tempting as it may be to resolve errors by simply adding them to the Administrators group, it is simply not necessary.

Issue
When you start to back out/restrict permissions after installation/configuration ... you will most likely start to see a number of errors popping up (6641 and 6482). They are permissions related.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6641

Date: 12/15/2007
Time: 2:00:00 AM
User: N/A
Computer: COMPUTERNAME
Description:
The SSP Timer Job User Profile Change Job was not run.

Reason: Logon failure: the user has not been granted the requested logon type at this computer


Solution
For each of these steps I recommend restarting IIS and affected services ... or if you can (to eliminate any doubts) ... reboot the server.

Step 1 - Check to make sure your service accounts have "Log on as a Service" permissions.
  • Go to Start > run > gpedit.msc ... to pull up group policies (shown right).

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignments

  • Double click "Log on as service" and check to see if your service accounts are listed under the "Local Security Setting" tab

  • If they are not there they will need to be added

  • Double click "Log on as a batch job" and check to see if your service accounts are listed under the "Local Security Setting" tab

  • If they are not there they will need to be added

  • If you have updated your policies you will at least need to run gpupdate/force from the command line.
Step 2 - Add the service accounts to the Backup Operators local group.
  • The Backup Operators have a few more policy permissions that can tackle some of those pesky errors.
Step 3 - Add the service accounts to the WSS_WPG group.
  • There are a number of posts out there that tell you to go into component services and manually add the service accounts to IIS WAMREG or SPSEARCH. DO NOT add them individually. SharePoint has already populated the WSS_WPG group to these DCOM applications.
Worst case, you will need to add more permissions for the WSS_WPG group via component services (explained below):
  1. Start > Programs > Admin Tools > Component Services

  2. Computers > My Computer > DCOM Config > IIS WAMREG (and SPSearch)

  3. Right click > Properties > Security tab

  4. Under Launch and Activation Permissions click Edit

  5. Check the checkbox for Remote Launch and Remote Activation

  6. Click OK