Yes, here it is, another shortsighted omission from MS....
It's not possible to create a workflow in SharePoint Designer and save it as a template to be re-used in multiple lists/libraries!
I mean, c'mon guys, how hard can that have been to implement !!??

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.

So here's another tricky issue (and another missing feature) in the MOSS/WSS 3 landscape.

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 ;)

Recently, I had a lot of trouble configuring InfoPath Forms Services in MOSS to handle a browser enabled form.

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’
  

After installation of the Reporting Services Add-in you may find that the “Reporting Services” section is missing in the site administration Application Management page.

Reporting services logs information to a log file in the “%temp% directory” for the user who is installed the Reporting Services Add-in, the file name is RS_SP_<number>.log. 

Check for an error activating the ReportServer Feature in the Central Administration:

******* User does not have permission to add feature to site collection: http://machinename:8080

This is because you are accessing the site using an account which does not have high enough permission, even though it may already be in the Site Administrators & Site Collection Administrators lists. Try logging in with an enterprise administration account.
Once you have logged in with a suitable account you will see Site Administration & Site Collection Administration in the site settings page: 

1. Go to SharePoint 3.0 Central Administration.
2. Select Site Actions -> Site Settings
3. Under the Site Collection Administration section click Site Collection Features
4. Activate the Report Server Integration Feature in the list

You will then see a Reporting Services section appear in the Site Settings page as well as the Application Management page.

Although you can have many views in a library (don't know the exact limit yet but I have 82 so far), it seems that the library/list 'edit shared webpart' view selector dropdown only displays 47 custom views plus the 4 defaults.
I guess I'm going to have to try to find a way to change that limit....

Oh, and the list of views available in the dropdown aren't sorted alphabetically.

There's also an annoying bug that when editing the current view and clicking ok, you are thrown back to the published page and the settings for the toolbar have defaulted to 'full toolbar' even if you have previously specified summary or no toolbar.  <sigh>

I recently had problems when trying to access a webservice installed on a web site in IIS 6.0. When browsing to the web service at http://server/webservice.asmx I recieved:

"Server Application Unavailable

The web application you are attempting to access on this web server is currently unavailable.  Please hit the "Refresh" button in your web browser to retry your request."

The application event log returned two errors:

I found various references related to "Failed to initialize the AppDomain:/LM/W3SVC/2079486950/Root"

One of which suggested that the error lay with .Net not having been registered with IIS.

To solve this, navigate to your .NET directory (something like C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) in a command prompt and run the command  aspnet_regiis.exe -i  which will register ASP.NET with IIS

However - this returned an error: "The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible."

D.oH! wrong directory for the .Net Framework - we are on a 64bit server after all - try in cmd:

and you should then see...

Start installing ASP.NET (2.0.50727).

..............................

Finished installing ASP.NET (2.0.50727).

Then...still no joy. Tried an iisreset without success.

So...More googling for:

 "Failed to execute request because the App-Domain could not be created. Error:

0x80070005 Access is denied."

... revealed (damn! you have to love google!) a post by dclaassen which suggested permissions at the website root...

So, as instructed I tried adding the Network Service account with read permissions to the website root folder and... voila! :)

When trying to access the Shared Services Provider Search Settings on a newly restored farm (http://server:54321/ssp/admin/_layouts/searchsspsettings.aspx) I'm getting the following error:

'Exception from HRESULT: 0x80040D23'

This initial error corresponds to an application event log:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date:  2008-01-09
Time:  11:04:49
User:  N/A
Computer: <SERVERNAME>
Description:
Ett undantagsfel uppstod för körningsmetoden för jobbdefinitionen Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 6acb7104-0309-459f-aebb-55003e90a509). Mer information finns nedan.

Exception from HRESULT: 0x80040D23

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

Uncommonly the Help & Support Center actually has a related article: Event ID 6398 Timer JobsURL: http://technet2.microsoft.com/windowsserver/WSS/en/library/76736512-efb5-406c-9ae9-ef619393f3ad1033.mspx 

However, this didn't offer any resolution - using the repair function did nothing.

Error 183: Cannot create a file when that file already exists.

The Application event log then showed an information event (ID: 1013) saying that the search service had terminated normally. Then shortly after the same Event ID: 6398 - Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 6acb7104-0309-459f-aebb-55003e90a509).

Additionally another error, also related to the 'Exception from HRESULT: 0x80040D23' :

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Delade tjänster för Office Server
Event ID: 6482
Date:  2008-01-09
Time:  11:40:49
User:  N/A
Computer: AVENLNDSRV010
Description:
Programserveradministrationsjobbet misslyckades för tjänstinstansen Microsoft.Office.Server.Search.Administration.SearchServiceInstance (4aa10976-553a-4176-a302-2c3337637d6d).

Orsak: Exception from HRESULT: 0x80040D23

