WitwickiTech.com

Recently, I had a user ask me about the an error they saw in the Workflow Information for a document. The library was using an out-of-the-box approval workflow and, after all the approvers had approved the document, the Workflow Information listed an Error event by user System Account with a description of “An error has occured in Approval”.

After some investigation, it turns out the error is caused by a configuration mismatch. There is a pair of settings, one in the document library, one in the workflow that must be matched otherwise this error will occur. In this particular case, the “require content approval” option in the document library was off while the “update the approval status” activity in the workflow was on.

Thankfully, the solution to this particular problem is fairly straightforward. Either turn on “require content approval” (using Document Library Settings > Versioning Settings) or turn off the “update the approval status” activity (using Document Library Settings > Workflow Settings > [select appropriate workflow] > Next button).

Changing the settings will prevent all future workflows from having this error; however, when the error occurs, the workflow stays running and changing the options after the fact, has no effect. I tried changing both options separately to see if the workflow would respond but it appears the only solution for running workflows is to terminate them (which changes the workflow status to cancelled).

One of the projects I’m involved with is setting up an anonymous portal site. As part of the site we decided to include a “Contact Us” form which we implemented as a standard SharePoint list. To allow anonymous access to the site, we allowed users to access the Entire Web site via Permissions > Settings > Anonymous Access. It turns out that giving anonymous access to the entire web site only allows anonymous users to view items in a list. It does not give permission to add/edit/delete items in a list. In hindsight, the help text for the anonymous access setting does actually tell you this if you read it closely but it wasn’t obvious at first:

Anonymous Access
Specify what parts of your Web site (if any) anonymous users can access. If you select Entire Web site, anonymous users will be able to view all pages in your Web site and view all lists and items which inherit permissions from the Web site. If you select Lists and libraries, anonymous users will be able to view and change items only for those lists and libraries that have enabled permissions for anonymous users.

Because we do actually want anonymous users to have access to the entire site, we ended up having to break permission inheritance for the list and then explicitly allow anonymous users to Add/Edit items as well as View items (selected by default) using List Settings > Permissions for this list > Settings > Anonymous Access.

For Reference, the server environment is SharePoint 2007 Enterprise (MOSS) on Windows 2003 and SQL Server 2008 with WSS/MOSS SP2.

Stumbled across an interesting situation today. A site admin asked how to turn on security trimming for the top navigation links on a SharePoint site. She had created several subsites and didn’t want the top nav tabs displayed if the user didn’t have access. She knew it could be done because she had been on other sites where it worked.

My first thought was “It just works, there is no ‘turn it on’ option”. So I went to the site to take a look. Sure enough, two of the four tabs displayed even if the user didn’t have access to those subsites. So I did some investigating and it turns out that when manually creating top navigation headings (using the Publishing feature navigation screen), if you use the full URL to the subsite, security trimming does not occur while if you use the relative URL to the subsite, security trimming does work. That’s rather interesting behaviour and it makes me wonder what other effects can happen when using full URLs vs relative URLs.

For Reference, the server environment is SharePoint 2007 Enterprise (MOSS) on Windows 2003 and SQL Server 2005 with SP2 and the August 2009 CU. The client environment is Internet Explorer 7 on Windows XP with Office 2007.

Since I’ve hit this issue twice now, thought I’d drop a post for myself so I don’t have to Google yet again for it.

Problem: Unable to activate publishing and standard features in a site. This occurs whether activating the features manually or via content deployment.

Solution: Re-install Service Pack 2 and any applicable Cumulative Updates using the standalone installation packages.

Cause: If the IIS Role is added by SharePoint setup, the Service Pack is not applied correctly.

Symptoms:

• Unable to activate Publishing feature
• Unable to activate Standard feature
• File Microsoft.SharePoint.Portal.dll in <12 hive>\ISAPI has the wrong version number

Environment:

• SharePoint 2007 SP2 (slipstreamed)
• Windows 2008 and 2008 R2

Links:
http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/8b96663a-ed87-4ab4-bd59-33c7245a76d4

- Dave

Some of our users have been experiencing problems when trying to synchronize their outlook calendar to a SharePoint calendar. Usually, Outlook sits at some percentage of send/receive indefinitely, but we finally had one user get an actual error. The error was “Unknown Error 0×800401F3″ which doesn’t say much but allowed me to finally track down the problem. Here’s the details:

Issue

• Outlook hangs on Send/Receive when user has sync’d calendars
• Outlook gives an “Unknown Error 0×800401F3″ when user has sync’d calendars

Workaround

• disconnect the offending calendar in Outlook and reconnect in SharePoint

Problem

• known issue with Outlook 2007 not decoding a Base64 Encoded Header

Change

• April Cumulative Update contains the fix, see KB968857

Environments

• WSS 3.0 and MOSS 2007
• Exchange 2003

References

• http://social.technet.microsoft.com/forums/en-US/sharepointadmin/thread/9db8897b-270d-4505-9b3d-26bfc177a718/
• http://support.microsoft.com/default.aspx/kb/968857
• http://www.endusersharepoint.com/STP/topic/outlook-and-sharepoint-sync-not-working
• http://www.techtalkz.com/microsoft-outlook/436948-connect-sharepoint-task-list-fails.html

- Dave