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.


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

What’s Your Name?

Recently, I’ve been engaging in several debates that focus on finding and defining names and titles for things or concepts. For some reason, people seem to feel they need to name something to understand it, whether it is a bird flying over their heads, the title they can use for their work, or well-understood concepts of development, like Marc Anderson’s Middle-Tier development.

In SharePoint, it often boils down to debates like whether someone can use a title as a Developer if they only work in JavaScript and CSS, or whether one should call themselves Business Analysts or Architects or something along those lines. Then, the debate goes into semantics about origins of words and the legacy of Donald (the Knuth, not the Duck) while nobody seems to focus on what developers, business analysts or architects do.

I think they should all be titled Frank, and then have to say what you do rather than your title. I find the whole idea of names and titles idiotic, and I’ll tell you why.

What’s In a Name?

If I walk up to you and slap your face, you’ll get annoyed, possibly angry. If I call it a hug and argue well enough that you agree to call it a hug, meaning I just gave you a hug, then everyone to which you tell the story won’t understand why you’re so upset. “B gave me a hug so I dropkicked his ass to the other side of the room”. Doesn’t really explain your anger, does it? In fact, in all likelihood, you’ll be seen as the crazy person, not me.

Silly example, right? Well, it’s silly because everyone knows that forcefully planting my hand on your cheek is usually an offensive action, regardless of whether it is called a hug or a slap. The name we put on things doesn’t change the thing itself. Names assume we have a common understanding of what the underlying thing is, and if we don’t, then the name won’t mean anything.

Let’s take another example, a saying like “She was like a mother to me”. Even if you’ve never heard that said before, you can probably deduce what it means, right?


What’s your relationship with your mother? Does the person who hear those words from you have the same idea about their mother as you do? The answers is likely no. Someone else may hate their mothers from being abused or some other tragedy and your possible intent of transmitting a message about your mother, who might have been strict but kind and gentle, will be completely misunderstood.

Language is a difficult thing. We mostly use it as naturally as we take breaths, but it is still the cause of all the conflict and love in the world.

Language should come with a warning sign: Please use with care. Misuse may lead to violence or sex.

So… What’s Your Title?

Some titles have very specific meanings and are even protected by law. In Norway, for example, you cannot call yourself a lawyer just because you want to. The title is protected because it should convey some sort of authority to it.

In some areas, titles are well understood. A car mechanic fixes your car and a neurosurgeon pokes in your brain, right? A woodchopper chops wood, and a baker bakes. We hold these truths to be self-evident.

However, in many areas, titles mean little unless you have a deep understanding of the profession. If you say you want to hire a lawyer in the US, you probably won’t get many useful applications, because there are so many types of lawyers that you need to know in which area you need their help. Even then, you may have to go through several candidates who may be practicing similar but not accurate enough areas of law or don’t have the background that you want. And who can, off the top of their heads, tell me the difference between an attorney, a lawyer, a solicitor, and a barrister?

Still, for the legal professions, these terms are actually defined and have accurate meanings. You can look it up if you need to do so.

Now explain to me what a SharePoint business analyst does. Well, they would analyze something, wouldn’t they? What exactly? Their title won’t tell. Would they come in an say “Well, your quarterly profit earnings amortizes well over the financial surplus year” or whatever the terms are? Or do they say that “you know, I’ve analyzed the mood of your employees and those colors you have in the office really brings out anger”?

How about a SharePoint developer. Develops something, right? Well, is a person who builds site collection templates a developer? How about someone who builds workflow solutions, but only uses the built-in workflows in SharePoint? Are they developing anything?

The truth is, it doesn’t matter. It doesn’t matter whether you’re a baker, neurosurgeon, lawyer, or developer. If we renamed the neurosurgeon to “fairy”, then if you hit your head in an accident, your head would be fixed by fairies, but you’d still get well. If we renamed SharePoint developer to “clown”, then your next site would be built by clowns, but you’d still get your solution done.

I know, many organizations already think their solutions are built by clowns…

