Tommy Segoro

INTRODUCTION

I got this error message when I tried to create a site using my custom site definition:

The template you have chosen is invalid or cannot be found.

SOLUTION

The problem is, on my custom WebTemp file I use an ID which has been used by other custom site definitions I developed previously. See below.

<Template Name="MYCUSTOMSITEDEF" ID="91111">

<Configuration ID="0" ….. /></Configuration>

</Template>

I'm wandering if there is a tool out there that can check whether a particular ID has been used or not. It will be very-very handy if you have to develop so many custom site definitions.

Cheers,
Tommy

INTRODUCTION

I'm currently working with a 5-server farm Sharepoint installation:
- 1 Central Admin
- 1 Search Indexer
- 2 Web Front End
- 1 Database

For several months the document libraries which have "incoming e-mail settings" specified never receive email any more. The SMTP service is installed on the Central Admin server.

THE PROBLEM

When I troubleshooted the issue, I noticed that the emails were sent to the drop box successfully but somehow the Sharepoint Timer never grabs and delivers them. I've looked at several things including:
- Checking if WSS_ADMIN_WPG and WSS_WPG have write access to the Drop folder
- Checking if WSS_ADMIN_WPG and WSS_WPG have administrator access to the SMTP server
- Checking if email relay is opened for anonymous
- Checking timer service jobs in Central Admin for unfinished tasks

When checking the timer service jobs I noticed no errors. Every task was finished successfully.

I then looked in the log files and there are no errors specifying the email service. So what is then the problem?

After I looked more closely, the Sharepoint Incoming Mail service was actually run on the two web front-end servers and not the Central Admin server. The email address of the library is set to the Central Admin domain (eg. LIST@CentralAdminServer.com) and the emails are correctly dropped into the Drop folder of the central admin server but the Sharepoint Incoming Mail service actually looks for the Drop folder in the two web front-end servers! Since those emails are not copied automatically from the Drop folder of Central Admin server to the WFE servers, they never get delivered at all!

SOLUTION

The solution of this problem that I could think of was to create a simple File Watcher application that automatically copies all new files from the Drop folder of Central Admin server to the two web-front-end servers and now incoming email is working.

Hope this post helps everyone who has the same problem.

Cheers,
Tommy

INTRODUCTION

This is the second part of the series. For first part please go to /tommysegoro/archive/2008/11/21/why-sharepoint-development-projects-failed-part-1.aspx.

WHY FAILED 2: DESIGN PATTERNS, TOO HIGHLY COMPLICATED ARCHITECTURAL PERSONNEL

The second reason why Sharepoint development failed is because of the conservative-design-patterns-centric-who-always-thinks-that-design-pattern-and-thousand-layered-development-is-the-best-way-to-go type of senior developer. To be honest, I also came from a custom development background and yes, with custom development you are actually expected to understand and apply design patterns to your application. However, with Sharepoint, it's kinda different. Put it this way, the way Sharepoint project is structured is already different altogether. I can say that I'm actually not a Sharepoint developer but a Sharepoint customizer instead because that's what I do: customizing Sharepoint.

