Workflow and SQL Error: Part 3

As you may remember from my earlier post and subsequent follow-up, we have been seeing an issue related to workflows and the Workflow History list in SharePoint 2007. As I’ve already mentioned, the case is with Microsoft and I also said that I would post updates as new information arrived. Today, more detail has emerged and, as promised, I am sharing.

Whilst replicating the fault today we were having trouble – one of us had a SharePoint install that failed every time and the other had one which would not fail at all. Whilst looking at possible differences we realised that the failing site was a publishing site and the non-failing site was a team site.

After some testing, I can now report that the fault I have described only occurs when the SharePoint Publishing site feature is enabled (note, the site feature, not the SharePoint Publishing Infrastructure site collection feature). If you’re not using a publishing site you have nothing to worry about from the problem we see.

Netware 6.5 on Hyper-V

As part of a customer project I needed to create a Netware environment for testing. It’s been a little while since I did any netware management and I quite enjoyed it. I did, however, encounter a couple of gotchas which I thought I’d write up for the greater good.

Netware OS

Installing the Netware OS was actually pretty straightforward. There are no integration services offered for Netware so from the outset I knew that I would need to use legacy hardware options in the virtual machine.

I created a nice big dynamic virtual hard disk for the server because I will need to install GroupWise and a whole bunch of other services later. I attached this to the virtual IDE controller, gave the machine a single processor core as anything more needs integration services, and (critically!) added a legacy network adapter. Netware isn’t a huge memory hog, so I added 1Gb of RAM and off we went.

I hit a snag at the point where the server tried to identify network drivers – it couldn’t find any, and I couldn’t see any in the list to load manually which matched the emulated hardware.

The solution turned out to be really simple: as you step through the installation screens there is an option to allow unsupported drivers. By default that is set to no. If you change it to yes, the installation recognises the network adapter as an old DEC and loads a driver which works.

Apart from that, I have experienced no difficulties with the server whatsoever, other than I have to run the machine connection window full screen to be able to switch between console screens.

Windows Client

I will admit, this one drove me crazy for a while before my final epiphany. There is a Novell client for Windows Vista now available, but why build a Vista VPC when an XP one would need less horsepower?

I dutifully grabbed an old Virtual PC VHD of our XP base install and fired it up.

Problem number one: In order to install the integration services I need to first uninstall Virtual Server Additions. No sweat, thinks I, clicking the uninstall button. Nope – you get a nice message saying that setup can only run inside a virtual machine!
Slightly surreal, I must say. I had to fire up the machine under Virtual PC and remove the additions, then copy the VHD back on the hyper-v server and start the system so I could install the integration services.

Problem number two: Once I’d installed the Novell client I couldn’t get it to see the Netware server. Nothing I did would work – I strapped down every setting I could on the client to point it at the Netware machine but it refused to connect, although I could ping between the two quite happily.
The solution, when I finally figured it out (and I must admit it was pure chance that I thought to try it) was to remove the shiny new virtual network adapter and replace it with a legacy adapter. As soon as I did that, the Novell client could communicate quite happily with the server!

The situation would appear to be that the Novell client stack can’t communicate properly through the new virtualised driver provided by Hyper-V. Exactly why this should be, I have no idea, but it drove me wild for a good couple of hours today.

Unable to access My Tasks in Project Web Access

Sometime ago we noticed an issue with My Tasks in Project Server. Certain users were unable to access My Tasks at all – they simply got a SharePoint error page.

A little jiggery-pokery with callstack and custom errors later, we saw that the error referenced a GUID for a task. I then searched the Project Server Publishing DB for the task GUID and subsequently located the project to which it belonged. If I edited the project in MS Project and updated the server, removing the task assignment from the user, they could access my tasks.

For anyone who has a similar problem, here are the SQL queries you need:

select * from dbo.MSP_TASKS where TASK_UID='<Task GUID>'

select * from dbo.MSP_PROJECTS where PROJ_UID='<Project GUID>'

Most odd. So I logged a call with our friends in Microsoft Support.

It’s been parked for a while, but I received an email from support today advising me that the Infrastructure updates would help. Funnily enough, I’d already installed them (we keep our SharePoint farm as fully patched as we can), so that was almost all the way there.

Finally, they provided a short SQL script to run against the Publishing DB. This would identify any tasks that were orphaned and correct the issue. Luckily, we had none!


When I experienced the problem there were no hits in my old friend Google so hopefully this will help somebody, somewhere.

Here are the links to the infrastructure updates for completeness. Remember to read the docs carefully on installing these babies!

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695), 64-bit edition

Infrastructure Update for Microsoft Office Servers (KB951297)

Infrastructure Update for Microsoft Office Servers (KB951297), 64-bit edition

Infrastructure Update for Project 2007 (KB951547) – English

Configuring ActiveSync on Windows Mobile for Exchange Push

I’m not certain how many of you will find this useful, but I had a question about configuring the Touch Diamond to talk to Exchange which I regrettably failed to notice.

It’s an interesting point of debate, now I come to think of it. When I got my Diamond the first thing I did was confgigure ActiveSync directly on the device. Whilst I do connect to my laptop from time to time, I don’t actually have any real sync going on between the two, other than possible for OneNote and Notes. How many people out there still use Outlook to sync their phone information if Exchange Push is available?

Anyway, back to the plot. To get this all going without using Windows Mobile Device Center or ActiveSync, grab your phone and go to Programs via the Start menu.

  1. In Programs, find ActiveSync.
  2. In ActiveSync, select Menu and then choose Configure Server
  3. In Server address, enter the name of your Exchange server. This is the same as the hostname you use for OWA (e.g.
  4. If your server needs https rather than http, tick the option monikered ‘this server requires an encrypted (SSL) connection)’
  5. Tap Next and you will be asked to provide login information – username, password and the name of your Active Directory domain. Make sure ‘Save password’ is ticked or the automatic sync won’t work and you’ll have to enter your password each time you trigger a manual sync.
  6. Tap Next once more and you will be able to select what gets synchronised. I have an unlimited data plan and I hate losing stuff, so I tick every box – Contacts, Calendar, E-mail and Tasks.
  7. If you’re being clever at this point, tapping Menu will allow you to get to the advanced options, where you can configure how conflicts are handled and what connection to use (normally this should be ‘Internet’)
  8. Tap Finish and the phone should sync.

To make sure Push is enabled, where new items get sent to your device as they arrive you need to alter the Schedule,  which is an option on the main Menu in ActiveSync. Pick your options to suit your preferences. I would stongly suggest that you make sure ‘use the above settings when roaming’ is NOT ticked unless you have deep pockets!

As ever, I hope this helps somebody out there.

SharePoint Website Schematic

I find myself drawing the same diagram over and over again in meetings to explain how SharePoint sites relate to IIS web sites, how managed paths and alternate access mappings fit and why you need to extend the SharePoint web application if you want more than one authentication provider.

After some of my colleagues pestered me to draw it again, I decided to create an electronic version, and since everybody seems to find it so useful I thought I’d post it here as well.

Rather than talk about it, I’m going to post it ‘blind’ and invite comments from you, my enthusiastic audience as to how easy it is to understand and any errors or omissions there may be.

With a little luck, somebody will find it useful!

SharePoint Website Architecture