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.