A lot of developers that I met before tried to apply these design patterns (MVC, MVP, etc) to a Sharepoint application and it ends up making it too complicated for everyone. Sharepoint is even utilising content database to store ASPX, master pages and user controls. Yes, of course with the solution template (http://www.codeplex.com/vs2008sp, WSPBuilder, STSDEV, etc) you can develop everything in Visual Studio. However, the project structure is so different. Although you can still apply MVC, MVP, etc but if we're looking closely on our project management timeline, there is no way that we'll meet our deadline using design-pattern approach. Don't get me wrong, design pattern is one of my passions in development.

Customizing Sharepoint should be straight forward. Even if you work with its framework, it is already quiet complicated altogether (hence Sharepoint knowledge shortage). To be honest, I personally don't find Sharepoint is as hard as custom application. In fact I spend a lot less time customizing Sharepoint. If I have to build my CompleteSharepoint.NET (http://www.completesharepoint.net) application (which is a simpler version of MOSS-like CMS built on top of WSS 3.0) using custom .NET application, it will take me twice-three times longer. A lot of the stuff is already built in (lists, document libaries, versioning, etc) and we just need to work with them. The SDK is also already built in, you don't have to build your own data access layer, etc.

In a nutshell, we just need to know where everything are and where to deploy our files into and that's pretty much it!

CONCLUSION

Therefore, my lesson for myself when developing Sharepoint is, "it's already complicated, don't make it more complicated". Seriously, MVC and MVP just won't work with Sharepoint. I don't need to apply any design patterns (and loosely-coupled type of code) to maintain and share my code with my team easily.

Well, at least that's my point of view.

INTRODUCTION

In this opportunity I would like to share with you on why Sharepoint development projects failed. This will be based purely on my knowledge and experience therefore I would love to hear your comments and sharings, too.

TARGET AUDIENCE

The target audience of this series are developers, BDMs and project managers.

WHY FAILED 1: INADEQUATE KNOWLEDGE ON SHAREPOINT

The first reason why Sharepoint projects failed is because of inadequate knowledge on Sharepoint. When I say "failed" it means that the project either doesn't meet client requirements at all or it does meet client requirements but then it's gone over budget and over the given deadlines and time frames.

A lot of project managers, BDMs and sales people are offering Sharepoint to clients simply because they buy into the hype. Just because Microsoft says that Sharepoint can do this and that (be it document management, internet or intranet applications) it doesn't mean that you have to use it as a solution. A lot of people just haven't realised how complicated Sharepoint is – or I should restructure the words better – a lot of people don't realise what it takes to customise Sharepoint yet they have started to offer it to clients. At the end of the day the project either goes over budget or meeting a brick wall (ie. can't find an easy way out to find a solution for particular client requirements) or it doesn't meet the client expectations at all.

I've tried to build my own custom solution on top of Windows Sharepoint Services 3.0 called CompleteSharepoint.NET and it's a simple web content management system as a replacement of MOSS. Since I developed it, I get to understand Sharepoint more and more and now I know what it takes to customise Sharepoint. Yes, it's a development platform more than just a product, yes you can build custom applications on top of it but you also need to know what it takes to make it happen.

When Sharepoint project failed people then blame it for its complexity. I never know such thing is complicated if you have a solid understanding on what it does and I feel sorry for Sharepoint (and Microsoft) because they get blamed so many times yet it's not their fault. Every product has its own advantages and disadvantages, strengths and weaknesses. Sharepoint is also the same, you will only benefit from it if you can maximise the strengths and cope with the weaknesses.

My personal recommendation is (before you even select Sharepoint as a solution offering), get to know the product first. Make sure you've consulted with a Sharepoint expert and make sure that what you want can be achieved with Sharepoint. For example, a BDM may have a lot of experience in document management system. He of course knows what DMS system should have (ie. the features). He should then consult to a Sharepoint expert whether these features either come out-of-the-box with Sharepoint or can be developed on top of easily.

When you have a quiet solid understanding of how Sharepoint works and what the features are, you can then be more comfortable offering it to clients. I always like this phrase, "It's better not to start anything rather than starting something and not finishing it well". A good leader is someone who finish what he has started and he finishes it well.

CONCLUSION

A good salesman will know his product. I can't tell you how good Carbonara Pasta is if I never try it myself. I can't tell clients how good Sharepoint is if I don't even have an adequate knowledge of what it does and what it can do.

INTRODUCTION

Hi everyone, I've just written a content management system on top of WSS 3.0. I'm utilising my solution template and I've provided the source code for free. Please go to http://www.completesharepoint.net. I tried to mimic MOSS 2007 functionalities but in their simpler version. It has page editing toolbar, custom page layout, custom publishing content type, etc. Please have a look on the screenshots below:

Please note that this is still in beta mode. You can download the source code but you will find so many things that can be improved. Thanks everyone I hope to hear some feedback.

Page Editing Toolbar

Editing a Page

Creating a Publishing Page

Custom Site Actions Menu

INTRODUCTION

