Windows Azure Workflow Only in SharePoint Server 2013

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 Introducing SharePoint 2013. 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.

.b

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!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

6 thoughts on “Windows Azure Workflow Only in SharePoint Server 2013”

  1. Ive not used a single dev box for sharepoint development for over a year. Consider this setup to separate your AD from sharepoint: blakeblackshear.wordpress.com/2010/10/07/sharepoint-2010-development-vm-part-1setting-up-server-core-with-ad/

    1. Thanks for your comment and link Brian. I know some developers prefer to separate out the DC role, but I’ve never seen a use for it except in situations where I’m doing active AD work from SharePoint.

      What are the benefits you see from having a dedicated DC box as oppose to just putting it on the SP VM?

      .b

      1. Overall, consistency…Some of the pros I see to this:

        1. Don’t have to worry about whether something will or “won’t” work on a DC. I just don’t have to think about it. I allocate 512MB RAM to the AD machine and I’ll trade this 512MB RAM for peace of mind knowing that I don’t have to worry about the “does it work on a DC” issue.
        2. Don’t have to spin up a new AD (and create new users/groups/etc) for each new project (consulting).
        3. Consistent use of service accounts for each SP VM I create.
        4. Enforce things group policy on each dev machine I create (i.e. disable shutdown event tracking, etc).
        5. Coming from a Development background, I want to spend as little time configuring AD and Group Policy. Basically do it once and forget it.
        6. Potentially spin up multiple servers to test things in “Farm” environment. Given the requirements for SP2013, this doesn’t seem to be a valid scenario, but for SP2010, from time to time, I may spin up a small farm to to trial/demo things and how they work in a small farm.
        7. More closely resemble how things would “work” in the real world. Hopefully identifying issues that arise from multiple boxes more quickly.

        Granted some of these could be mitigated by alternative approaches, however, this setup has served me quite well for SP2010 work over the last 1year+.

  2. Actually, you need at least 5 VMs to really do true development in SharePoint 2013:

    1) Domain Controller – 2GB
    2) SVR-SPWFE01 – 8GB
    3) SVR-OWA01 – 8GB
    4) CLIENT01 – 4GB
    5) SVR-SPAPP01 – 8GB

    Why? Domain Controller being separate is straight-forward. You need a SharePoint instance for sure (SVR-SPWFE01), this can host the visual studio for development of server and client side code. You need a OWA instance because it won’t let you install on a SP instance. You need a client machine because you have to install Visual Studio express for Windows Phone development to do thing with Push Notifications and mobile programming. And the last instance is for doing true Search development with a multi-role search architecture.

    If you don’t have these FIVE, you can’t do every single development task one would need to do in SharePoint 2013. Trust me, I have already tried to get it down and it just doesn’t work.

    Total of at least 24GB of memory to run a full development environment.

Leave a Reply

Your email address will not be published.