Friday, December 11, 2009

[MOSS/WSSv3] SharePoint 2007 build numbers (UPDATE)

Here a list of build number of SharePoint 2007. Based on the build number you can determine which patchlevel your SharePoint environment is on:

12.0.0.6520 - MOSS 2007/WSS 3.0 October '09 Cumulative update
12.0.0.6514 - MOSS 2007/WSS 3.0 August '09 Cumulative update
12.0.0.6510 - MOSS 2007/WSS 3.0 June '09 Cumulative update
12.0.0.6504 - MOSS 2007/WSS 3.0 April '09 Cumulative update
12.0.0.6421 - MOSS 2007/WSS 3.0 SP2
12.0.0.6341 - MOSS 2007/WSS 3.0 February '09 Cumulative update
12.0.0.6335 - MOSS 2007/WSS 3.0 December '08 Cumulative update
12.0.0.6327 - MOSS 2007/WSS 3.0 August '08 Cumulative update
12.0.0.6318 - MOSS 2007/WSS 3.0 Infrastructure Update
12.0.0.6300 - MOSS 2007/WSS 3.0 post-SP1 hotfix
12.0.0.6219 - MOSS 2007/WSS 3.0 SP1
12.0.0.6039 - MOSS 2007/WSS 3.0 October '07 public update
12.0.0.6036 - MOSS 2007/WSS 3.0 August 24 '07 hotfix package
12.0.0.4518 - MOSS 2007/WSS 3.0 RTM

You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm

Source

Friday, November 20, 2009

[MOSS] Event 5214 - The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate'

[ISSUE]
The following event was occuring on our environment quite often:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 5214
Date: 11/19/2009
Time: 4:28:54 PM
User: N/A
Computer: [SERVER]
Description:
Insufficient SQL database permissions for user '[account]' in database 'SharePoint_AdminContent_3995bd54-8091-4157-b162-8aaaf7116355' on SQL Server instance '[SQL SERVER]'. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate, database 'SharePoint_AdminContent_3995bd54-8091-4157-b162-8aaaf7116355', schema 'dbo'.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[SOLUTION]
To solve this issue, perform the following steps:

  • Open the SQL Management Studio
  • Browse to the database in question, in our case "'SharePoint_AdminContent_3995bd54-8091-4157-b162-8aaaf7116355"
  • Open the database and then Security > Roles > Database Roles
  • In the right part of the window, right click the WSS_Content_Application_Pools role and click Properties
  • Select the menu option "Securables"
  • Click "Add"
  • Select "Specific objects" and click "OK"
  • Click "Object Types", select "Stored Procedures" and click "OK"
  • Add the following stored procedures: proc_FetchDocForUpdate, proc_GetWebMetaInfo, proc_UpdateDirtyDocument, proc_UpdateListItem
  • Click "OK" to add these stored procedures
  • Select the added stored procedures and select "Execute" in the "Grant" column.
  • Click "Add" once more
  • Select "Specific objects" and click "OK"
  • Click "Object Types", select "Views" and click "OK"
  • Add the following view: UserData
  • Click "OK" to add this view
  • Select the added view and select "Select" in the "Grant" column.
  • Click "OK" to complete

Wednesday, November 04, 2009

[MOSS/WSSv3] Post Installation automation

Just ran into the following ver usefull tool on Codeplex: The Post Installation Tool or PIT. This tool automates various configuration changes after you have installed SharePoint. Via a config file you can customize some configuration tasks.

Saturday, October 24, 2009

[MOSS/WSSv3] Feature cleanup

Have you ever seen the following error in one of your logs:
Failed to determine definition for Feature with ID '<guid>'. Skipping this feature for element querying consideration.
This message is caused by a feature that has been removed from the environment, without being properly deactivated before removal. SharePoint still has a reference to the feature, so it tires to activate the feature. But because it doesn't exist anymore, it will skip the feature.

Last week I ran into a tool which can scan your environment for such a "faulty feature". This tool is called the "SharePoint Feature Administration and Clean Up Tool" and can be found on Codeplex.

When you have started the tool, it contains a button called "Find Faulty Feature in Farm", which starts the scan for faulty features.

Have fun with this great tool!

Wednesday, October 21, 2009

[MOSS/WSSv3] Content Deployment/StsAdm export/import issue

[SITUATION]
At a customer the developers created a custom solution that displayed image in a picture library on a page and used the image title to overlay across the image. If the image title would be empty, the solution would use the site title. The solution worked fine on our staging environment.