Continuing from my previous post /tommysegoro/archive/2008/09/14/sharepoint-solution-syntax.aspx I will discuss further on the syntax required for creating other elements of Sharepoint. In my previous posting, I've mentioned to you about how to create site definition, master pages, page layouts, content types and fields using feature. In this posting, I will mention about creating web parts, event receivers and feature receivers.

WEB PARTS

To create web parts you will need the following structure:

Inside HelloWorldWebPart.webpart you have:

<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
<metaData>
<type name="WSPBuilder.WebParts.HelloWorldWebPart, WSPBuilder, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6109cdf7233db6c5" />
<importErrorMessage>Cannot import this Web Part.</importErrorMessage>
</metaData>
<data>
<properties>
<!– standard Web Part properties –>
<property name="ChromeType" type="chrometype">Default</property>
<property name="Title" type="string">Hello World Web Part</property>
<property name="Description" type="string">Use to create classic Hello World excitement</property>
<property name="CatalogIconImageUrl" type="string">/_layouts/images/IMAGE.GIF</property>
</properties>
</data>
</webPart>
</webParts>

Inside Elements.XML:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="WSPBuilderWebParts"
List="113"
Url="_catalogs/wp"
Path="dwp"
RootWebOnly="true">
<File Url="HelloWorldWebPart.webpart" Type="GhostableInLibrary" >
<Property Name="Group" Value="WSPBuilder Web Parts" />
</File>
</Module>
</Elements>

Inside Feature.xml:

<Feature
Id="8E7D1D5E-4A07-4857-AD5A-EAC3D1A20391"
Title="WSPBuilder Web Parts"
Description=""
Hidden="FALSE"
Scope="Site"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml"/>
</ElementManifests>
</Feature>

FEATURE RECEIVERS

For feature receivers you will need the following syntax:

Inside Feature.xml:

<!– _lcid="1033" _version="12.0.4518" _dal="1" –>
<!– _LocalBinding –>
<Feature Id="6873B8E8-848D-461d-9494-9422E354AE6B"
Title="Test Site Feature Receiver"
Description="This is the feature that sets the CompleteSharepoint.NET publishing lists without approval."
Version="1.0.0.0"
Scope="Web"
Hidden="False"
DefaultResourceFile="core"
ReceiverAssembly="SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a829755eafa973db"
ReceiverClass="SPTemplateLand.FeatureReceivers.MyFeatureReceiver"
xmlns="http://schemas.microsoft.com/sharepoint/">
</Feature>

You will then need to create your feature receiver class.

EVENT RECEIVERS

With event receiver, you need to have the following syntax:

The first feature is the feature that deploys your custom list. You can get the syntax from CustomList feature that Microsoft has deployed inside the FEATURE folder of your 12 hive.

Inside Feature.XML:

<?xml version="1.0" encoding="utf-8"?>
<Feature Id="EAD2A016-DB17-4f7b-94CE-A3EC6CF5D815"
Title="My Custom List Feature"
Description=""
Version="1.0.0.0"
Scope="Web"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="CustomList.xml" />
</ElementManifests>
</Feature>

Inside CustomList.XML (note the Type property):

The second feature is then the feature that deploys the Event Receiver feature.

Inside Feature.XML:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="9EF6A5A1-AF0A-494e-BB78-93BA3730E6EC"
Title="Custom List Event Receiver"
Description="An Event handler that supports the addition/modification/deletion of list items throughout various sites in the collection."
Version="1.0.0.0"
Hidden="FALSE"
Scope="Web"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="Elements.xml"/>
</ElementManifests>
</Feature>

Inside Elements.xml (note the ListTemplateId and the Type property of the event):

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Receivers ListTemplateId="10050">
<Receiver>
<Name>SPTemplateLandEventReceivers</Name>
<Type>ItemDeleted</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ea47656c35c3a98</Assembly>
<Class>SPTemplateLand.EventReceivers.CustomListEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
<Receiver>
<Name>SPTemplateLandEventReceivers</Name>
<Type>ItemUpdated</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ea47656c35c3a98</Assembly>
<Class>SPTemplateLand.EventReceivers.CustomListEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
<Receiver>
<Name>SPTemplateLandEventReceivers</Name>
<Type>ItemAdded</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ea47656c35c3a98</Assembly>
<Class>SPTemplateLand.EventReceivers.CustomListEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
</Receivers>
</Elements>