What matters is what you do, not what you or anyone else call you. Call me what you want, as long as you call me time and again, to quote the immortal lyrics of Culture Beat.

Did you know that the text for Mr. Vain was written in part by an English pole vaulter named Steven Lewis who at the time was only 7 years old? Either that, or Wikipedia is wrong.

Introducing Frank

If titles make no sense, why do we need them? Beyond giving certain professionals an ego boost, as long as customers do not understand the industry well enough to understand what each title means, titles have little meaning.

Recruiters have a task just as difficult. You’ll find plenty of job advertisements for “SharePoint developer” that then go on to demand skills in web design, SharePoint Designer, InfoPath, and Visual Studio, plus the ability to set up, operate, and maintain a SharePoint farm. A SharePoint infrastructure architect, according to one job ad I just read, needs to have hands-on experience with SQL Server (a DBA requirement), IIS (a web administrator), and Windows (a server administrator), as well as knowledge of SharePoint APIs (which is developer skills). Another ad for a SharePoint designer and developer lists PerformancePoint, Outlook, and helpdesk support systems (!) as important tools.

Even among SharePoint professionals, titles are confusing. You can’t say “SharePoint developer” these days without a fight over whether developers have to actually use .NET programming to be allowed the use of the title. Are you configuring SharePoint instead you say? Well, you’d probably confuse your clients even more if you called yourself SharePoint configurator, and it still wouldn’t say whether you configure SharePoint for operations or for building business solutions.

If I walk up to a client and say that I’m a SharePoint developer, I will likely also need to explain exactly what I do. Even if I say I’m a third tier developer, or use the term SharePoint programmer, I’m still not revealing enough for the client to evaluate whether I can solve their problems.

Instead, let’s drop titles completely. They mean very little outside the SharePoint community and the community cannot agree even among themselves what the titles mean. Until the community matures enough to end up with clearly defined titles with unambiguous meanings, we cannot possibly expect anyone else to understand what we mean.

Let’s call ourselves Frank. We’ll still have to tell clients what we do so it won’t matter much in terms of accuracy. This will also force the clients to focus on what their problems are rather than the title of the person they want to hire, a title they and the person they hire do not understand, or at least can’t agree on how to define.

Job recruiters can skip trying to come up with a title that matches their requirements, but instead explain what they need done from the person they hire.

And, who knows, perhaps the community can come together and decide that being SharePoint Frank is about as useful as all the other attempts we’ve made at agreeing on titles and then actually come up with a common understanding of what we do rather than what our names should be.


Pin It

Become a SharePoint Professional – Understanding The Architect Role

One of the most misunderstood career paths in SharePoint is that of the architect. These roles retain some of their mystery because people do not understand them well but perhaps also because the title “Architect” in other fields is often considered a higher status profession.

The confusion seems to stem from many developers or administrators looking to ‘advance’ into becoming an architect. This idea seems silly to me; in fact, I’ve previously argued that going from being a technical performer to an architect is a disadvantage.

In truth, however, an IT architect is just like any other profession and you advance in your career as you do in any other job. You start from scratch, you learn, and you become a better architect.

In this series, called Becoming a SharePoint Professional (read the other articles at the bottom of this article), I’m trying to enlighten you on what it means to become and be a SharePoint professional. In this article, I’ll be focusing on the SharePoint architect and what becoming an architect entails.

The Role of an Architect

In SharePoint an architect is not necessarily a technical role at all. Many of the greatest architects I’ve known have little or no hands-on technical experience at all. Rather than knowing how to do something, what they know is what is possible and what makes sense.

For this reason, an architect is a horizontal role in that their greatest strength comes from breadth of knowledge rather than depth of expertise. An architect needs to weigh countless options against each other and pick the ones that best solve the requirements.

Architects work on finding out what to do rather than how to do it. They work from a set of requirements or goals and then pick the components required to reach that goal. They work in close company with soft-skill professionals like business analysts, project managers, and so on, but also with technical performers like pure developers and administrators. Once an architect has completed their work, they hand over a design or architecture to technical performers who them implement that design.

