This is a good news/bad news post, and I’ll make the choice for you, the good news comes first.
I was researching a claim made by several people (*armpfhMVPscough*) about the impossibility of installing Windows Azure Workflow (WAW) on a domain controller. This caused at least a bit of an outrage because people were told that they need two virtual machines to do SharePoint 2013 style workflow development.
I found those claims strange because I have successfully installed WAW on several SharePoint 2013 boxes, and I haven’t had any problems with them, beyond some trivial authentication mistakes on my first install that were quickly corrected.
So, imagine the look of eggs on my face when I set out to install a new SharePoint 2013 server, adding WAW as I had done probably ten times already, and suddenly landing flat on my stomach with error messages popping up from everywhere when I tried to run the post-install PowerShell commands to connect the two platforms.
Well, it turns out, I wasn’t so crazy after all. At least not regarding this. Let me give you a bit of background…
Workflows in SharePoint 2013
As you may or may not know, SharePoint 2013 now has two workflow engines that behave widely different. The traditional workflows, the ones we’ve used up until SharePoint 2010, are based on the .NET 3.0 framework and runs on the .NET 2.0 runtime.
In SharePoint 2013, we also have the option of using Windows Azure Workflows, which are essentially a completely rebuilt workflow engine that runs on .NET 4.0. Unfortunately, the new workflow engine can’t run the traditional workflows, at least not easily, so you need to choose whether you want SharePoint 2010 style workflows or SharePoint 2013 style workflows.
This is actually a fairly simplified view of the situation, but for the purposes of this article, it should suffice.
Now, the caveat of WAW is that unlike SharePoint 2010 style workflows it doesn’t run in SharePoint as such. To use WAW, you need to install a separate component in addition to SharePoint. This is great from performance, scalability, and flexibility perspectives, but means there’s an additional task to perform to get SharePoint 2013 style workflows up and running. And we’d all want SharePoint Designer Workflow loops and state machines, right? These features are only available in SharePoint 2013 style workflows.
And All of This Is Interesting Because..?
The story so far is pretty straight-forward. The twist comes from the fact that several people started publicly claiming that you cannot possibly install WAW and thus SharePoint 2013 style workflows on a Windows domain controller. Knowing a fair amount of SharePoint developers use only one virtual machine which includes the domain controller role, this lead several people to cry out that you now need at least two virtual machines to do SharePoint 2013 development.
If that had been true, it would have been a blow to the feasibility of SharePoint 2013 workflow development. With the SharePoint 2013 system requirements already on the edge of what is technically possible on current laptops, having to set aside additional resources to run a separate domain controller seems bad.
However, as Liam Cleary documents in his blog post Install Windows Azure Workflow Service on a Domain Controller, installing WAW on a domain controller is not just possible, it is very easy. I’ve had the exact same experiences, in fact I’ve set up WAW and run several SharePoint 2013 style workflows already as part of my research for . No problems at all, except that I forgot to use a fully qualified domain name for authentication the first time I did it.
Note: You need to use a fully qualified domain name for the Run As account when setting up WAW. You need to enable TCP/IP connections for your SQL server. Those are the major caveats.
Because several people, who should be in the know (*coughMVPsharmpft*, nasty cough I have there, sorry), claimed that it was plain impossible, I started asking around to see if anyone had even a mention of the domain controller limitation in any official documentation. Nobody could even point me in the right direction of such claims. I’ve been reading up on the Microsoft documentation on WAW and so far haven’t found anything myself either.
It is quite possible that an installation on a domain controller is not supported, but that’s a continent away from not working for the purposes of development. After all, I’ve still to hear about any SharePoint developer being worried about the supportability of their development environment. And no sane mind would install a single SharePoint farm on a domain controller in a production environment in any case, right?
So, developers, here’s the good news: Just relax. You don’t need two virtual machines to do SharePoint 2013 development, at least not at present. If anyone tells you differently, ask them to tell you exactly what isn’t working, and feel free to let me know their responses in the comments. If they can’t, tell them they’re idiots.
I’m trying to add a mild disclaimer here, but keep in mind we’re currently still in beta and things that seem to work now may not work in RTM.
What you need, though, is SharePoint Server 2013, because WAW workflows are not available in SharePoint Foundation 2013.
No SharePoint 2013 Workflows in Foundation?
Before I continue, I should point out that we’re still at the time of this writing in beta for SharePoint 2013. It is quite possible that Microsoft will change their stance on features and components before RTM.
However, at present, you cannot get WAW workflows to run with SharePoint Foundation 2013. You’ll notice this when you try to run a required PowerShell command towards the end of the installation, and you’ll know it because you get a message stating that the PowerShell CMDLet was not found.
You can get WAW installed just fine. In fact, when I wanted to prove that you could install WAW on a domain controller, I did just that, but because it was a quick setup, I didn’t go with a SharePoint Server install.
Part of the setup of WAW in SharePoint 2013 is to run a PowerShell command to connect SharePoint 2013 to your WAW installation. However, the entire installation of the features required for that connection exists only in SharePoint Server 2013, specifically in the OSFSERVER install files. Those files do not ship with SharePoint Foundation, so there’s no way to set up the infrastructure for connecting to WAW.
So, there you have it, good news and bad news. You don’t need a second VM, but you can’t accomplish what you may want without having Server installed.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!