You will then need to build your custom event receiver class that inherits from SPItemEventReceiver.

CONCLUSION

So there you go. Hope this helps. To be continued.

INTRODUCTION

Hello hello…I've said in my last post /tommysegoro/archive/2008/09/25/sharepoint-team-development-with-visual-studio-part-3.aspx that that post was going to be the last post in this series. But I actually lied!

In this post I will focus more on the tools. I've played around with another 2 tools: SPTemplateLand and WSPBuilder and in this post I will list the advantages and disadvantages of using both tools (once again these are only based from my experience). So please agree/disagree with me. Thanks.

TOOLS AND MORE TOOLS

I just tried 2 new tools for generating features and solutions for me: SPTemplateLand (http://www.codeplex.com/sptemplateland) and WSPBuilder (http://www.codeplex.com/wspbuilder). Both are excellent tools to generate the solution file automatically.

I will start with SPTemplateLand first.

SPTEMPLATELAND (http://www.codeplex.com/sptemplateland)

Advantages:
- Generation of the WSP file automatically.
- Simple yet fulfilling the purpose.
- Not relying on any executables for it to run.
- Easy to modify for any projects.
- Deploy files to the correct location.

Disadvantages:
- No Visual Studio built-in commands.
- You have to have at least one feature definition in your project otherwise the manifest.xml will not render correctly and you won't be able to add your solution to Sharepoint using the STSADM command.
- If you want to deploy your DLL to GAC, you have to copy it manually inside the DLL folder.
- No batch scripts by default so you have to remember the STSADM syntax for installing, deploying and upgrading the solution.
- Key.snk is not part of the solution so you have to create and sign your assembly manually.
- No reference to Microsoft.Sharepoint and System.Web automatically. You have to add them manually.

In general, I like this solution template as it's very simple and yet fulfilling its purpose to generate and deploy WSP automatically. Things that I mention in the Disadvantages section are not really major. They of course will be improved in future versions hopefully.

WSPBUILDER (http://www.codeplex.com/wspbuilder)

Advantages:
- Built-in Visual Studio project template. It's very nice to have a project which namespace and assembly names have been automatically-generated based on the project name.
- Yet still quiet simple to use.
- Deploy files correctly to the correct location.
- Key for signing your assembly is now part of your project.

Disadvantages:
- Relying on the executable.
- No Visual Studio built-in commands.
- Config file may be confusing. There are so many options that you can enable/disable and the documentation is rather not clear. 
- Doesn't have any batch scripts so you have to remember the STSADM commands for installing, deploying and upgrading your solution. You may also need to add your WSPBuilder.exe to the PATH environment variables so you can run it from anywhere within your folder.
- No reference to Microsoft.Sharepoint and System.Web automatically. You have to add them manually.

CONCLUSION

So there are just some of my findings with those tools. I've got nothing to against any of these tools. If they've been working for you then please keep using them. I kept saying this over and over again, it doesn't matter what tools you use as long as they can help you deploying your solutions and features automatically.

I've also created my own please go to http://www.codeplex.com/vs2008sp which is kinda similar with the tools I've mentioned above except it has built-in Visual Studio build commands.

Do you know that the "URL" property of the Schema.XML on your custom list definition can make the version selection in your Office applications disappearing when you're trying to check-in your document?

OOTB it should be:

But an incorrect URL property in the SCHEMA.XML will cause it to look like below:

The version selection somehow disappears!

So what's the problem? The problem is this:

<List Name="My Custom Documents" Title="My Custom Documents" Description="" Direction="0" BaseType="1" Url="Lists/MyCustomDocuments" ………

You can NOT have the word "Lists" in the URL.

Same with your list instance in your Elements.XML (if you deploy your custom list using feature):

<ListInstance FeatureId="6E99D423-7EB9-4FD3-9654-DAC0B96C1827"
Title="My Custom Documents"
TemplateType="101"
Url="Lists/MyCustomDocuments" />

Remove the word "Lists" from the URL so it becomes:

<ListInstance FeatureId="6E99D423-7EB9-4FD3-9654-DAC0B96C1827"
Title="My Custom Documents"
TemplateType="101"
Url="MyCustomDocuments" />

Fiuh…I spent hours trying to fix this.

Hope this helps.

Tommy Segoro

This is the third and last part of Sharepoint Development using Visual Studio series. For previous part:
/tommysegoro/archive/2008/09/04/sharepoint-team-development-with-visual-studio-part-2.aspx

Note: Just change the part-x bit to go to the other series of this posting. 

INTRODUCTION

I've shared to you about the different Sharepoint project types, the development methodology approach and the tools. In this particular posting I will share to you on how to plan your Sharepoint development. I've talked a bit about this in my previous posting about how you should plan your content types and fields first. Sure, requirements change but at least you reduce your "headache" if you can get as much content types and fields done as possible. In this particular posting I will share to you on how I normally approach the site creation, the implementation of features, etc.

THE TOOLS

Once again I will repeat this over and over again: You HAVE TO utilise solution and features deployment for team development. Please find on my previous post regarding the tools I've used. Anyway, I will use my own solution template for creating solutions and features on my examples/projects. Please download from http://www.codeplex.com/vs2008sp.

SITE CREATION

Personally I will go down the custom site definition path. I will not modify OOTB site definition (eg. modifying STS's ONET.XML directly) because when you start modifying OOTB files, they may get overridden by service packs or patches that Microsoft releases. With custom site definition, too you can select what features to be activated upon creating a new site, what files to appear, etc which makes sense for me.

My fellow Sharepoint developer mentioned to me before that he prefers to use PowerShell to activate the features because he can see whether feature activation succeeds or not rather than you create your site first then getting an error message. If any of you uses PowerShell to create your site/activate your features, can you please share your experience? Anyway, I personally will go down the custom site definition path because it's easier for me to categorise which site will use what features, which site use what pages, what lists to instanstiate, etc. See example below of my custom ONET.XML:

<Configuration ID="1" Name="Blank">
<Lists>
<List FeatureId="00BFEA71-2062-426C-90BF-714C59600103" Type="103" Title="Page Order" Url="Lists/Page Order" />
</Lists>

<Modules>
<Module Name="DefaultBlank" />
</Modules>

<SiteFeatures>
<!– BasicWebParts Feature –>
<Feature ID="00BFEA71-1C5E-4A24-B310-BA51C3EB7A57" />
<!– Three-state Workflow Feature –>
<Feature ID="FDE5D850-671E-4143-950A-87B473922DC7" />
</SiteFeatures>

<WebFeatures>

<!– CUSTOM FEATURE –>
<!– SITE ACTIONS –>
<Feature ID="69CCBDEB-6B71-4fb6-9A2E-93EBB8D792D8" />

<!– PUBLISHING LISTS CREATION –>
<Feature ID="67A06416-3D36-44c9-8980-F10FA0181B27" />

<!– SET PUBLISHING LIST WITHOUT APPROVAL –>
<Feature ID="6873B8E8-848D-461d-9494-9422E354AE6B" />
<!– MASTER PAGES –>
<Feature ID="5522E091-66EA-40e8-9C62-D08861A96225" />
<!– MODIFY NAVIGATION –>
<Feature ID="2F74B5BA-BDA9-435d-84DC-DF3CA1E741A2" />

<Feature ID="00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5" />
<!– TeamCollab Feature –>
<Feature ID="F41CC668-37E5-4743-B4A8-74D1DB3FD8A4" />
<!– MobilityRedirect –> <!– CUSTOM FEATURES –>
<!– Content Type Binding –>
<Feature ID="678C0C06-1053-455b-8767-867B6B37EA75" />
</WebFeatures>
</Configuration>

Therefore, when I need to create a particular site that will require particular features to be activated, I can easily go to Site Actions -> Create Site and create a site that uses my custom site definition and it will then have the correct activated features.

For creating custom site definition I always start from the OOTB ones. To create WSS-related site definitions, start from STS. For Collaboration Portal starts from SPS and for MOSS Publishing starts from BLANKINTERNET.

THE PROJECT

I personally will divide the project into 3 sub-projects:
- Features
- UI
- DLL

The Features project will contain feature-related stuff (except features that deploy UI such as master pages, CSS, page layouts and javascripts). So in this project you will have features that contain feature receivers, features that deploy web parts, features that deploy content types and columns, etc.

The UI project will contain UI-related stuff such as feature that deploys master pages and page layouts, feature that deploys images, CSS and javascripts.

The DLL project contains all code-behind related stuff (feature receivers, event receivers, custom fields, user controls, web-part code, etc). Why I divide the code into a separate project? It's because when you're deploying the DLL it won't affect the other elements (eg. Features and UI). The other elements will still run as normal yet you can deploy as many changes to your code as possible.

UI ELEMENTS

I will deploy CSS and images that are related to the UI directly on file system using feature. I will not upload images that are related to UI to Sharepoint image library. The reason is, when it comes to updating them, it's very-very easy and quick to re-deploy a new set of CSS, javascripts or images to a file system rather than uploading those files to Sharepoint.

For master pages and page layouts, I will also move away from using Sharepoint Designer and I will NOT un-ghost them. Updating them will be very easy and they can be source controlled using TFS/VSS if you're not using Sharepoint Designer to update them. When you want to update them, you can just re-deploy your UI project and it will upgrade all of your master pages and page layouts in the file system.

CUSTOM PAGES FOR DISPLAYING NON-SHAREPOINT INFORMATION

Let's say you need to display information from your MS CRM but in the context of Sharepoint (and inheriting the Sharepoint permission for viewing that page, etc), I will personally go down the custom page layout (or application page path). This way you can then code your page to use Sharepoint permission. In your Sharepoint custom page you can then have user controls that will display information from MS CRM.

Example: http://myintranet/Pages/ViewCustomer.aspx or http://myintranet/_layouts/ViewAdmin.aspx.

TESTING

Various testings can also be executed on a Sharepoint application (same as usual custom applications). With unit testing however, you will need to have Sharepoint installed on your machine because stuff like retrieving list item from a list, etc will require you to connect to a Sharepoint list. When I divide my projects into those 3 categories, I can easily test the DLL project without even deploying my UI and my Features (although I will need to have the actual list to be created on my Sharepoint site if I need to retrieve items from it).

DEVELOPMENT PROCESS

The development process can be the same per general custom application development. With those 3 sub-projects I have, I can check-in check-out files/features/user controls/master pages, etc and my fellow developers can then get latest and run Install/Upgrade and he will suddenly have the latest files on his Sharepoint site. That's the beauty of solution and feature deployment. It allows you to do team development.

BUILD and UAT PROCESS

The build and UAT process can also be the same as per general custom application development. I can use TFS (or other tool) to build my 3 sub-projects, deploy the features/solutions to the Test server then I can run Install/Upgrade script. The Sharepoint site on the Test server will then have the latest features and files installed.

CONCLUSION

So this will be the end of the team development series hope that you enjoy reading them and please share your experience. The team development process may take more time than just modifying things directly through the Sharepoint GUI but it's worth it. It will make your code maintenance a lot easier, it also allows you to perform code review (making sure that everyone is on the same page in terms of writing feature, code and solutions) and updating/upgrading your files will be a lot easier.

To download sample code please go to http://www.smallbusinesshosting.com.au/SampleProject.zip.

Cheers.

INTRODUCTION

I'm currently working at a client where they haven't got SP1 installed and the environment hasn't been setup correctly. Somehow this service crashes all the time.

THE WORK AROUND

The work around to this problem is for me to create a batch script which I then call through Windows Scheduled Task. I schedule the WST to run this script every 10 minutes.

The content of the script is very-very little:

net start "Windows Sharepoint Services Timer"

That's it! At least the timer service has been running stable because every time it crashes, it's automatically started by the script.

Hope this helps,
Tommy