An architect needs to be able to construct massively complex grids of capabilities. Every selected feature has both opportunities and challenges, and these need to match, not just to the requirements, but to all other selected features as well. Knowing all the capabilities of all available features and components is in itself a huge challenge, but being able to put them all together to solve the requirements without causing too many side effects is the task of a master.

Note: My argument against going from a technical role to an architect role is in short that a technical role is a role that focuses on few or one area in depth, which is exactly the opposite of what an architect should do. A previously technical-role architect will likely tend to prefer the methods and options with which they are familiar, making them bad architects.

IT architects come in many flavors, even in SharePoint. Saying you’re a SharePoint architect means about as much as saying you’re a SharePoint developer. Sure, I know you design or architect things, but do you architect solutions, infrastructure, security, information, or what?

Although you’ll find architects that work in multiple disciplines, keep in mind that, as with all professions, if you split your profession over multiple disciplines you will not be able to go as deep into each area.

For example, a SharePoint solutions architect specializes in knowing as much as possible about capabilities of various features and components in SharePoint and even other platforms like Office, Exchange, Lync, and so on. This is a massive undertaking, and to be good at it, or for it to yield an actual return on investment for the training you need, you need to focus.

If in addition you start to work as an information architect,  where your tasks will be to understand the business taxonomies and architect information management system to support those, you’ll find a completely new discipline that will take attention away from your solutions architecture practice. You won’t excel in all disciplines, or even many. Like developers or administrator, if you want to become an expert, you need to focus.

In short, however, think of architects not as advanced developers or administrators, but rather as breadth-first practitioners within those disciplines, who know a massive amount of topics to only a small extent. This means that there are ‘developer’ discipline architects that essentially architect building and development, and there are ‘administrator’ discipline architects that essentially architect management and operations.

Finally, keep in mind that we are only talking about SharePoint architects so far. However, there are many architect roles that are not SharePoint specific but are still relevant to SharePoint professionals. For example, a solutions architect (not to be confused with a SharePoint solutions architect) focuses on solutions in general, where SharePoint is just one option. These solution architects pick SharePoint as a tool, but doesn’t necessarily know SharePoint features or components in detail. They then hand over the architecture and requirements to a SharePoint architect who can then pick the required features and components.

Note: This all comes down to another problem with IT, the ambiguity of titles, but I’ll leave that for a separate post.

The Path of Becoming an Architect

I sometimes hear SharePoint professionals say that you cannot have junior architects, because all architects are in senior roles. This may be correct, but probably not in the way you think. Many current architects have extensive experience. They move into their new career after having spent years doing other disciplines, such as development, infrastructure, security, or similar technical professions. However, there’s nothing preventing you from starting out in a career as an architect from scratch.

When moving into a new career, experience may be a good thing because it usually means you are older and have been exposed to more situations from which you can learn.  This isn’t unique to architects; for an experienced administrator to move into development, for example, their life experience means they will have a head start on many of their younger and less experienced colleagues.

You become and architect just like any other profession. You start with the architect’s version of your first “Hello World” solution, and from that point on, you are an architect, albeit not more than a developer would be a developer after creating their first “Hello World” application, or an administrator would be an administrator after doing their first spouse-mode install (and adds a “Hello World” web part to their wizard-created site).

Architects, like developers and administrators, start out by doing simple tasks to build their experience and confidence. Perhaps setting up a site for your department, or even just designing the document structure for a single library. Perhaps you’re onto the infrastructure path so you figure out what hardware you need to run a single department SharePoint solution.

These tasks are simple, but expose you to some of the considerations you need to make in your future career. From these simple tasks, and don’t feel ashamed to repeat them for experience or make failure to get a few burned fingers, you advance to more advanced scenarios.

Advancing Your Architecture Skills