We use Content Deployment to deploy the sites from the staging environment to a live environment. On the live environment, the overlayed text suddenly became the picture name instead of the picture title.

[ISSUE]
After some troubleshooting it turned out that Content Deployment deploys the site just fine from staging to live, however when an image title field is empty, Content Deployment populates this field with the image name! After performing some tests we discovered that this behavior is also occuring when:
  • Deploying a document with an empty title. The document name is used.
  • Using stsadm export/import to deploy the site instead of Content Deployment.
[CAUSE]
We raised a support call at Microsoft, but although they were able to reproduce the issue they are not going to fix this. According to "internal resources" this behavior is "by design". We could raise a design change, but that would probably be denied because other customers would deliberately use this behavior.

[SOLUTION/NEXT STEPS]
In this situation we had to modify our code to check if the title field is empty OR equal to the image name. Although this workaround works, we do not believe that this behavior is by design. When creating a "backup" using stsadm export and "restore" with stsadm import, you would expect no data to be changed in that process..........

Monday, October 05, 2009

[MOSS/WSSv3] Mergecontentdbs change

I have used the STSAdm operation MergeContentDbs many times in the past. But since I heard of the bug in this operation I temporarily stopped using it.

Fortunately the bug was fixed in the April Cumulative Update. So this weekend I moved some larger site collections to their own database and then I ran into an issue I didn't experience before:

MergeContentDbs used to copy the content to the new database and remove it from the old database to free up the data. However this time the amount of free space in the database did not change! Searching the Internet revealed a change in functionality of the operation.


"If a site collection is very large, an attempt to delete the site collection from a Web application fails. This causes the stsadm -o mergecontentdbs command to fail when you try to move site collections from one content database to another. This issue is resolved by adding an optional -gradualdelete parameter to the stsadm -o deletesite command. If this parameter is present, SharePoint marks the site collection as deleted to prevent further access while a SharePoint Timer job gradually deletes the data in the site collection. After you install the hotfix package that this article describes, the stsadm -o mergecontentdbs command uses this gradual delete functionality by default."



To remove the data from the database you can do two things:
  1. Run stsadm -o databaserepair to remove all orphans
  2. Wait until the daily timer job "Site Collection: Delete" runs, most of the times during the night.

- mergecontentdbs gotcha
-
Article updates for the April Cumulative Update

Wednesday, September 23, 2009

[MOSS/WSSv3] Anonymous access causes documents to appear in search and accessible for users

[ISSUE]
A customer was running into a strange issue with documents that were located in a document library which had strict permissions, but the documents were returned in the search results to all users AND users were able to open them. So it looked like SharePoint didn't obey the security settings.

[SITUATION]
In the past someone played around with the anonymous access setting. Because the environment is used as an intranet this was not supposed to be configured, so we disabled anonymous access on web application level. A few weeks ago, we noticed that users were able to open sites and documents even though they did not have permissions to it.

[CAUSE]
After some investigation and checking with Microsoft it turns out that SharePoint had some left over anonymous settings. Even though anonymous access was disabled at web application level, users were still able to access the documents anonymously.

As it turns out does the disabling anonymous access on the web application level only remove the administration pages of anonymous access, it does not remove all settings that have been configured before that. To make matters worse, we even ran into an extra issue:
After we re-enabled anonymous access, configured anonymous access on site level to None instead of Entire Web Site and a full crawl ran, the documents were still returned and available for users. Some more investigation turned out that, just like permissions, the anonymous access settings were also copied when breaking inheritance. Picture the following situation:
  • Enable anonymous access on the web application
  • Configure anonymous access on a top level site to Entire Web Site
  • Break the permissions inheritance of a document library and change the permissions
  • Set anonymous access on a top level site back to None
  • Disable anoymous access on the web application
In this situation, because the permissions inheritance was broken when its parent has anonymous access configured, the document library also has anonymous access configured. The only way to correct this through the GUI is to enable anonymous access on the web application level AND site level, so the anonymous access administration pages are enabled again on the document library.


[BACKGROUND]
Basically what happens: If you remove anonymous access form the web application only, on the webs it remains set. In case of the document library. By default it inherits permissions form its parent. The permission inheritance most probably was broken on the doclib when anonymous access was still enabled. The permissions were copied from the parent and the anonymous access remained enabled.

[SOLUTION]
In order to fix this issue, I have written a PowerShell script which loops through the site collection, checking each web and each library or list. If it encounters a web or list that has anonymous access configured, it disables that access.



