Quick tip: if you’re using the Managed Metadata service in SharePoint 2010, you may encounter an issue when trying to use it in a site column. When creating the column of type, Managed Metadata, you may encounter the error message:

Required feature is not enabled for this column type

This is simple to fix. In powershell, issue

get-spfeature | where {$_.DisplayName -eq 'TaxonomyFieldAdded'} | enable-spfeature -url http://yoursiteurl

changing the -url paramater to match the URL of your site. Job done.

VMWare converter is a free tool from VMWare to convert Virtual Machines from one format to another. I’ve recently built an ESXi server and was looking to move some machines from VMWare Fusion 5 over to it. There are a few pitfalls to be aware of:

1. VMWare Converter 5.0 is not compatible with ESXi 5.1 (yet). Don’t even try - Converter will just hang.
2. Converter 4.3 is allegedly compatible with 5.1, but I didn’t have any success. I would get “invalid fault” exceptions.
3. Convert 5.0 with ESXi 5.0U1 is painfully slow to transfer machines, even on gigabit lan. There is one option here that explains how to improve conditions. However, even with that fix, I only got transfer speeds of around 5mb/s when transferring file-based VMs.
4. It may not help, but check DNS and network config between you and your ESXi server is setup. DNS in my ESXi was set up to be some random IP address which presumably did not help.
5. Installing the converter on the machine you want to transfer is much faster. So rather than targetting a .vmx file, you can tell it to transfer the “currently powered-on machine”. Doing this with a simple W7 machine achieved speeds of anywhere up to 14mb/s. (Not great if you want to transfer a non-Windows machine, though!)
6. You may encounter issues with VMs that have multiple virtual hard drives. I had a SQL Server with 3 separate drives installed, and whilst it did transfer all drives, with data intact, only the C: drive was alive when starting the machine. You may need to use DISKPART to get the other drives going again.

Will add more issues as I encounter them.

This is the second post in a series about running ESXi on a home server. See the first part, here.

ESXi is a free download from VMWare. You just need to register an account and install it. Simple huh? Well, not all the way. Two main issues:

1. I didn’t install an optical drive (intentionally, although with hindsight it would have been a bit easier to have one)
2. The Broadcam NetXtreme BCM57781 LAN card on my ASROCK board is not supported by ESXi. D’oh.

However, there are ways around this. If you’re running the same build as me, you should be able to follow these steps. If you’re using different hardware, substitute in the relevant bits!

This is the first part of a series on running ESXi on a home server. See the second part, here.

It’s a been a while since updating this blog. Apologies, but it’s mostly because I’ve been really busy. As part of that though, I use a lot of VMWare Virtual Machines. Being an Apple “fanboy” (gah) I use VMWare Fusion on my Macs which is great for running various virtual machines. (In fact, Windows 7 and Windows Server 2008 R2 seem to run a hell of a lot better virtualised rather than natively. Go figure.)

Anyway, it got to a point where I decided I needed a bigger and more robust framework to run virtual machines on. Simply speaking, running one or two VMs on my Mac is fine, but when you need to run several at one time with limited resources, it starts to get a lot more involved. Given that VMWare ESXi Hypervisor is a free platform for running a single server VM host, I figured I’d experiment with building an ESXi server for home use. This blog post details some of the pain I went through in getting there.

Before I get started, there are a few terms I will use:

HOST - the physical machine, that is running ESXi
GUEST (or guest OS) - this is the virtual machine(s) that then runs on ESXi

And quickly:

What is ESXi

ESXi is a cut down linux kernel that acts as a hypervisor. That is, it’s a piece of software that runs on the physical machine, and then presents the physical hardware to the guest machines that want to use it. It in itself is not an OS. So they key difference here between say VMWare Fusion or Workstation is that you’re not running an edition of e.g., Windows Server which itself is running Virtual Machines - you’re, moreorless, cutting out the middle man.

If you’re using a delayActivity in your Visual Studio State Machine workflow, you are likely to want to use the InitializeTimeoutDuration handler to set the length of the delay.

An easy mistake to make is to think you could do the following:

private void DelayActivity_InitializeTimeoutDuration(object sender, EventArgs e)
        {
            delayActivity1.TimeoutDuration = new TimeSpan(0, 10, 0);
        }

However, this won’t work. This is because SharePoint will intialise a new instance of the delayActivity with the timeoutduration specified as default. To set the TimeoutDuration of your “actual” activity, you should do the following:

If you’re designing a SharePoint 2010 workflow, particularly a state machine, you may base the workflow activities around an item in a list. Particularly, you may want the workflow to carry out activities when the item is changed by the end user.

This is a relatively straight-forward task, but one thing you will quickly encounter is that if you have multiple states, and each one handling the onWorkflowItemChanged event, you’ll notice that the event will fire once for each occurrence of your handler. So if you had 3 states, and each one has an onWorkflowItemChanged event, then your state that is handling the event will receive it 3 times. This is clearly undesirable and quite frankly strange behaviour.

On any list, you can define a new column as a type of “Person or Group”. In event handlers or workflow, you may want to grab this value as use it as a real SPUser object, which will expose the name and email address, for example. Unfortunately if you just grab the value of the field, e.g.,

<br /> item["MyPersonField"]<br />

you’ll end up with a string that looks a bit like this:

15;#DOMAIN\Matt Thornton

Read more

A common problem in designing workflows is how to make the workflow “sleep” for a period whilst users do (or don’t do) something. A common scenario is where you wait for some user input, but if you don’t get any by a certain time to continue the workflow in a different stream. You achieve this with a delay activity where you specify a timeout in the form of a Timespan.

The delay activity was broken in SP2007 which was then fixed with a Hotfix. Surprisingly, this remains kind of broken in SP2010 as well. That is to say, the delay activity never wakes up.

Update: the below information is useful reference, but you may find it leads to undesirable results, where your workflowItem events fire repeatedly. Read the below, and then read this.

Working in Visual Studio 2010 and designing SharePoint 2010 state machine and sequential workflows, you may come across the following warning message when building and deploying your solution when using the onWorkflowItemChanged event:

Activity ‘onWorkflowItemChanged’ validation warning: The correlation token may be uninitialized

You will also probably notice that your workflow doesn’t respond or wake up to any onWorkflowItemChanged events. This is almost certainly due to the correlation token you’re using. The way to get this working correctly is:

This is one of those “d’oh” SharePoint moments. Created a new SharePoint feature and used Visual Studio to deploy it. Worked like a dream. Great, I think, ready for UAT. Package up the solution, install to the UAT environment and then attempt to activate the feature. Boom.

Weird. The feature was very simple so the error, as is the wont of SharePoint, was a bit unhelpful. Quick bit of Googling which didn’t help, before, thankfully, my brain engaged. I checked to see if what my feature was trying to do - create a site column and attach it to a couple of content types - had actually worked. It had.