Information om teknisk support:
System.Runtime.InteropServices.COMException (0x80040D23): Exception from HRESULT: 0x80040D23
   at Microsoft.Office.Server.Search.Administration.MSSITLB.IGatherManagerAdmin3.get_ConfigurationVersion()
   at Microsoft.Office.Server.Search.Administration.Gatherer.ProvisionGlobalProperties()
   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

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

I checked the permissions on the databases and the account used for the search services was a db owner. It wasn't until I set the permissions for the services to be the system account (as opposed to a separate account for the search) that the SSP Search Settings became available again.
Worryingly, somewhere in the restore process the permissions have been messed up. Time for further testing & re-identifying the roles and permissions for the admin accounts. 

During a client installation I came accross a stumbling block when trying to map a UNC path to a WSS 3.0 document library.

The issue was that I need to batch copy files from one server share directly into a WSS 3.0 document library via the windows explorer view (UNC path).
However, while this works like a charm from Windows XP, doing this from a w2k3 server to another w2k3 server is problematic.
Having tried adding the UNC path mapping using command line: Net use X: \\Server\Site\DocLib, and via windows explorer mapping to: \\Server\Site\DocLib , both returned the error:

System error 67 has occurred. The network name cannot be found.

Since the other common way of accessing this, using the document library GUI and using the Actions > Open with Windows Explorer, failed to activate (as I thought due to the default IE lockdown on a w2k3 server), the following have also been set:

* The user account is a site owner in WWS 3.0 and is in the Power User group on the web server.
* Default IE security lockdown has been disabled on the w2k3 server
* All Active X controlls have been enabled
* The site is in a trusted zone

Still no joy.

After some head scratching & further investigation and eventually resorting to the 'phone a friend' option I was relieved to find that the answer was a reltively simple one:

Start the Web Client Service under services and set it to startmode automatic.

You've installed the PDF iFilter on the server and registered the dll.... you've added the icon to the images folder and the reference to the xml file... you've added the file type in the Shared Services provider Search Settings... you've run the full search indexing for the portal...

...the icon for pdf will display correctly in lists & libraries....but you *still* don't get pdf documents appearing search results??

You wouldn't happen to be running a 64bit server for SharePoint or SQL ??

If you are then there's some bad news for you. Adobe have not yet released a 64bit version of the iFilter for PDF. And while the 32bit version installs without error you will not get any results appearing in the SharePoint search.
As yet Adobe have not announced when (or even if) they will release this.

In the meantime there is an alternative.... Use this 64bit iFIlter from Foxit Software

Note: the installer does not register the application with MOSS 2007. After installing you will need to manually add a pdf extension in the registry settings:

  1. Open regedit and locate the following:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\<SiteID>\Gather\Search\Extensions\ExtensionList]
  2. Add a new String value with the latest number in the sequence and edit it to add pdf as the Value data.

Then, check that the pdf file type shows in the portal Shared Services Administration:
  1.  Under Search click Search Settings
  2.  Under Crawl Settings click File Types

If not then add it:
  1.  Click New File Type and add pdf

Incidentally, this will add the following reference for the pdf file type in the registry:
  1. Open regedit, locate [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf] 
  2. Check the default value is {987f8d1a-26e6-4554-b007-6b20e2680632}

Check also that you have the .gif file that you want to use for the pfd icon in the following folder on the server: 
  Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Images

