SharePoint Project Series.

This is a series of blogs I am writing on SharePoint projects:

Part 1 - Design and Planning Part 2 - Implementation (Stage 1) Part 3 - Implementation (Stage 2)
Part 4 - Training Part 5 - Continued Support Part 6 - Suggested Continued Improvement

Wednesday, April 29, 2009

Service Pack 2 is here!

Well they waited till after lunch but it is finally here!

Here are the new updated links to the individual service packs:

Service Pack 2:

Service Pack 2 for Windows SharePoint Services 3.0, x86 & x64

Service Pack 2 for Office SharePoint Server 2007, x86 & x64

Slipstream WSS:

Windows SharePoint Services 3.0 with SP2, x64
Windows SharePoint Services 3.0 with SP2, x86

I'm off to slipstream and install!

Here is the SharePoint team blog:

Tuesday, April 28, 2009

My SharePoint senses are tingling...

SharePoint Service Pack 2 is just around the corner, in fact it should be released any minute now...

As has been promised in this point:

I can feel it, its just around the corner.

I'm patiently waiting, my VMs are hungry.

SharePoint URL TinyURL and IIS Virtual Directories

Using SharePoint you would probably have come across the URL character cap. For instance if the URL you are trying to link to on a particular site gets very deep it has the potential to expand past the 256 character limit and therefore become truncated. This URL truncation results in broken hyperlinks, this is often experienced when trying to link directly to InfoPath URL forms.

I found this helpful post:

This information has enabled me to create some really nice Virtual directory re-directions to essentially create a really functional form launch center for long un-linkable InfoPath hyperlinks.

This is how it is done:

  1. On the SharePoint server (this needs to be repeated on other Web Front End servers if needed) open IIS.
  2. Navigate to the Portal IIS Website (SP_Portal_Site_80 for example), right click it and click on new > New Virtual Directory > Click Next
  3. Type in an alias to use for the URL, if you want to create a list of virtual directory hyperlinks for your InfoPath forms use something like 'FormURL'.
  4. Browse to the default IIS directory such as c:\Inetpub\wss\virtualdirectories\80 and create a new sub folder inside your sharepoint directory, feel free to use the same as your alias. Click next > next > finish.
  5. This will be your new SharePoint url to house the links to the InfoPath form links. For example http://intranet/FormURL.
  6. Now for each form you would like to link to you need to create a new virtual directory under the one created before.
  7. Follow the same steps as above to do this. Name the alias relational to the particular form you will be linking. (for example Timesheet)
  8. Right click the newly created virtual directory and click on properties.
  9. Select 'A redirection to a URL' and copy and paste the URL from the SharePoint URL InfoPath form (do this by clicking on 'New' in InfoPath form library and copying the address bar URL) into the 'Redirect to:' field.
  10. Check the 'Permanent Redirection' box and click on apply.
  11. Repeat the process for as many SharePoint InfoPath forms as you like.
Now you may link the URLs using the SharePoint tiny URLs created above. So for your Timesheet InfoPath URL you have created you can now use http://intranet/FormURL/Timesheet. You can use these URLs all over your site including the Top link bar, Side Link Navigation, Summary Link Web Parts etc.


Wednesday, April 8, 2009

SharePoint Projects Part 1

This is the first part of a multiple part series regarding SharePoint projects and the processes involved.

SharePoint Projects Part 1 - Solution Design

Many SharePoint projects have fair issues when it comes to time estimation. Due to the nature of 'Fixed Price' projects becoming ever so popular with clients (and with the sales team) it becomes extremely easy to over promise and under deliver. It is far easier to tell a client something will cost $100k and then finish under and let them know they have an addition x number of hours for further development and/or support then to tell a client $85k and then have to ask for another $10k due to unforeseen circumstances.

The problem is that SharePoint projects need to be treated almost as custom application development projects, although SharePoint is a fixed product essentially, the variables involved in each deployment is difficult to gather and can therefore skew your initial comprehension of the proposed solution. Therefore, whenever possible (and reputation allowing) it is a good idea to work on all SharePoint projects on a Time and Materials basis, this means that the project 'is finished when it is done' so to speak. Obviously for your own sanity you would have a project plan with assigned tasks and time estimates for your own reference.

However, if the client will only accept a fixed price (Which is often the case) and you don't have an option to decline the project, take these factors into account:

Scoping, Planning and Design

From what I have seen this is one of the most ignored steps in SharePoint projects. Microsoft have developed the SharePoint Deployment Planning Services (SDPS) to tackle this very issue. I would strongly recommend reviewing some of the available material to understand the SharePoint planning process.

The more planning and requirement gathering you do, the greater success you will have when it comes to quoting. One important aspect to note is that this is actually part of the project, you need to make the client aware that this type of 'discovery' phase is a vital part of the project. If the client chooses to not continue with the project after this discovery time frame, I believe that the client is accountable for the time spent during the design consulting phase.

For example: if you take your car to the mechanic and the mechanic tells you 'It sounds like you have a problem with your clutch, but I need to inspect it to be sure' you will pay the mechanic for his time to inspect the vehicle. Not allowing this 'inspection' and just 'going ahead' with the 'project' can result in the 'mechanic' replacing your clutch but in the process discovering that your gearbox and drive shaft are also damaged and therefore costing you a lot more than a 'clutch replacement'. This is essentially the same thing as a SharePoint project.

Things to remember (CAMSUD):
  • Capacity: How many users, how much data will be stored, what kind of data
  • Availability: SharePoint disaster recover and server availability, performance monitoring
  • Modification: Any SharePoint modifications, site creations, site collection creation, search scopes etc. Also would include look and feel modifications through Master/Layout pages.
  • Scalability: Future growth, future capacity, Future Development
  • Usability: Performance consideration, server architecture, network infrastructure, virtualisation, server farm configuration
  • Development: Customising SharePoint from a development perspective. Solution deployment.

I will be back next week to post the next part to this series: Implementation.

Tuesday, April 7, 2009

New Themes!!

Microsoft have released 10 new themes for SharePoint in the form of Visual Studio Extensions for SharePoint Projects.

They can be downloaded here:

Microsoft Download Site