First off, the client alerted me to a strange problem – she was unable to delete images in any image library.

So, logging in with the system account I tested:

-          Marking the image in the library and selecting delete from the actions menu – nothing happened, the image remained in the library, no error message was shown.

-          Opening the library in the explorer view and trying to delete from there – returns "Unable to delete xxx_xxx.jpg. Unable to delete the file. It may not exist or is in use or the web server is temporarily unavailable."

-          Accessing via SharePoint Designer – returns "Server error: Unable to delete the file xxx_xxx.jpg. Error code: 16388"

So, in search of the root of this problem I naturally went to check the logs. But before doing so I checked the Diagnostic log settings, trimmed the logging options and clicked OK. SharePoint kindly returned the standard "Unknown error" message.

Then there's this one. Whilst trimming the logs I thought I'd double check the Usage Analysis log settings. It all looked ok so I exited but clicked OK and not cancel. And received this error:

"The transaction log for database 'MOSS_Config' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases"

Although this is an uncommonly informative error message with clear directions as to where to go next it's also quite unusual because there are as of today <b>zero</b> Google hits for this one.

The corresponding MOSS log didn’t give much more info:

"Unexpected query execution failure, error code 9002. Additional error information from SQL Server is included below. "The transaction log for database 'MOSS_Config' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases" Query text (if available): "{?=call proc_StartTimerRunningJob(?,?,?,?,?,?)}"   "

However, the corresponding application log error gave Event ID 5586. This yielded a variety of Google references but nothing specific.

So, I logged on (RDC) to the SQL server for the farm and was greeted with various messages along the lines of “Warning low disk space…”

In fact, the SQL had zero KB remaining. A sad state of affairs but one that’s easily fixed.

Anyway, I digress.

Fortunately, since this isn't a new problem there are already documented solutions to it, such as this one from Kindler Chase: http://www.raregrooverider.com/post/2008/02/SharePoint-Services-Search-Error-Event-ID-2424.aspx
And this from Pat McGown: http://blogs.microlinkllc.com/pmcgown/archive/2008/11/07/moss-search-access-denied-event-id-2436.aspx

In my particular case it was the latter resolution with disabling the loopback check which fixed it.

Setting up the lookup list
1. At the top level site use the /_layouts/create.aspx page to create a list with a column that contains the items you want to lookup to.
2. From the Site Settings > Site Column Gallery create a Custom Site Column that uses a lookup field to the new list and column from step 1.

Using the new lookup
3. At your chosen location in the site hierarchy, go to the settings for the list/library where you want to add your lookup and in the Columns section, click Add from existing site columns
4. Select your new Custom Site Column from the list (use the groups menu to filter and locate your list depending where you added it, either to an existing column group, the default Custom group or a newly defined custom group), and add across.
5. The new lookup column will now appear in your list/library.

What I want to achieve is a way to get an calendar event which is created in SharePoint into my single, personal Outlook calendar.

So, at a base level I was thinking along the lines of possibly using a custom sharepoint workflow to send a copy of the sharepoint event as a meeting request.
Or perhaps as a feature for MOSS/WSS calendars to have a button on the event info toolbar to 'add event to my Outlook'… 

Well, as it happens there is already a default function that works-ish. It's not very smart, but it works. 

At the very basic level, there is a default 'export event' option on the MOSS/WSS calendar event toolbar. Default function opens a 'file download' dialogue asking if you want to 'open' or 'save' the current event. Selecting 'open' gives you a standard Outlook event window.
Then selecting 'Save & close' from the toolbar here saves it directly into your own Outlook calendar.
Job done.

To simplify this process slightly you can deslect the 'always ask me about this type of file' option in the 'file download' dialogue. The default action will then be to open the event file, then you can just save and close.

Now… to find a way to automate this if you are the one creating a calendar event in SharePoint, plus adding attendees…