[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$site = new-object Microsoft.SharePoint.SPSite("http://<site collection url>")

foreach ($web in $site.AllWebs) {
$web.Url
if ($web.AnonymousPermMask64.ToString() -ne "EmptyMask") {
$web.AllowAnonymousAccess
$web.AnonymousPermMask64
$web.AnonymousPermMask64 = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask
$web.Update()
}

foreach ($list in $web.lists) {
if ($list.AnonymousPermMask64.ToString() -ne "EmptyMask") {
$list.DefaultViewUrl
$list.AnonymousPermMask64
$list.AnonymousPermMask64 = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask
$list.Update()
}
}
$web.dispose()
}


More info

Tuesday, September 22, 2009

[MOSS/WSSv3] Error 1387 when removing users from Farm Administrators group

[ISSUE]
Today I tried to remove the user accounts from the Farm Administrators group, that have left the company a while ago. Unfortunately I was unable to do so, SharePoint presented me with an error 1387.

[CAUSE]
Using Google I ran into the following blog post Unable to remove user from SharePoint Farm Administrators group : Error 1387. Here Tim was talking about the fact that the accounts were deleted and SharePoint was performing some kind of check.

[SOLUTION]
After temporarily recreating the accounts of the users, I was able to delete the accounts from the group successfully!

Tuesday, September 08, 2009

[MOSS/WSSv3] SharePoint 2007 build numbers

Here a list of build number of SharePoint 2007. Based on the build number you can determine which patchlevel your SharePoint environment is on:

12.0.0.6510 - MOSS 2007/WSS 3.0 June '09 Cumulative update
12.0.0.6504 - MOSS 2007/WSS 3.0 April '09 Cumulative update
12.0.0.6421 - MOSS 2007/WSS 3.0 SP2
12.0.0.6341 - MOSS 2007/WSS 3.0 February '09 Cumulative update
12.0.0.6335 - MOSS 2007/WSS 3.0 December '08 Cumulative update
12.0.0.6327 - MOSS 2007/WSS 3.0 August '08 Cumulative update
12.0.0.6318 - MOSS 2007/WSS 3.0 Infrastructure Update
12.0.0.6300 - MOSS 2007/WSS 3.0 post-SP1 hotfix
12.0.0.6219 - MOSS 2007/WSS 3.0 SP1
12.0.0.6039 - MOSS 2007/WSS 3.0 October '07 public update
12.0.0.6036 - MOSS 2007/WSS 3.0 August 24 '07 hotfix package
12.0.0.4518 - MOSS 2007/WSS 3.0 RTM

You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm

[MOSS2007/WSSv3] "The expected version of the product was not found on the system" while installing update

[ISSUE]
I just tried to install the June Cumulative Update on a test environment. After the "Running detection" step, I got the following error:

"The expected version of the product was not found on the system"

[CAUSE]
Some troubleshooting revealed that we had installed SP2 for WSS and MOSS on the environment, but not for the installed language packs. After we installed SP2 for the WSS and MOSS Language Packs, the update installed just fine.

Monday, August 17, 2009

[MOSS/WSSv3] Error "Unable to get the private bytes memory limit for the W3WP process."

[ISSUE]
On the environment of a customer we encountered a lot of errors in the event log, which also caused some performance issues. The message was:
"Unable to get the private bytes memory limit for the W3WP process. The ASP.NET cache will be unable to limit its memory use, which may lead to a process restart. Error 0x80070005".

[CAUSE]
The message is caused by a known issue with insufficient permissions in your IIS metabase. The metabase ACL's on the target server did not include the IIS_WPG group on the following two nodes of the metabase (IIS_WPG is in both ACL's on a clean install):
- W3SVC/AppPools
- W3SVC/Filters

[SOLUTION]
Download the MetaACL utility from KB267904. When you have downloaded and installed the program, run the vbs via the following command:

cscript metaacl.vbs IIS://Localhost/W3SVC/AppPools IIS_WPG RE

The path is case sensitive - type exactly as above; after you run this command restart the IIS services and see if this corrects the problem.

Source

Wednesday, August 12, 2009

[MOSS/WSSv3] Large log files with default logging options

[ISSUE]
When you configured the SharePoint logging as default, it is very much possible that the logs are filled with "Preserving template record with id....." messages. You would expect these messages only to be logged when logging is set to Verbose mode.

[SOLUTION]
The question how to solve this issue has been asked a lot on the Internet, for example on the MS Forums. Unfortunately nobody had a real answer. But since a couple of months, Microsoft fixed this issue. The April Cumulative Update now contains a fix for this issue:


