To match the ScopeId in the EventData property of the SPAuditEntry to a SPListItem you need to use the hidden column ‘ScopeId’ and not the Id property of SPListItem.

Here is what I mean

The following XML is returned in the EventData proprty for a SPAuditEventType of SecRoleBindUpdate. To match the Scope returned in the XML to SPSite, SPWeb and SPList object you would use the Id property of this object, but not for the SPListItem.

<roleid>1073741826</roleid>
<principalid>11</principalid>
<scope>72EEC412-B14B-4EFB-AB95-EA821A3A4C63</scope>

You need to use the ‘ScopeId’ column of the SPListItem

So why can’t I just use the SPAuditQuery.RestrictToListItem method to return the audit entries for that SPListItem.

It doesn’t work, that’s why and this has been confirmed by MS Support.

Here is a workaround that will link the ScopeId to the SPListItem that triggered the audit entry


using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;namespace ConsoleApplication1
{
  class Program
  {
  static void Main(string[] args)
  {

We were getting an error on one of our Load balanced web servers.

First of all we got “Attempted to read write to protected memory” error followed by the “The path specified cannot be used at this time” which is then logged every minute in the event viewer on our server.

This then ends up using all the resources on that server, which then makes the server become unavailable. Once the machine becomes unavailable it will move onto the next server and kill that one.

This was reported to Microsoft support and they identified it as a bug that will be fixed in SP1.

In the meantime the following will need to be done to work around this problem

1. Install the following hotfix 923028
2. Retype the password for the search service from The central administrator page.
3. Run “services.msc” and select the Windows SharePoint Services Timer
   Make sure the service is running with a MOSS service account, if it is running with MOSS services account then stop the service, retype the password and then start the service account again
4. Install / script a tool that automatically restarts the Windows SharePoint Services Timer when the following Event IDs are raised; 6398, 6482 and 7076. Microsoft Support maybe able to provide you with this tool if you raise a support request with them.

 This is a particularly scary bug to be appearing in a “Production” ready product, especially as it is only happening in the farm environment and can take down you whole farm.

I believe there needs to be more information on the whole way SharePoint propagates between servers in a farm, there seems to be little understanding of it presently.

Here’s an odd one.

We had customized our master pages by adding in the Search WebPart, so we could customize some of the parameters

We changed the following:

<asp:ContentPlaceHolder id="PlaceHolderSearchArea" runat="server"></asp:ContentPlaceHolder>

To the following:

<asp:ContentPlaceHolder id="PlaceHolderSearchArea" runat="server">
<SPSWC:SearchBoxEx webpart="true" runat="server" __webpartid="{2883947B-2B5C-4A56-92B3-33B7383F7C0D}" id="SearchBoxEx1"><WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <Title />
  <FrameType>None</FrameType>
  <Description>Used to search document and items.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>ImportedPartZone</ZoneID>
  <PartOrder>0</PartOrder>
  <FrameState>Normal</FrameState>
  <Height />
  <Width />
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <AllowConnect>true</AllowConnect>
  <AllowEdit>true</AllowEdit>
  <AllowHide>true</AllowHide>
  <IsVisible>true</IsVisible>
  <DetailLink />
  <HelpLink />
  <HelpMode>Modeless</HelpMode>
  <Dir>Default</Dir>
  <PartImageSmall />
  <MissingAssembly>Cannot import this Web Part.</MissingAssembly>
  <PartImageLarge />
  <IsIncludedFilter />
  <ExportControlledProperties>true</ExportControlledProperties>
  <ConnectionID>00000000-0000-0000-0000-000000000000</ConnectionID>
  <ID>g_455588d4_92a9_484e_9273_9221d7a9a97f</ID>
  <GoImageUrl xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/gosearch.gif</GoImageUrl>
  <GoImageUrlRTL xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/goRTL.gif</GoImageUrlRTL>
  <GoImageActiveUrl xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/gosearch.gif</GoImageActiveUrl>
  <GoImageActiveUrlRTL xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/goRTL.gif</GoImageActiveUrlRTL>
  <DropDownModeEx xmlns="urn:schemas-microsoft-com:SearchBoxEx">ShowDD_DefaultContextual</DropDownModeEx>
  <AdvancedSearchPageURL xmlns="urn:schemas-microsoft-com:SearchBoxEx">/SearchCenter/Pages/advanced.aspx</AdvancedSearchPageURL>
  <SearchResultPageURL xmlns="urn:schemas-microsoft-com:SearchBoxEx">/SearchCenter/Pages/results.aspx</SearchResultPageURL>
  <ScopeDisplayGroupName xmlns="urn:schemas-microsoft-com:SearchBoxEx">Search Dropdown</ScopeDisplayGroupName>
  <RegisterStyles xmlns="urn:schemas-microsoft-com:SearchBoxEx">true</RegisterStyles>
  <ShouldTakeFocusIfEmpty xmlns="urn:schemas-microsoft-com:SearchBoxEx">false</ShouldTakeFocusIfEmpty>
                </WebPart>
</SPSWC:SearchBoxEx>
</asp:ContentPlaceHolder>

We did this in all our master pages including the application.master page.

All was working fine until we tried to delete a column in a list and we go the “Unknown Error” message and the column wasn’t deleted.

The following error message was be ing logged

Application error when access /_layouts/mngfield.aspx, Error=Unable to validate data.   at System.Web.Configuration.MachineKeySection.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)     at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) 

After of a month or so of investigation with Microsoft support, we discovered that the Search Webpart was causing the problem in the application.master page and causing a conflict in one of the application pages in the “Layouts” directory, specifically the mngfield.aspx page.

We have removed the Search WebPart from the application.master page and all seems to be working fine.

UPDATE

I have had an update from Microsoft on this issue, apparently the wording is wrong.

It will retain the number of major versions entered, but the number for minor versions is not to limit the number of minor versions, but to limit the number of major versions that have minor versions (Does that make sense?).

For example, if I set major versions to 10 and minor versions to 2, it will show me 10 major versions of which 10 and 9 will have minor versions still available.

The problem here is that I can still create 100 minor versions so this is not helping me limit the amount of versions my users keep and keep my storage costs down

n a document library under “Versioning Settings” you can choose to set the number of major and minor versions to retain.

This does not work! You are still able to create more than the number of versions specified in both major and minor

Version

I have spoken to Microsoft and they have confirmed this to be a “design limitation”. Has anyone ever got someone at Microsoft to say “bug”?

I’ll keep you updated if I get a fix for this.

There is currently a bug in MOSS 2007 search that automatically converts any URLs entered to lower-case.

We had a site hosted on a UNIX server that had a case sensitive URL, so when I entered http://server.net/Start/Welcome.html MOSS 2007 converted it to http://server.net/start/welcome.html and then tried to crawl this URL, but UNIX would return a “page could not be found” error.

Microsoft provided us with a hotfix for this, so if you have the same problem I suggest you raise a support request.