And what does this mean for the end user??  Since a single SPD workflow can only be attached to a single list, you have to rebuild a workflow from scratch for every instance you wish to implement.
Even if there are only a few lists/libraries that require the same workflow, this means, for complicated workflows built in SPD, a LOT of manual effort & time running through the rules based logic. Not to mention, if there's an email notification involved, you can't copy & paste the mail content and keep any lookups.

And how often is it that you have multiple lists/libraries that require the same workflow?? I'd say pretty often. And it's not always convenient, necessary or possible to have the workflow built in Visual Studio and implemented as a feature.

Well, rant over (for now), there is a workaround (probably by accident rather than design)…. it is possible to copy and paste workflows in SPD. And not only can this be done in the same site, it can be done across site collections & farms.

So, once you have created your first instance, you can simply copy & paste your 'template' to the root Workflows folder in the current (or any other) site. Then it's simply a case of following a couple of steps to ensure it's all going to run smoothly.

1. Rename the new copy to identify which library it will be associated with.
2. Open the new copy and you will be given the initial startpage of the workflow. Here you will see that the workflow isn't assigned to a list/library, so you can select a new list/library to assign it to.
3. Step through to the next page where you can check/modify any existing conditions & actions if you require small changes per instance (Note: references to specific columns/fields will need to be checked. Of course, if you're implementing this procedure over many lists/libraries then the chances are that the lists/libraries are identical or have similar key columns/fields that are part of the workflow)
4. Review any emails that will be generated by the workflow and reset any lookups that have been added to the body. These references will have been detached by the copy & paste. To fix this it's simply a case of selecting the lookup which will appear as a string like: [%{0B1B3F2F-D3DB-4F4B-8640-CA442C7E5B10}:%], then clicking on the 'Add Lookup to Body' button and clicking OK in the Define Workflow Lookup dialogue. This resets it to the current list/library.
5. Click finish when everything is checked.

Of course, you can save a target list/library as a template, move it to your  local development environment and keep a copy of this workflow assigned to it by doing the exact same procedure.

It's not the most elegant solution, but until the SPD design team get their act together it'll have to do.

I thought it was about time I mentioned this

The best way for you to address this issue and ask for a design change is to send a mail to mswish@micrsooft.com This mail thread is visited regurarily and is an important factor in deciding whether to change a functionality.

What happens when you encounter a document library (or many libraries) with hundreds of documents with multiple versions? - maybe even 50+ versions per document because someone forgot to consider version trimming during the planning or failed to educate the end users on the implications of versioning.
If a library is created with versioning enabled, the library settings show major versions enabled but with NO default setting for trimming, but the user doesn't get to see this unless they actively go into the library settings after creation. This relies on the user actually knowing how to manage versions in MOSS – this can never be guaranteed.

Of course, each one of these versions will be taking up valuable space in the database and having an impact, not only on the current db size, but the time and size of the daily SQL backups.

Is there a way to purge old versions in MOSS/WSS 3 without affecting the latest/current version??

Sadly (and almost predictably) there is NO default function for post-trimming / deleting document versions en masse, either in a single library or accross a site collection. With 100's or 1000's of documents across a site collection it would be no mean task to manually trim them all.

So far, in search for an answer to this, we came across the following third-party tool for SPS2003 (http://www.sharepoint247.com/FreeTools/DeleteVersions/tabid/56/Default.aspx), unfortunately it appears not to have been updated for MOSS/WSS 3.

However, there is a small light at the end of this tunnel – I suspect more by chance than design…

If you change the settings for an existing document library to trim the number of versions to, for example, no more than 3 major versions (Document Library Settings > Versioning Settings > Document Version History > Optionally limit the number of versions to retain), then when a user modifies or uploads a new version of a document, all but the latest specified number of versions will be deleted.

In our particular client case, this workaround was perfect since all the documents (application & network performance reports) are batch copied to a single library on a nightly basis. Simply reseting the library versioning & running the batch again forced the database to trim all the versions to 1 per document. After that it was a simple SQL process to shrink the database.

However, this still leaves a couple of mighty big holes in the document management feature set for in MOSS / WSS 3 :-

• NO default version trimming set at creation time.
• NO means of post trimming versions across site collections, sites or multiple libraries beyond manually deleting every unwanted version on every individual document.

What happens in an enterprise portal with 1000's of document libraries that can't be batch copied and replaced??? Scary eh…
With such a complex product as SharePoint you'd think the development team would have seen some of these glaringly obvious shortcomings (and yes, I have a list…)

So, mental note to self (and anyone else who's paying attention)…

• Plan carefully for versioning management…
• Educate clients on the implications of versioning…
• Educate clients on the need to educate their end users…
• Buy shares in storage hardware companies

A couple of errors were cropping up and typically the Infopath interface for reporting these errors gave no real clue as to the exact nature of the problem.
Also, both these errors mentioned references in the server application log – neither appeared there, which really didn't help matters.

Fortunately, with the right settings in central admin, MOSS has very detailed logging. However, these logs can be large and cumbersome to search through, giving you eye-strain and a headache at the very least.
So, before you even try troubleshooting via the MOSS logs remember to configure the logging to an appropriate level of throttling. Having said that, the config options in MOSS to filter sets of info in the logs is pretty poorly designed imo.

In the Central Admin pages the diagnostic logging event throttling was set to:
Category: All
Least critical event to report to the event log: Warning
Least critical event to report to the trace log: Verbose
Number of log files: 30
Minutes to use log file: 5

 —-

Configuration/Background:
The InfoPath form uses two web services to retrieve data from an SQL 2005 db – there is no writing to the db.
The web services are hosted on the same web application as the MOSS portal web app but using a different port.
The form is set to use a Trust level of Domain
The form is set to be browser compatible.
MOSS is configured with Enterprise Features enabled & configured for InfoPath Forms Services http://server:12345/_admin/ipfsConfig.aspx 
 Allow users to browser-enable form templates
 Render form templates that are browser-enabled by users 
 Allow embedded SQL authentication 
 Allow user form templates to use authentication information contained in data connection files 
 Allow cross-domain data access for user form templates that use connection settings in a data connection file 

The full form with web service data connections runs correctly when tested in InfoPath – ie the web service connections to SQL are good.

Issues:
 When the form is published to MOSS and accessed from a form library using the browser interface the form returns the following error:

An error occurred accessing a data source.
An entry has been added to the Windows event log of the server.
Log ID:6932

 No such error is listed in the server application event log

Check MOSS log:

Data adapter failed during OnLoad: Security settings on the server prevent the use of this data connection. 
Warning  The form could not retrieve data from http://server:10101/webservice.asmx because it would violate cross-domain restrictions. To allow this connection for administrator-approved form templates, enable full trust for the form template, or add the connection to a Data Connection Library. 
For user form templates, cross-domain connections must be enabled in SharePoint Central Administration, and all connections must be in a Data Connection Library.  For more information, please see the security documentation for InfoPath Forms Services.

Tested the form again and all is good

— key locations to remember for publishing browser enabled InfoPath Forms —

Central Administration > Applications:

1. Forms Services Configuration: http://server:12345/_admin/ipfsConfig.aspx
• Key settings for connections & authentication
2. Manage Form Templates: http://server:12345/_admin/ManageFormTemplates.aspx
• Upload, and approve a browser enabled form.
• Activate to a site collection
3. Manage Data Connections: http://server:12345/_admin/ManageDataConnectionFiles.aspx
• Upload and web enabled data connection files (.udcx)
• Save and upload udcx files from step 2 below

Site Administration:

1. Form Templates: http://server/FormServerTemplates
• This is auto populated from step 2 above
2. Data Connection Library: http://server/Data%20Connections/
• Target location to publish converted web services data connections from InfoPath
• Default Approval required.
3. Form Library: http://server/site/Library
• Set library advanced settings – enable management of content types
• Specify the published & deployed form template from the `select from existing site content types'