When you set the least critical event to report in the Event log to ERROR, and you set the least critical event to report to the trace log to MEDIUM, the following messages are logged in the Unified Logging Service (ULS) logs:
Preserving template record with size…
Deleting template record with size…
However, you only expect these ULS messages to appear if the logging level for General is set to Verbose.


Just install this update and you are good to go!!

Monday, July 13, 2009

[MOSS2007] Issues with Excel Services

[ISSUE]
Over the past weeks, we have had some issue with the amount of available disk space on our C drive. In order to free up some data, I have created a script which deleted used data from the C drive. One of the items it cleaned was the C:\Windows\Temp folder. After we ran the script on our servers, Excel Services suddenly stopped functioning properly.

[CAUSE]
As it turned out, Excel Services is writing some files into the C:\Windows\Temp folder on de Excel Services servers. After running the script, these folder were deleted, messing up Excel Services.

[SOLUTION]
From within the Shared Services page (Excel Services Settings section > Edit Excel Services Settings > Workbook Cache Location), you can change the location to which Excel Services writes these temp files. When leaving empty, it will use the system Temp folder.

IMPORTANT NOTE: The application pool account needs to have write permissions to this folder. And an iisreset is required before the changed setting will be activated.

Monday, July 06, 2009

[MOSS/WSSv3] June 09 Cumulative Update released

The June 09 Cumulative Update has been released. You can find more information about them on the following links:

MOSS:
972569 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972569

970948 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970948

970947 Language specific
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970947

972562 Language specific
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972562

WSS:
971538 uber package
http://support.microsoft.com/default.aspx?scid=kb;EN-US;971538

This update contains hotfixes after April CU and Microsoft recommends to install according to the following sequence:

Source: http://blogs.msdn.com/joerg_sinemus/archive/2009/07/01/moss-and-wss-june-cu.aspx

Friday, July 03, 2009

[Citrix WISP] The Web Interface for SharePoint shows "No Resources"

[ISSUE]
I tried to install the Citrix Web Interface for SharePoint 2007 (WISP) on our SharePoint environment according to the installation manual supplied by Citrix.

After the installation and configuration, the WISP only showed "No Resources" instead of any applications.

[CAUSE]
According to this article is one of the features supposed to create an application in IIS in the web application where you activated that specific feature. Unfortunately it did not do that. We are using Windows 2008 and IIS7, so maybe that is the cause of this issue.

[SOLUTION]
To solve this issue, I created the application in IIS manually. Just take the following steps:
  • Browse to the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Citrix folder
  • There should be a folder with a GUID as its name, copy that name
  • Open IIS and browse to your web application
  • Create a new application and use the GUID as the name and the same application pool as the web application

The downside of this issue is that you need to perform this step on each of your web servers manually.

Thursday, July 02, 2009

[MOSS/WSSv3] Common mistake about SharePoint recycle bin

Up until recently I was under the impression (like may others with me) that the timeframe you can configure for the recycle bin in the Central Administration page was for the first stage only. When that period was expired, SharePoint would move the content to the second stage recycle bin.

Last week I have been talking with a Microsoft employee who told me something different. According to him, SharePoint deletes the items from the recycle bin after this period, both from the first AND second stage recycle bin. The only way documents get specifically moved to the second stage is when a users cleans his recycle bin.

Tuesday, June 30, 2009

[MOSS/WSSv3] Bug in STSADM MergeContentDBS command

With Service Pack 1, Microsoft introduced the STSAdm command "Mergecontentdbs". With this command you can move site collections between databases. Unfortunately I recently ran into a bug in this command:

When your site collection contains multi valued columns, it is possible that the data in these columns will be gone after migration.

This issue is confirmed by Microsoft and according to them fixed in the April Cumulative Update. To prevent this issue from occuring, install Service Pack 2 and the April Cumulative Update on your environment.

Sunday, June 28, 2009

[MOSS2007] Unexplainable errors on the server desktop

[ISSUE]
A while ago we received some unexplainable errors on the servers desktop. A popup window would appear with the Title "Error" and three buttons "Abort, Retry and Ignore". That was all the info we got. When the popup was shown, IIS stopped responding all together until one of the buttons was clicked.

We had to call in the assistance of Microsoft and after numerous troubleshooting sessions we tracked down the issue to the Search component of SharePoint.

[CAUSE]
A user has uploaded a picture of himself to a picture library. He wanted to use that picture as his profile picture, so he copied the URL of the page (not of the picture) and managed to somehow paste this into the ProfilePicture URL field.

Unfortunately the picture library had spaces in the URL and when opening a picture, SharePoint always places the location where the user came from in the URL. Because the library contains spaces, were these URL double encoded:
Space: %20
Percentage sign: %25
Double encoded space: %2520