If your time and job description allows, don’t waste time after a project, but immediately start to think about the next steps in a more complex scenario, even if you know for a fact that a more complex scenario will never happen for this project. What would your solution look like if it were scaled to five times its current size? What if you had three times the number of document types? What if there was a need for external user access? What if you had to support a rapid restore after a critical breakdown?

As an architect, your skill set includes thinking two or three stages ahead of your current project, so after you’ve completed your first and simpler projects, start practicing on the thought pattern. By doing so, even if the project never moves ahead, you will see your simpler project in a new light. Perhaps you didn’t take into account that when you add three new departments to your solution, your chosen solution isn’t scalable enough. Good! You’ve just gained experience that will help you in your next project. Perhaps you didn’t consider changing document requirements in your taxonomy solution. Great! You’ll not make the same mistake again.

Next time you are asked to create a new department site or a document taxonomy, you’ll have these new and imaginary experiences to help you along, and you’ll architect a solution that is better than your first one.

Congratulations, you’ve improved.

Eventually, you’ll start working on larger projects, for example if your organization is satisfied with the work you did for your department and want to do a larger SharePoint deployment. By the time you get to this point, you should have architected several smaller installations already, you’ll have joined the SharePoint community to have a peer network from which to learn, and you’ll have confidence in your own abilities.

The point here, though, is there in no part of the path is there a stop that say “now, go be a SharePoint developer for a few years” or “now, manage your servers for a couple of years to build experience”. You don’t build experience as an architect by working as a developer or administrator, no more than you build experience as a chef by eating a lot or selling food at a convenience store. Granted, these are related tasks, but if you want to be a better chef, you need to cook, and if you want to be a better architect, you need to architect.

Similarly, there’s no ‘exit’ path after you’ve reached a certain skill level. You don’t naturally ‘advance’ from being the world’s greatest food eater to be a great chef, nor from being a chef to a grocery store manager, even if all of these are related to food. Great developers don’t become great solutions architects by advancement; a developer who wants to become an architect starts from the bottom, just like anyone else. You don’t become a business analyst as a natural progression from an architect role; if you want to become a business analyst, you start from the bottom, just like anyone else.

Your path of advancement in your career is usually within that discipline, so your advancement path as an architect is to become a great architect, and the advancement path as a developer is to become a great developer.

I Have No Projects!

If you work for a single organization and as an architect primarily for that organization, you might end up with spare time where you don’t get to practice your skills.

Here’s an exercise I did in my early days as an aspiring SharePoint infrastructure architect (and if you didn’t know, I originally started out on the path towards SharePoint administration). Look through case studies posted for SharePoint solutions, and focus on the areas of requirements. In fact, stop reading after finding and understanding the requirements. That’s where you’ll spend most of your architect time in any case.

Then, based on the usually limited requirement information you find in those case studies, start architecting the solution. If you are stuck in one area, for example the scale of servers, read requirements again, and see if there are other factors you can address. These may reveal clues that can help you solve your original problem of scale.

After a while, you’ll be stuck for good, and you won’t be able to go further. That’s OK, at this point, you have a ton of questions you need to ask and get answered to move on. You also have, and this is why you’ll want to use a case study, the solution so that you can verify your own suggestions and learn from what the organization in the case study chose.

In addition, the questions you have are important because you’ll find the same problems in other real-life situations. By knowing in advance what questions you need answered, you also know more about what you need for your next project.


Well, we’re still not done yet, at least not with the series. I still have many questions for you to ask.

Before I end this article, however, I’d like to send out a special thanks to Paul Culmsee for helping me with this article. I often reach out to Paul when I need feedback on topics and articles, and he always brings valuable insight to the table. I highly recommend checking out his book Heretic’s Guide to Best Practices (he made me say that).

Don’t forget: if you have questions you want answered about becoming a SharePoint professional, the comment field below is your place to ask. The series is still under development and I’ll be happy to answer questions if they’re appropriate.

Of course, you can also check out the articles in the series navigation below (or, if reading this elsewhere, view the entire Becoming a SharePoint Professional series here)


Pin It