Content deployment (PRIME) still frustratingly buggy

Right now im investigating content deployment options at a client and even after all the infrastructure updates content deployment seems to be buggy still. Its not the fact that its just buggy, its also highly unpredictable.

Sometimes content-types just dissapear in the destination site, or the import/export gives randomly access denied on files while importing.

Its very frustrating to fallback on features & provisioning by code. I wish MS fixed and stabilized their platform first before releasing 2010.

STSADM or any assembly loading terribly slow, behind firewall or VPC/VMWARE?

A small tip which i found here: http://www.dynasign.nl/blog/?p=9 

In short:
Apparently, when STSADM executes, it tries to load strong named assemblies which need to be verified against an authentication provider externally.  When your environment has bad network access or no network access, it waites for a timeout before continuing. Which makes provisioning your sites, or any STSADM commands very very slow.

If you dont need it, the trick is to edit your machine config and add:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled=”false”/>
    </runtime>
</configuration>

Check out this link for more info:
http://support.microsoft.com/default.aspx/kb/936707

Storing files externally in MOSS to bridge ECM requirements

For those who have been with me from the beginning know that I’ve spoken quite a lot about ECM CAS (Content Addressed Storage) & HSM systems and the lack of storing files externally (ON HSM systems for instance, or file systems) in MOSS. This was one of the major drawbacks in comparison with the top of the market ECM suppliers.

I’ve blogged a long time ago about the the External Storage API, which was back then called BLOB API. You can read more about CAS & HSM in my ECM series here.

Quite recently Pav Cherney wrote an article on TechNet on how to implement your own storage provider using the ISPExternalBinaryProvider interface. This excellent article explains in detail what you need to implement your own external storage API.

Go have a look at his article here.

More on the ISPExternalBinaryProvider interface:

Are you choosing the most efficient way for your SharePoint solutions? A look at CRM 4.0 and SharePoint.

Introduction

Now that SharePoint development becomes easier now the tools and MSDN documentation are up to date and available for everyone it seems that everyone is hammering away in SharePoint custom development. There are tons and tons of blogs explaining how to build your own functionality, custom workflows, forms, field controls and event-handlers. Which makes me wonder whether people are also considering other products of Microsoft stack to aid in there product development and reach their business goals. 

It seems that the complexity and extensibility of the SharePoint platform automatically justifies for developer code frenzy and resort to building custom applications or so called application templates on to SharePoint without considering for instance building MS CRM or CRM / WSS / SharePoint integrated solutions.

SharePoint and CRM 4.0

Now with coming CRM 4.0 with its new workflow and entity relationship features it becomes more attractive to build custom solutions in CRM. Especially for the applications that require complex workflows, entity ownership & sharing and relations between entities. What I have seen a lot of developers do with SharePoint is create applications on top of SharePoint and using the lists as an semi-related database. Create an set of event-handlers or workflow activities to set rights or ownership on items and for handling complex logic. Now this is not necessarily a bad way, but maybe it could have been done more efficient when using an product like CRM and integrating it with SharePoint or WSS.

Probably the best way to explain this is by having an example, the service request scenario:

A common requirement for a large intranet is to streamline and manage service requests coming from the users using the Intranet to support the Intranets governance model.

These service requests can vary from “I want to like to request an new project site” and ‘I want to report offensive or erroneous content” to simple ones like “I would like to retrieve a deleted document”.

When one has an large organization to support, the amount of daily service requests can become unmanageable without an proper service request process. Service requests need to be assigned to different people or teams and handled with a lot of user interaction.  In the past I have written elaborate custom functionality, complex workflows and endless forms to overcome this problem in SharePoint while nowadays this sort an similar functionality can easily be created in CRM. 

As an bonus CRM 4.0 provides out of the box functionality to create service requests, cases and find associated knowledge base items to handle the cases accordingly.

The only thing that needs to be written in order to integrate both parts is an web-part to publish the service request and track its status from CRM using CRM’s web-services.

By using this kind of integration you save a lot of development effort as oppose to building all functionality custom.

A couple of other exciting scenarios with CRM and SharePoint integration:

Governed project portal and site lifecycle management Creating an project in CRM, which triggers the creation of an project site in a governed taxonomy in the SharePoint environment and notifies users that the site has been created. When the project site’s documents are all passed for review, SharePoint triggers an event in CRM which updates the CRM entity that the project is finished and backups the site accordingly.  Because the status of the site is tracked in CRM, the CRM reporting functionality can be used to generate reports. Additionally, the site’s lifecycle policy  can be monitored and endorsed from CRM.
Custom CRM based user authentication Create an custom authentication provider for SharePoint that uses CRM as its back-end user-store to authenticate users. Providing functionality to manage SharePoint users for, for instance, an extranet, in CRM.
Employee time-off request application Users can request time off by filling in an form on SharePoint with creates an request in CRM, which can then be handled by an manager accordingly.
Service request and incident management Users can report incidents by filling in an form on SharePoint with creates entities in CRM with can be handled accordingly. Reporting can be done with SRS or from CRM.