(the icon can be found here (use the 17 x 17 one): http://www.adobe.com/misc/linking.html)
Then: 
  1. Edit the Docicon.xml file to include the .pdf extension. To do so: 
      Start Notepad, and then open the Docicon.xml file here: Drive:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\Xml 
  2.  Add an entry for the .pdf extension. For example, where NameofIconFile is the name of the .gif file: <Mapping Key="pdf" Value="NameofIconFile.gif"/> 
  3.  On the File menu, click Save, and then quit Notepad. 

Next - REBOOT THE SERVER! (Before doing this there were a few minutes frustration. Simply stopping & starting the services, iisreset etc is not sufficient)

When rebooted go back to the portal Shared Services Administration and start a full crawl:
  1. Under Crawl Settings click Content sources and Crawl Schedules
  2. Click the arrow icon next to your Shared Service (Default name is: Local Office SharePoint Server Sites) and select Start Full Crawl

We've recently been messing about with the CRM & MOSS integration features, and while the initial setup of the MOSS farm on Kerberos authentication wasn't the most straightforward we are now getting issues when trying to conect two CRM webparts for filtering. This doesn't happen if we connect a regular web part with a CRM list web part. It happens only between two CRM list web parts. 

The target webpart returns the following error:

"An error has occurred. This Web part could not be displayed. ERROR [42000] [Microsoft][ODBC SQL Server Driver][SQL Server]Conversion failed when converting from a character string to uniqueidentifier"

 As an additional part of this error, on refreshing the page or trying to redefine the filter, the target webpart for the filtering also returns the following:

When using the content editor web part, in some cases you can receive the following message when editing the content, or saving the content: "cannot retrieve properties at this time".

This exact error suddenly appeared on a client installation after https access was enabled via ISA server. Prior to that the content editor web parts worked normally over http. When browsing the site using the server name there is no problem. The issue therefore lies with the https translation.
The sites alternate access mappings are configured with the https url as an extranet. Changing this to any of the other options makes no difference.

Mart Muller refers to a MS KB article in his post here however I'm not sure this is correct. Neither of the two supposed causes are applicable in this case:

Further investigation ongoing...

I'm not one to complain, but...

[rant]

Yet again I find that one of the most intuitive, flexible site templates is hobbled for no good reason. Why on earth is the Multipage Meeting Workspace so restricted compared to the Team Site???

To begin with, lets take the function for 'save site as a template'....
- Team Site - 'save site as template' allows for inclusion of content. Great, nice one, useful feature that.
- Multipage Meeting Workspace - 'save site as template' DOES NOT allow for inclusion of content. WTF?? why on earth should I be restricted in this site?? maybe some people use this template for other things than meetings because we find the page tab layout extremely useful. This was a problem in 2003, why the hell hasn't it been fixed in 2007??

And then today I discovered another shortcoming that may not be quite so apparent. The new 2007 feature 'Send to location'...
- Team Site - document: Send to > Other location, add location (by typing instead of a browse function, hello? is this 2007??), send - file is copied. Ok. 
- Multipage Meeting Workspace - document: Send to > Other location, add location (grr), send - ERROR! "There were errors copying to this location. The destination is in a meeting workspace, which does not support this action."  DoH!!
I'm speechless. No, really.
Hello!!?? is there any light on in the MOSS development office??? WHY is this not possible in the Multipage Meeting Workspace site??? For what possible reason would I not want this feature available in this site template???

And do you know how I discovered this?? In testing the workflow features of SharePoint Designer in a Multipage Meeting Workspace site.

cue..

[subrant]

Somehow the development team for SharePoint Designer forgot to include the workflow function to allow MOVE document from one location to another. Instead you have to COPY the document to the destination location and then DELETE the original!!

Words begin to fail me at this point. Why on earth was this feature overlooked?? 9 times out of 10 a user will probably want to move a document rather than duplicate it. Surely this can't have been difficult for the development team to include??

Now I have to deal with a substandard method for getting a document from one location to another and finding that the DELETE step in the custom workflow causes the document in the target location as well as the origin location to be deleted!! Probably because this is a, you guessed it... Multipage Meeting Workspace site.

[/subrant]

And in case you're wondering, yes, the workflow function for copying a document from one location to another on a Multipage Meeting Workspace site works even though you can't do it via the drop menu 'Send to > Other location' options in the library!!!  o_0

[/rant]

This one has been resurrected from the collection of post-crash blogs:

How is it possible to connect metadata/column information to Word documents stored in a WSS 3.0 library so that it is synchronised both ways??

Also referenced in the MS Office Word Team blog adding links between Word & MOSS metadata/columns is simple enough to do, but one thing appears to be missing....
Easily implemented for custom metadata and a few defaults, however 'Version' (as in the version number created by doc libs, both minor & major) doesn't seem to be available? Only Revision number which isn't the same. Or am I missing something?

Surely this is one of the more important columns that users may wish to include in a document header. How can this be added??

Finally, after trawling through endless forums & posts I find a blog by Joerg Sinemus describing exactly what I want to achieve. Though by no means a simple solution: http://blogs.msdn.com/joerg_sinemus/archive/2007/01/26/wss-version-number-in-the-word-2003-document.aspx

A great post, but surely there is an easier way to do this in MOSS / Word??

The bigger questions is perhaps: why on earth wasn't this feature included in the WSS 3.0/Word integration options by default??!!! After all, once a document is in library you can connect any custom metadata using the Quick Parts as well as some defaults. So why not Version?? it's possibly one of the most often used items in word headers.

So was this a serious lack of foresight on the part of the MOSS development team? or just too complicated to get into this release?

The Microsoft Information Worker Solutions Competency is changing to reflect the enhanced capabilities of the 2007 Microsoft Office system and Microsoft Exchange Server 2007. The program will now be made up of nine specializations that have been designed to help you better position yourself to build today's most in-demand business solutions-and capitalize on some of the fastest-growing market-segment opportunities.

As a partner who is active in the "Office System Desktop Deployment" and/or "Office Smart Client" specialization in the Information Worker Solutions Competency, we want to inform you that the names of these specializations are being changed and the list of qualifying exams is being expanded to include the new Microsoft Office 2007 products. Please be assured that these changes require no action on your part and your benefits will continue without interruption.

Please refer to the table below for more information about the new specialization names.

View transition details for the 2007 Information Worker Solutions Competency

View exam requirements for the 2007 Information Worker Solutions Competency