Hi,

We have a custom function that performs a MOVE operation either at file-level or at folder level. When we use the function on a massive scale and/or on a set of folders that have many sub-folders and documents, we encounter some situations where the documents could not be moved (since behind the scene, a move is basically a add followed by a delete), there is a bug in the way WSS/MOSS allocate the internal unique ID for a new document/item and therefore, the MOVE operation can not be completed successfully.

Sometimes, the ID obtained by the internal stored procedure of WSS returns an ID that is already allocated (i.e., the ID being retutrned by the stored procedure is smaller than the latest ID allocated for this document library) and therefore, the add portion of the MOVE cannot be completed. From this point forward, you cannot add any new document in the library and worst, since the MOVE operation was not completed, you end up with duplicate documents. We believe that in our case, since we support multiple MOVE operations against the same set of folders, this is what has stress the ID generation logic to a point where the bug shows itself. We probably have to rework our logic but even then, there is still a bug with the ID generation and Microsoft has recognized it.

When we look at our database, the docID increment is not linear; it is exponential and therefore, for a library containing around 50000 documents, the current highest docID is at 1.9 billion, near the SQL limit of 2.2 billion. This bug was also existing in SharePoint 2003 and Microsoft is currently working on a hotfix for this bug but no date has been released so far.

In the mean time, what you could to determine if you have this situation, and most of the time you really can't tell, is the following:

1. Open the dbo.AllLists table within a WSS Content database. This table contains a row for each list/library within the WSS Content database. The following columns are the ones to look at:
1. tp_Title - The Title of the list/library
2. tp_ItemCount - The actual number of items in the list/library
3. tp_NextAvailableID - The ID that should be used for the next item addition. On normal conditions, this should be equal to to_ItemCount + 1

If there is a huge difference between the tp_ItemCount and the tp_NextAvailableID, there is a chance that this list/document library is victim of the bug. Please note that a high rate of DELETE will reduce the tp_ItemCount and will be reflected in the difference; it should not be considered as an error.

Another useful query to perform to confirm a problem with ID generation. Perform this query agains the dbo.AllDocs table of your WSS Content database:

SELECT dbo.AllDocs.DoclibRowId, dbo.AllDocs.TimeLastModified, dbo.AllDocs.TimeCreated, dbo.AllDocs.[LeafName], dbo.AllDocs.[DirName], dbo.AllDocs.NextToLastTimeModified, dbo.AllDocs.Id, dbo.AllDocs.ParentId

FROM [dbo].[AllDocs]

WHERE ListId = 'a list GUID goes here' AND DoclibRowId is not null

This will show you if the ID generation is linear (and correct) for a given list/library and other information for each item in the list.

Hope this will help someone!

DJ Lordee

We were migrating a MOSS site collection in production and these servers have anti-virus protection in place. This protection was preventing MOSS-WSS to send outgoing e-mail. The error reported was "Cannot connect to SMTP host " followed by an encrypted server name that was looking like Chinese characters.

 To fix the problem, just look at your anti-virus settings to allow SMTP on port 25 and this should work. Thanks to John Powell for the tip.

One of our project wants to implement the concept of a legal hold as part of our Records Management practice. A legal hold is required for one or many documents when a litigation occurs. All items relevant to a given litigation must be freeze meaning that their current information policy must be suspended, only specific users are now allowed to access the document, and all these actions must be audited.

Given that this function was need prior to the DOD certification of MOSS 2007 that validate the MOSS Records Management features, which occurs in May, we have think about an interim solution. Using a legal flag property (a checkbox) within the document properties, we have written an event handler that look at every field change in the document library and if we detect that the legal flag has been modified for a given document, we dynamically change the permission sets for this item, thus restricting access to a specific group, and we start audit various actions such as view, edit, etc.

The only thing that we haven't done is to suspend their current information policy and it is because we haven't really looked at it seriously. Since Records Management feature is now DOD certified, we will look to use it instead of our custom solution.

This situation is a solid example of the richness and flexibility of the MOSS/WSS platform and object model. We've been able to achieve 2 of the 3 core functions related to Legal Hold just by writing a couple of event handlers.

By using this blog platform, I wish to share our experiences, tips and development practices using WSS V3.0 and MOSS 2007 platform. We have selected MOSS 2007 as our ECM platform to enforce our management of unstructured content such as digitalized images of paper-based business documents, Office documents, and so forth.

Our program is a three-year plan where each business units must understand and comply to our ECM framework prior to storing any content within MOSS. We're opting for a phased approach to avoid recreating the current mess of file shares and to help us achieve greater compliance toward regulations in the area of digital documents.