When to choose what?

The most difficult question to answer is when to choose what development strategy when building this kind of business applications. There is no golden rule for as it largely depends on the situation and business need. To make matters worse both products tend to get more overlapping functionality.

For instance, you can store documents in CRM as attachments and without versioning, (of course it still doesn’t match SharePoint) and you can make your SharePoint applications look like CRM based applications such as presented in the “Microsoft 40 application templates” examples.

Apart from the obvious license and performance considerations there are some other facets one might consider.

Are you building an more database based application with complex workflows and relations between entities? Or more of an document or item repository with basic approval workflows? How big is the group of users that will use this application? When this functionality is build in CRM what impact will this have your CRM license model? Is it worth getting extra CRM CALs against building the application completely custom in SharePoint? What for an impact will building hybrid solutions have for your release management?

Probably the best way is to dive into both products and get a feel for them. Here are a couple of pointers to help you consider what development strategy to choose what when developing applications:

CRM only

  • When building large complex workflow or process intensive back-end solutions, for a select group of users go for a CRM solution as CRM provides a lot of configuration, workflow flexibility and options like team sharing, user-assignment and queues already out of the box.  
  • Furthermore, when you are basically creating an large application in SharePoint where the lists more or less start to look like relational databases an option might be to port it to CRM. Especially, when there is complex functionality like ownership of list-items and elaborate user permissions involved.

SharePoint only

  • Document storage based application and collaboration based solutions
  • Simple easy to develop workflows
  • Applications with simple entity relations and entities with limited changing ownership.
  • Large user base (for instance whole parts of the organization) that uses the application.

SharePoint and CRM hybrid applications

  • Back-end is a relatively small selective group of users, logic is complex and results into elaborate tracking of tasks and items.
  • Front-end need to be accessible by a large amount of users, everyone on the portal needs for instance be able to create new cases and entities in CRM using an created form.
  • Monitoring, managing and reporting needs to be done centrally.

Notes on CRM and SharePoint integration

Please note that Microsoft has plans to integrate SharePoint and CRM in its upcoming office release.

Also be sure to understand when writing to the CRM data model in any way such as web-services is only allowed when you have the CRM External Connector license.

SharePoint Designer Workflow (WSP) Packager source-code released!

Source-code on CodePlex!

Recently I got a lot of requests to release the source-code of the SharePoint designer workflow packager. My idea was to wait a bit until I got time to clean up the code and  to fix some bugs.  But since I am still traveling this could take a while.

If you find any bugs, please feel free to become a contributor and upload your fixes :-)

Check it out here at: http://spdtoolkit.codeplex.com/

Installation notes

Be aware that there are still a couple of bugs in the code, and remember that you need C# 3.5 to be installed on your server to run this.

I won’t recommend running this on production servers unless you are a 100% sure that it works.

What’s next?

Depending on the feedback I might extend the workflow packager but it all depends on Microsoft’s roadmap on Workflows for SharePoint’s Next Release. Personally, I think that MS will port the web-based CRM 4.0 workflow editor to SharePoint, or create shared functionality for it, which would supersede this tool. Until then, I try to keep it updated with bug-fixes.

SPD Workflow Packer Source Release (And why I am a bit quiet)

Hi all,

First off, my apologies!The reason for me not blogging lately is because I am traveling Australia and New Zealand and it’s a bit hard getting wireless in my camper.

However, I am releasing the source code for the workflow packaging tool as soon as I can find a place to put it.

Until then, look at my view :-)

PICT3493

PICT3280

Cheers,

Emile

I’m expected to be back and back to civilization in May :)

Common reasons why corporate Intranet implementations fail

As an contractor, I usually get hired when something goes wrong, or need to be done immediately. Most of the times this is when projects are failing or about to fail.

I have seen a lot of development oriented companies having trouble implementing SharePoint.  Mainly, this is because these companies are used to developing software targeted for a particular part of the stakeholders’  company. However, when it comes to implementing an Intranet an much wider view and understanding is required.  Developing and deploying an Intranet  requires to involve a lot of different functions from an company, and usually results in political warfare when not properly managed.

However, ERP related companies seem to have less of a struggle when it comes to implementing SharePoint. Basically because they have seen what it takes to implement ERP systems.

I have set up an list of most experienced reasons why corporate intranet implementations fail:

  • Primary focus on technology instead of functionality.
  • Lack of understanding of the product and inexperienced teams.
  • Lack of early end-user involvement and not planning for Intranet adoption.
  • Lack of an structured process for getting requirements, developing, managing and transitioning a SharePoint project.
  • Absence of a well defined information architecture and not doing usability assessment. 
  • Stakeholders support organization not able to support SharePoint.
  • Not understanding and being able to communicate the impact of an SharePoint implementation to the stakeholder.
  • Stakeholder not being able to provide clear requirements.
  • Failing to have an governance strategy.

Be sure to asses this risks when you are starting your SharePoint projects.

Follow

Get every new post delivered to your Inbox.