Error installing Workflow Manager: Add-WFHost raises exception

Workflow Manager 1.0 (a.k.a. Azure Workflow) is the new workflow engine to support workflow in SharePoint 2013. This allows for a more scalable workflow engine which can be hosted on a separate (workflow) farm. The other option is hosting the workflow engine on the same server where SharePoint 2013 is hosted.

To deploy my environment(s) I use PowerShell. This is the same with configuring Workflow Manager 1.0. When running the Workflow Manager Configuration it generates the PowerShell command for you (see sample script).

Add-WFHost exception when configuring Workflow Manager

Although I use PowerShell scripts, it’s very likely to have the same issue and errors when running the Workflow Manager Configuration. When running my, slightly adjusted, script I got this error:

Add-WFHost : Could not successfully create management Service Bus entity 'WF_Management/WFTOPIC' with multiple retries within a timespan of 00:02:05.7093984.. The exception of the last retry is: The token provider service was not avaliable when obtaining a token for '$STS/Windows/'.. At C:\SPInstall\McwModules\mcwspinstall.wfm1.0\Ensure-WorkflowManager.ps1:117 char:19 + $wfHost = Add-WFHost -WFFarmDBConnectionString "Data Source=$wfDBServer; ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (:) [Add-WFHost], TimeoutException + FullyQualifiedErrorId : WFRuntimeSettingFailed,Microsoft.Workflow.Deployment.Commands.AddWFHost

Solution to “token service provider not available” issue

It seems the service bus is not available, which is a local server address. I tried disabling the loopback adaptor, but that didn’t work out. After digging around some more I realized my environment has a proxy server. The checkbox “Bypass proxy server for local addresses” was unchecked in the Internet Settings (Control Panel » Internet Options » Connections tab » LAN settings).

After ensuring the local addresses are bypassed, the PowerShell script worked as a charm!


Resolve conflict Domain Control SID and member SID

To play around with SharePoint 2013 I need a decent setup of a Domain Controller, SQL Server 2012 and SharePoint 2013 Server. To achieve this I use Hyper-V and want to reuse as much as possible, but it has it limits…

SharePoint 2013 Server Topology

Every machine, virtual of physical, has it’s own SID. This can be retrieved via PsGetSid.exe from The thing is, it seems that the Domain Controller needs to have an unique SID within the domain. Although the domain members are allowed to have similar SIDs.

When I setup my topology I use a base image for every machine. Meaning these all have the same SID. After I installed my Domain Controller and second machine which I wanted to join to the domain I got this error “The domain join cannot be completed because the SID of the domain you attempted to join was identical to the SID of this machine”.


The solution to this is renewing the SID of the member machine. I needed to run sysprep.exe to change the SID of my base image, which I use to create the SQL Server 2012 and SharePoint 2013 machines. After running sysprep everything worked as expected!

When setting the MySiteHostUrl I get a UserProfileApplicationNotAvailableException

When I’m trying to set the MySiteHostUrl via PowerShell it throws an error. Taking a closer look it seems after initializing the UserProfileManager class an UserProfileApplicationNotAvailableException is raised.

The exception you receive is

New-Object : Exception calling ".ctor" with "1" argument(s): "UserProfileApplicationNotAvailableException_Logging :: UserProfileApplicationProxy.ApplicationProperties ProfilePropertyCache does not have 458839b6-4979-413a-a7a3-41d8564faea3"

The PowerShell script I’m using is retrieving the current context and initializing the UserProfileManager object. This should provide me access to the MySiteHostUrl.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ea 0 $site = Get-SPSite “” $context = Get-SPServiceContext($site) $upm = New-Object -TypeName Microsoft.Office.Server.UserProfiles.UserProfileManager -ArgumentList $context $upm.MySiteHostURL = “”

The solution to this is providing the account running the PowerShell script sharing permissions “Full Control” on the User Profile Service Application.

  • Open Central Administration
  • Click Service Applications
  • Select “User Profile Service Application”
  • Click in ribbon the Permissions button
  • Add account which is running PS script, in this example “xxx-spinstall”
  • Select “Full Control” and click OK
  • Run the PS-script again!

Permissions User Profile Application