This caused the user to paste a double encoded URL into his ProfilePicture field. As it turns out, SharePoint throws an assertion error when it is requested to return this value, for example when searching for that specific person.

[RESOLUTION]
After discovering the issue, the Microsoft engineers checked internally and found out that coincidentally the issue was fixed in MOSS Service Pack 2. They redesigned the assertion handling in this service pack, fixing the issue.

Before we implemented Service Pack 2 on our environment, we changed the value is the users profile to a correct value and ran another crawl. Fortunately we never saw the issue ever again.

[WSSv3\MOSS] Shortcoming in stsadm MergeContentDbs - does not support multiple SQL instances

In our environment we have multiple SQL instances that host the content databases. Just tried to copy a site collection from one content database on one SQL instance to another content database on a different SQL instance. Unfortunately I got the following message:

"The databases need to be on the same database server in order to combine them"

It looks like the command does not support multiple SQL instances, which would be a real shortcoming.

Friday, March 27, 2009

Move IIS 7 root directory to different drive in Windows 2008

In IIS6, it was possible to specify the directory in which IIS should place its files during installation. In IIS7, this is not possible anymore.

To solve this issue, you can download a script which is able to do this after installation on this page:
http://blogs.iis.net/thomad/archive/2008/02/10/moving-the-iis7-inetpub-directory-to-a-different-drive.aspx

The script only contains a small bug. Solve this by:
  • Search and replace "f:\" by "%MOVETO%"

Thursday, March 26, 2009

[MOSS2007] SharePoint removes entries from hosts file with multiple entries on one line

[SITUATION]
The SharePoint environment consists of three servers, a web front end, an index/central admin and a database server. According to Microsoft Best Practices, we have activated the Web Application role on the index server as well and configured the index server to use the local server. SharePoint does this by modifying the HOSTS file.

[ISSUE]
Last week a colleague noticed that some entries in the hosts file were periodically removed. After some investigation, he found out that this only happens with entries where multiple hostnames are linked to one IP address, for example:
  • 127.0.0.1<tab>server.domain.intra<tab>server
All entries that had only one server name in each line, remained in the hosts file.

[SOLUTION]
To get around this issue we changed the following line:
  • 127.0.0.1<tab>server.domain.intra<tab>server
into:
  • 127.0.0.1<tab>server.domain.intra
  • 127.0.0.1<tab>server
After this change, SharePoint left the entries alone.

Wednesday, March 11, 2009

[MOSS2007] Import connections only shows a few domain controllers

[ISSUE]
At my current project we experienced the the issue that only one domain controller was listed when trying to configure SharePoint to use a specific domain controller (Shared Services /ssp/admin/_layouts/EditDSServer.aspx?dn=<domain name>).

[EXTRA INFORMATION]
The specific domain has about 75+ domain controllers world wide, so the fact that SharePoint lists only one is something strange. Because the listed domain controller isn't the closed one, SharePoint will always generate WAN traffic and imports will be slower.

[CAUSE]
After a long period of troubleshooting we discovered that the Active Directory guys had deleted all _ldap and _kerberos DNS entries (except for the one domain controller) in _tcp.dc._msdcs.. They have done this to make sure that computers that log on from an unmanaged site (which IP address is not configured in the AD subnets) always use the central AD server instead of randomly choose one and generating unnecessary WAN traffic. As soon as we added some extra _ldap DNS keys, these popped up in the list.

[SOLUTION]
We added the _ldap and _kerberos DNS entries for all domain controller in our 2nd datacenter. We are now able to select the closest domain controller.

Monday, March 09, 2009

[MOSS2007] Output caching error for _layouts/images path (Event 5785)

[ISSUE]
On our SharePoint environment we receive the following message very often in the Application event log:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Publishing Cache
Event ID: 5785
Date: [date]
Time: [time]
User: N/A
Computer: [server name]
Description:Unable to connect publishing custom string handler for output caching. IIS Instance Id is '[IIS web ID]', Url is 'http://[domain name]/_layouts/images/[image name].gif'.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[CAUSE]
The reason why this is logged is that SharePoint tries to cache the file mentioned. Because the _layouts/images folder is not considered a SharePoint managed path it is not able to do so.

[SOLUTION]
To fix this issue:
- Open the web config for the mentioned web application.
- Search for the <location path="''_layouts/images"> section
- Add the following text to the section (just before </system.web>)
<httpmodules>
<remove name="PublishingHttpModule">
</httpmodules>

Source: MS Forums article, last post