Archive

Posts Tagged ‘PowerShell’

Listing all scopes in a Workflow Manager instance using PowerShell

August 12, 2013 4 comments

One of the pains I have encountered with setting up the Workflow Manager for use with SharePoint is that there is no clear visibility into the scopes that are currently on the Workflow Manager farm. It was hard to understand what scopes were already created, which of those were active, what the parent-child hierarchical relationships among those were and what applications were connected to those scopes.

So I tried to figure out if there was a way through OM code to get to this information or at least as much of it as I can get to without spending a whole lot of time and research. And below is what I could whip up.

param([parameter(mandatory=$true)][string]$Endpoint, [string]$Path = "/", [string]$Parent = "None")

[Reflection.Assembly]::Load("Microsoft.Workflow.Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35") | Out-Null
Write-Output ""

function WriteScopeInfo([string]$scopeUri, [string]$path, [string]$parent) {
    $scopePath = $scopeUri + $path
    $client = New-Object -TypeName "Microsoft.Workflow.Client.WorkflowManagementClient" -ArgumentList $scopePath
    $manager = $client.CurrentScope
    $scope = $manager.Get()

    Write-Output "Name: `t`t`t$($scope.DisplayName)"
    Write-Output "Path: `t`t`t$($scope.Path)"
    Write-Output "Status: `t`t$($scope.Status.ToString())"
    Write-Output "User Comments: `t$($scope.UserComments)"
    Write-Output "Parent: `t`t$parent"
    Write-Output "Children: `t`t$($scope.ChildScopeCount)"
    Write-Output ""

    if ($scope.ChildScopeCount -gt 0) {
        $manager.GetChildScopes() | % { WriteScopeInfo $scopeUri $_.Path $scope.Path }
    }
}

WriteScopeInfo $Endpoint $Path $Parent

Note that the script requires 3 inputs, one of which is mandatory. The Endpoint parameter requires the URL to the workflow endpoint. This will likely be a web application on port 12290 or 12291 depending on whether you set up the Workflow Manager farm to just use HTTPS (which is the default) or also HTTP. Please refer to this post if you are not sure how to set up the Workflow Manager farm.

The other two parameters are just used to kick things off for the scope discovery function. The first called Path is used to determine the node in the scope tree that you want to begin with. By default, this assumes the value “/” representing the root scope on the farm. But if I know of another scope somewhere down the tree and the branches and spring thenceforth are the only ones I am concerned with, I would pass it so – “/myscope/subscope”. The second called Parent is only required to identify the parent of the scope node that I am starting at. It is not really required and assumes the value “None” by default.

When run the script produces an output as shown below. As you can see, I am providing the endpoint URL of the Workflow Manager instance installed on my machine.

clip_image001

For those that are unable to use PowerShell, here is the C# version of the same thing.

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Configuration;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Workflow.Client;

namespace WorkflowClient
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                string workflowEndpoint = string.Empty;
                if (args.Length < 1)
                {
                    Console.Write("Provide workflow endpoint URL: ");
                    workflowEndpoint = Console.ReadLine();
                }
                else
                {
                    workflowEndpoint = args[0];
                }
                Console.WriteLine("");
                WriteScopeInfo(workflowEndpoint, "/", "None");
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message + ex.StackTrace);
            }
            finally
            {
                Console.WriteLine("Press any key to end...");
                Console.ReadKey(true);
            }
        }

        private static void WriteScopeInfo(string scopeUri, string path, string parent)
        {
            try
            {
                WorkflowManagementClient client = new WorkflowManagementClient(scopeUri + path);
                ScopeManager manager = client.CurrentScope;
                ScopeDescription scope = manager.Get();

                Console.WriteLine("Name: " + scope.DisplayName);
                Console.WriteLine("Path: " + scope.Path);
                Console.WriteLine("Status: " + scope.Status.ToString());
                Console.WriteLine("User Comments: " + scope.UserComments);
                Console.WriteLine("Parent: " + parent);
                Console.WriteLine("Children: " + scope.ChildScopeCount.ToString());
                Console.WriteLine("");

                if (scope.ChildScopeCount > 0)
                {
                    Collection<ScopeDescription> children = manager.GetChildScopes();
                    foreach (ScopeDescription child in children)
                    {
                        WriteScopeInfo(scopeUri, child.Path, scope.Path);
                    }
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message + ex.StackTrace);
            }
        }
    }
}

I hope to be able to use this to keep things clean/sane when I have more applications using my workflow farm and needing more scopes and child scopes.

Advertisements

Managing Quota Templates on SharePoint through PowerShell

August 10, 2013 3 comments

Quota templates are a seldom used but practically important feature in SharePoint. Important because it allows administrators to keep tabs on what sites can consume what level of storage without having to keep close watch on them. Defining a quota template with a high water mark (for warning when its reached) and a maximum level is the first step to this. Depending upon use, an administrator may have to define a large number of quota templates but doing this through the UI in SharePoint Central Administration is tedious.

clip_image001

One of these forms needs to be filled out for each template and it could get tiresome if there are tens of templates to create or edit. The easier way to do this? PowerShell.

The files in the archive posted here are PowerShell scripts that will allow an administrator to get a quick view of all available quota templates in XML and then allow the same XML file to accrue additions, modifications and changes pertaining to deletions that can be applied back to the set.

The following need to be ensured before running the scripts

  1. Run the scripts locally using the SharePoint Management Shell on a computer where SharePoint Server 2013 is installed and configured.
  2. Run the scripts as a farm administrator with permissions to alter quota templates. If the user is able to use the Central Administration UI to manage quota templates, then the user will be able to run these scripts.
  3. If there are permission issues with executing the script, ensure Add-SPShellAdmin is run for the user running the script.
  4. Use Set-ExecutionPolicy to temporarily tone the restrictions down if the shell complains about the script not being signed.

GetQuotaTemplates.ps1

##########################################
# Script:   GetQuotaTemplates.ps1
# Function: Retrieves all quota templates
#           defined on the farm in XML
# Author:   Lenny Ankireddi (2013)
##########################################

function Get-SPQuotaTemplates
{
    # Prepare XML structure
    $xmlText =
@"
<?xml version="1.0" encoding="UTF-8" ?>
<QuotaTemplates AsOn="">
    <QuotaTemplate Name="Sample" Action="None|Add|Edit|Delete" StorageMaxLevelInMB="0" StorageWarnLevelInMB="0" UserCodeMaxLevel="0" UserCodeWarnLevel="0" />
</QuotaTemplates>
"@

    # Read the XML string into an object
    $xmlDoc = [xml]$xmlText

    # Read the sample element
    $sampleQuotaTemplate = @($xmlDoc.QuotaTemplates.QuotaTemplate)[0]

    # Get a reference to the content web service
    $service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

    # Iterate through the list of quota templates
    $service.QuotaTemplates | ForEach-Object {
        # Clone the sample element
        $newQuotaTemplate = $sampleQuotaTemplate.Clone()

        # Set the attributes of the element with the quota template properties
        $newQuotaTemplate.Name = $_.Name
        $newQuotaTemplate.Action = "None"
        $newQuotaTemplate.StorageMaxLevelInMB = [string]($_.StorageMaximumLevel / 1024 / 1024)
        $newQuotaTemplate.StorageWarnLevelInMB = [string]($_.StorageWarningLevel / 1024 / 1024)
        $newQuotaTemplate.UserCodeMaxLevel = [string]$_.UserCodeMaximumLevel
        $newQuotaTemplate.UserCodeWarnLevel = [string]$_.UserCodeWarningLevel

        # Add the element to the QuotaTemplates node as a new child
        $xmlDoc.QuotaTemplates.AppendChild($newQuotaTemplate)
    }

    # Remove Sample node
    $sample = $xmlDoc.QuotaTemplates.QuotaTemplate | Where-Object { $_.Name -eq "Sample" }
    $xmlDoc.QuotaTemplates.RemoveChild($sample)

    # Set date and time when generated
    $now = Get-Date
    $xmlDoc.QuotaTemplates.AsOn = [string]$now

    # Save the XML as a file to the current location
    $currentLocation = Get-Location
    $xmlDoc.Save("$currentLocation\QuotaTemplates.xml")

    # Report completion
    Write-Host -f Green "The quota template information has been saved to QuotaTemplates.xml."
}

Get-SPQuotaTemplates

This script fetches the quota templates currently specified on the local SharePoint farm and their related properties and places these details in an XML file in the same location as the script file.

clip_image002

The XML file will be named QuotaTemplates.xml and will be of the following format.

<?xml version="1.0" encoding="UTF-8"?>
<QuotaTemplates AsOn="04/24/2013 14:58:32">
    <QuotaTemplate Name="Personal Site" Action="None" StorageMaxLevelInMB="100" StorageWarnLevelInMB="80" UserCodeMaxLevel="300" UserCodeWarnLevel="200" />
    <QuotaTemplate Name="Sample 01" Action="None" StorageMaxLevelInMB="4096" StorageWarnLevelInMB="2048" UserCodeMaxLevel="0" UserCodeWarnLevel="0" />
    <QuotaTemplate Name="Sample 02" Action="None" StorageMaxLevelInMB="5120" StorageWarnLevelInMB="4096" UserCodeMaxLevel="0" UserCodeWarnLevel="0" />
</QuotaTemplates>

This file will serve as in input descriptor for the other script that manages the creation, edition and deletion of quota templates. Running the GetQuotaTemplates.ps1 script will overwrite any existing QuotaTemplates.xml file in the script file location. A file with the same name is expected as input by the ManageQuotaTemplates.ps1 script. Therefore if an input file is required for posterity, a copy of the file will need to be saved away manually.

ManageQuotaTemplates.ps1

###############################################
# Script:   ManageQuotaTemplates.ps1
# Function: Applies changes to quota templates
#           based on definition in XML
# Author:   Lenny Ankireddi (2013)
###############################################

function ManageQuotaTemplates
{
    # Get a reference to the content service
    $service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

    # Read XML input file
    $currentLocation = Get-Location
    $xmlDoc = New-Object XML
    $xmlDoc.Load("$currentLocation\QuotaTemplates.xml");
    $xmlDoc.QuotaTemplates.QuotaTemplate | Foreach-Object {

        $Name = $_.Name
        $StorageMaxLevel = $_.StorageMaxLevelInMB
        $StorageWarnLevel = $_.StorageWarnLevelInMB
        $UserCodeMaxLevel = $_.UserCodeMaxLevelInMB
        $UserCodeWarnLevel = $_.UserCodeWarnLevelInMB

        switch ($_.Action)
        {
            "Add"
            {
                Write-Host "Attempting to add new quota template $name..."
                # Check if quota template already exists
                if ($service.QuotaTemplates[$Name] -ne $null)
                {
                    Write-Host -f Red "Quota Template $Name already exists. Cannot add a new one with the same name. Use the Edit action to alter the existing template."
                    Write-Host ""
                }
                else
                {
                    # Get a reference to a quota template object
                    Write-Host "    Getting a reference to a new quota template object..."
                    $quotaTemplate = New-Object Microsoft.SharePoint.Administration.SPQuotaTemplate

                    # Set mandatory properties on the quota template
                    Write-Host "    Setting quota template properties..."
                    $quotaTemplate.Name = $Name
                    $quotaTemplate.StorageMaximumLevel = [int]$StorageMaxLevel * 1024 * 1024
                    $quotaTemplate.StorageWarningLevel = [int]$StorageWarnLevel * 1024 * 1024
                    $quotaTemplate.UserCodeMaximumLevel = [double]$UserCodeMaxLevel
                    $quotaTemplate.UserCodeWarningLevel = [double]$UserCodeWarnLevel

                    # Add the new quota template to the list of quota templates
                    Write-Host "    Adding the quota template $Name..."
                    $service.QuotaTemplates.Add($quotaTemplate)

                    # Update the service
                    $service.Update()

                    Write-Host -f Green "Quota Template $Name has been added."
                    Write-Host ""
                }
            }

            "Edit"
            {
                Write-Host "Attempting to edit quota template $name..."
                # Check if quota template already exists
                if ($service.QuotaTemplates[$Name] -ne $null)
                {
                    # If found, edit the template with new property values
                    Write-Host "    Quota template was located; editing it..."
                    $service.QuotaTemplates[$Name].Name = $Name
                    $service.QuotaTemplates[$Name].StorageMaximumLevel = [int]$StorageMaxLevel * 1024 * 1024
                    $service.QuotaTemplates[$Name].StorageWarningLevel = [int]$StorageWarnLevel * 1024 * 1024
                    $service.QuotaTemplates[$Name].UserCodeMaximumLevel = [double]$UserCodeMaxLevel
                    $service.QuotaTemplates[$Name].UserCodeWarningLevel = [double]$UserCodeWarnLevel

                    # Update the service
                    $service.Update()

                    Write-Host -f Green "Quota Template $Name has been edited."
                    Write-Host ""
                }
                else
                {
                    Write-Host -f Red "Quota Template $Name was not found. Verify that it exists and name has been correctly typed in XML input. Use the Add action to add a new template by this name."
                    Write-Host ""
                }
            }

            "Delete"
            {
                Write-Host "Attempting to delete quota template $name..."
                # Check if quota template can be found
                if ($service.QuotaTemplates[$Name] -ne $null)
                {
                    # If found, delete it
                    Write-Host "    Quota template was located; deleting it..."
                    $service.QuotaTemplates.Delete($Name)

                    # Update the service
                    $service.Update()

                    #Report completion
                    Write-Host -f Green "Quota template $Name has been deleted."
                    Write-Host ""
                }
                else
                {
                    Write-Host -f Red "Quota template by name $Name was not found. Verify that it exists and name has been correctly typed in XML input."
                    Write-Host ""
                }
            }
        }
    }
}

ManageQuotaTemplates

This script is used to make changes to the quota templates currently defined within the system. This can be done by altering the XML file output generated by GetQuotaTemplates.ps1 shown above.

clip_image003

The Action attribute of the QuotaTemplate element can be altered to one of the following values.

 

Action Result
Add The script will attempt to create a new quota template. However if one already exists by the name used in the XML, no action is taken.
Edit The script will attempt to find an existing quota template by the given name and edit its properties. If one is not found, no action is taken.
Delete The script will attempt to find an existing quota template by the given name and delete it. If one is not found, script reports failure to find it.
None The quota template is left untouched.

Altering the XML

The following precautions need to be taken while altering the input file for the quota template management script

  1. Only edit the Action attribute on QuotaTemplate elements that need to be changed. It is None by default and these quota templates are not altered by the script.
  2. To add a new quota template, copy one of the existing elements over and change its attributes. Do not forget to set the Action attribute to Add.
  3. To edit an existing quota template, select the QuotaTemplate element with the corresponding Name attribute and change its attributes. Do not forget to set the Action attribute to Edit.
  4. To delete an existing quota template, select the QuotaTemplate element with the corresponding Name attribute and set its Action attribute to Delete.
  5. Add, Edit and Delete values on the Action attribute are case sensitive. Type exactly as shown here.
  6. Change the values of the attributes of the QuotaTemplate elements as necessary. Do NOT change any of the other XML constructs.
  7. Values for StorageMaxLevelInMB and StorageWarnLevelInMB are to be provided in integer megabytes. If you do not want to specify these, set them to zero.
  8. Values for UserCodeMaxLevel and UserCodeWarnLevel are to be provided in numerical points. If you do not want to specify these, set them to zero. If you want to set them to SharePoint standard values, specify 300 and 100 respectively.

Recommended approach

Run the GetQuotaTemplates.ps1 script first always to get a fresh updated XML from the server. Alter the XML as required and run ManageQuotaTemplates.ps1. The scripts have been written to avoid providing input parameters on the command line. Hope this helps.

PowerShell script to install SharePoint Root certificate to Trusted Root store

June 18, 2013 3 comments

Now this post is not really about why and how certificates are used by SharePoint. But in order to understand why we are doing what we are going to do shortly, let me start with a brief 2-minute (hopefully) primer on what this is about.

The public key infrastructure allows messages between users, applications and servers that host the applications to happen in a secure manner using digital certificates. The same happens within SharePoint when a message between entities needs to be secured. Now in order for the sender and receiver of messages secured through certificates to work, a trust needs to be established between the parties. The way this works is that both parties trust a third party which is the issuer of the certificate using which the message is signed. Bear in mind that this is a very high level overview of how this works and there are several variations that we shall not get into here. Having said the above, now in order for the receiver of a message to trust the certificate that is presented with it, it will need to be verified. Not only that certificate but its issuer’s certificate and that certificate’s issuer and so forth until we can trace back to a trusted root certificate. This is referred to as certificate chaining.

Within SharePoint, one instance where this happens is when the Security Token Service issues a token and signs it with a certificate. This certificate will need to be verified as mentioned above through building a chain back to a trusted root certificate. Also, a Certificate Revocation List (CRL) needs to be verified to ensure the certificate has not been revoked. This last is yet another topic requiring much detailed explanation that I shall try to address in a future post. But the idea here is that each certificate in the chain needs to be verified and one needs to lead to a trusted root CA store. If this doesn’t happen, certificate validation errors will occur and cause delays in response time to the users. To avoid this, we need to ensure that the SharePoint Root Authority certificate is installed to the Trusted Root Certification Authorities certificate store on each server in the SharePoint farm. The link above provides steps to do this but involves several manual steps. What I have included below, is a PowerShell script that does it all end to end.

The following are prerequisites to running the script.

  • To be run locally on each machine.
  • To be run as a user with Shell_Admin_Access role on the farm databases [If this is not available run Add-SPShellAdmin before proceeding].
  • To be run as a user with local administrator privileges on the server.

Another thing worth verifying before executing the script is the execution policy on the server. You can determine this by running the Get-ExecutionPolicy cmdlet. This typically shouldn’t be a problem unless you are running the script from a remote share. If you do have a problem though, you can work around it by using the Set-ExecutionPolicy cmdlet.

function CopySharePointRootCertToLocalTrustedCertStore {

    # Add the SharePoint PowerShell snap-in
    if (-not (Get-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue)) {
	    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
    }

    # Get the SharePoint root certificate
    $rootCert = (Get-SPCertificateAuthority).RootCertificate

    # Store current location
    $location = Get-Location

    # Go to trusted root certificate store on local machine
    cd Cert:\LocalMachine\Root

    # Check if the certificate already exists
    # If it does, report and end
    if ((dir | ? { $_.Thumbprint -eq $rootCert.Thumbprint })) {
        Write-Host -f Green "SharePoint Root Authority already exists in local machine trusted root certificate store."
        cd $location
        return
    }

    # Get the certificate store for "Trusted Root Certification Authorities" (Cert:\LocalMachine\Root)
    $certStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store Root, LocalMachine

    # Open the store with maximum allowed privileges
    $certStore.Open("MaxAllowed")

    # Add the certificate to the store
    $certStore.Add($rootCert)

    # Close the store
    $certStore.Close()

    # Get the certificate if it exists
    if ((dir | ? { $_.Thumbprint -eq $rootCert.Thumbprint })) {
	    Write-Host -f Green "Certificate was successfully added to the Trusted Root store."
    }
    else {
	    Write-Host -f Red "The certificate could not be added to the Trusted Root store."
    }

    # Set location back to where it was
    cd $location
}

CopySharePointRootCertToLocalTrustedCertStore

You can save the script as a .ps1 file and run on each of the servers where the SharePoint root certificate needs to be copied. The way to verify that this has actually worked is to pull up a management console and add the Certificates snap-in as described in the Microsoft Support KB Article referenced above. If however, your objective is to just export the certificate from SharePoint, you may want to use the script provided below. Just make sure you set the $certPath to where you would actually like to export the certificate and by what name.

# Set the certificate file path
$certPath = "C:\SharePointRootAuthority.cer"

# Add the SharePoint PowerShell snap-in
if (-not (Get-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue)) {
	Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
}

# Get the SharePoint root certificate
$rootCert = (Get-SPCertificateAuthority).RootCertificate

# Export the certificate to disk as a certificate file
$rootCert.Export("Cert") | Set-Content $certPath -Encoding byte

Once you have exported the certificate, you can manually add it to the certificate store by using the Management Console or by using the second half of the first script presented above. The only difference is that you will need to construct an X509 certificate object from the certificate file as shown in the script snippet below.

# Set the certificate file path
$certPath = "C:\SharePointRootAuthority.cer"

# Get the certificate store for "Trusted Root Certification Authorities" (Cert:\LocalMachine\Root)
$certStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store Root, LocalMachine

# Get the certificate from the location where it was placed by the export process
$cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 $certPath

# Open the store with maximum allowed privileges
$certStore.Open("MaxAllowed")

# Add the certificate to the store
$certStore.Add($cert)

# Close the store
$certStore.Close()

That’s it for now. Hopefully, I will find some time to write up more about troubleshooting certificates in SharePoint soon. In the meanwhile, happy scripting!

Configuring Workflow Manager 1.0

June 2, 2013 4 comments

If you have installed Workflow Manager 1.0 and everything went through successfully, at the end of the installation process, you should be presented with a configuration screen that will allow you to create a new Workflow Manager farm with default or custom settings OR join the computer on which you just installed Workflow Manager to an existing farm. To review the installation process, check out Installing Workflow Manager 1.0.

This article covers the configuration process using the Configuration wizard UI. If you are interested in running configuration through the Workflow Manager PowerShell console, refer to this post.

Before you proceed, ensure that the account that you are logged in as to configure Workflow Manager has sysadmin role on the instance of SQL Server where the Workflow Manager and Service Bus databases will be created. Configuration will be performed according to the steps outlined here.

Choose the option on the Configuration Wizard to install Workflow Manager with Custom Settings

clip_image001

On the following screen, for SQL Server Instance, choose the options as shown below and click Test Connection. If the connection is successful, a green check mark icon should be seen. Expand the Advance Options section and ensure Windows Authentication is selected and that the option to Use the above SQL Server Instance and settings for all databases is checked. We shall not use SSL for this particular installation.

clip_image002

Provide database names as shown below (I am using default names here) for the workflow, instance and resource management databases. Clicking on the Test Connection button each time will allow ensuring that the database names are not already used.

clip_image003

Scroll down to configure the service account that will be used to run the Workflow Manager and Service Bus services. Provide inputs as shown below.

clip_image004

This installation procedure allows Workflow Manager to generate its own certificates. Provide the Certificate Generation Key and retype it to confirm as shown below.

clip_image005

In the port configuration section, leave the default port selections for HTTPS and HTTP. Check the box to allow communication over HTTP. NOTE: This is being done as part of the current installation process since this is a non-Production environment. It is not recommended per the TechNet article to allow workflow management over HTTP in a Production environment. Uncheck the Enable firewall rules on this computer checkbox.

clip_image006

Next, specify the group that will be given access to all Workflow Manager databases. I am using the local admin group; on a full-fledged farm, a group with all farm administrators would make sense. Then click on the Next button to proceed to Service Bus Configuration.

clip_image007

On the Service Bus Configuration page, set the database names again as shown below. These are not the default names here, by the way. I did some clean up to have the names look consistent and remove the monikers “DB” or “Database” from them since that part is evident.

clip_image008

For the service account and certificate key, choose the same ones that were provided for the Workflow Manager configuration

clip_image009

For the port configurations, leave in place all the default port numbers. Uncheck the Enable firewall rules on this computer box.

clip_image010

NOTE: The firewall rules checkbox has been unchecked for both the Workflow Manager and the Service Bus because checking this box will cause the configuration wizard to try and edit the firewall rules on the computer. However, the firewall on the target server is set to Off. The setting made above is to skip the firewall rule setting. If the firewall, is turned back on, rules will need to be put in for each of the ports configured above. Otherwise, the workflow manager and service bus services may not respond correctly.

Finally, configure the admin group that will receive access to all Service Bus databases as shown below and click on the Next button to proceed.

clip_image011

The next screen provides a summary of all of the settings and selections made. Go through them to ensure that the right selections have been made for Workflow Manager.

clip_image012

Scroll down to view the settings and selections for the Service Bus as well. Once satisfied with all the settings made, click on the Check button at the bottom of the screen to proceed.

clip_image013

NOTE: You can copy a text manifest of all the settings made by using the Copy link at the bottom of the page. You can also, use the Get PowerShell Commands link to get the complete configuration process given out in script that you can quit the wizard and execute through the Workflow Manager PowerShell console to complete configuration. If you prefer using PowerShell, copy the commands now and refer to this article.

If you choose to carry on in the wizard, at this point the configuration process kicks off and goes through with the farm provisioning. If all goes well and configuration is successfully completed, the UI will display check marks against all stages and we may then proceed on to the step where SharePoint is configured to leverage Workflow Manager services.

clip_image014

If you have everything set up correctly, you should be able successfully add the Service Bus and Workflow Management farms and add the host to both. However, sometimes, a problem might occur during configuration that will require fixing before configuration can be run again. To check the workarounds or solutions to a couple of problems that I have faced and documented, refer here.

If everything got configured correctly, the Workflow farm should be ready to be consumed by clients such as SharePoint 2013. To learn how to configure SharePoint 2013 to consume the workflow services, please check out Configuring SharePoint 2013 to use Workflow Manager 1.0.

Configuring Workflow Manager 1.0 using PowerShell

June 2, 2013 1 comment

This post covers the process of configuring Workflow Manager 1.0 using PowerShell. It assumes that Workflow Manager 1.0 has already been installed. To get the step by step on the installation procedure, check this article. In Configuring Workflow Manager 1.0, I have detailed the post installation configuration process of the Workflow Manager product through the Configuration Wizard UI. If however, you like me, are the kind of person that would like to monitor as many steps along the process as you can, you may want to run configuration through PowerShell. Note that while you can follow the commands purely as shown in this article, and make required changes for your environment, it would be easier to refer to the configuration post and use the wizard to make all the settings but not run it. Instead, at the end of that article, you can see how the PowerShell commands based on the settings made are handed to you by the wizard so you can copy them, close out the wizard and move on to the console.

You can run the entire configuration process through a script that the configuration wizard provides you as mentioned above. All you need to do to generate this script is use the Get PowerShell Commands link on the Summary page. There are a couple of good reasons for using PowerShell instead of the wizard based configuration process

  1. You can run each command, verify the outcome and move on to the next step confidently.
  2. Error handling becomes easier since it is very evident what specific operation failed and you can resume after the last successful step.

If you have already copied, the PowerShell commands provided by the configuration wizard, you may have to or want to make some changes to it before you proceed. The following are the changes I made.

  1. If you open the commands, you will notice that text at the places where the RunAs account password or the certificate generation key are used have been replaced with some placeholder text (which looks like this – ‘***** Replace with Workflow Manager Certificate Auto-generation key *****’) so as not expose those. This will need to be corrected.
  2. The script instantiates a couple of references to hold the certificate generation key – $WFCertAutoGenerationKey and $SBCertificateAutoGenerationKey. These are used in the New-SBFarm, New-WFFarm, Add-WFHost and Add-SBHost commands to follow. It does this because this allows using different certificate auto-generation keys for each service. If you wish to use the same certificate, you can eliminate one of these statements and make sure you use the variable from the other in both commands.
  3. The same as above holds true for the RunAsPassword. One of these can be removed and the variable from the other statement can be used in both the Add-SBHost and Add-WFHost commands.
  4. Once all of this is done, you may choose to save the script as a PS1 file and run the entire set of commands at once through the console or type each command individually.

To start configuration, launch a new Workflow Manager PowerShell console. You should find a shortcut to this in the Workflow Manager 1.0 program folder in the Start menu. If not, you could navigate to %ProgramFiles%\Workflow Manager\1.0\Scripts and run StartWFConsole.cmd. Either way, you’ll end up launching Windows PowerShell with the WorkflowManager module imported.

clip_image001

STEP 1 – Get a secured string for the Certificate Generation Key

clip_image002

STEP 2 – Create a new Service Bus farm

clip_image003

In progress…

clip_image004

… and done.

clip_image005

STEP 3 – Create a new Workflow Management farm

clip_image006

In progress…

clip_image007

… and done.

clip_image008

STEP 4 – Get secure string for the super-secret password

clip_image009

STEP 5 – Add this host to the service bus farm

clip_image010

In progress. The part where the service bus services are started may take a while. This is where the Service Bus Gateway and the Service Bus Message Broker are being spun up. This is also the most troublesome part of the entire configuration process.

clip_image011

And done.

clip_image012

The farm information now looks as shown below

clip_image013

If you face any challenges with the addition of the host to the service bus farm, please check this post to see if you are having a problem similar to the ones documented. If everything went alright, you can proceed on to the next step.

STEP 6 – Create a namespace on the Service Bus to be used by Workflow Manager. Couple of things to note here.

First, you can call this namespace anything as long as you ensure you use the same name in the client configuration parameter you use when adding the host to the Workflow Manager farm.

Second, if you copied the configuration PowerShell from the wizard, it does some exception handling and implements a wait after the New-SBNamespace cmdlet is called presumably to allow the time it takes for the instantiation to complete before we proceed on to getting a client configuration based on it. I am not doing any of this below because I am running each command in sequence and can manually handle these things.

clip_image014

STEP 7 – Get a client configuration for the namespace just created. This provides you an XML structure that can be used by the Workflow Manager client to establish connections and communicate with the Service Bus.

clip_image015

STEP 8 – Finally, add the current host to the Workflow Manager farm. This usually goes through without a hitch and completes the configuration. At least on the Workflow Manager.

clip_image016

So you see a couple of HTTPS and HTTP endpoints. Let’s take a quick look at IIS Manager to see if these show up correctly. As you can see below, there is now a Workflow Management site on IIS that is bound to port 12290 for SSL and 12291 for HTTP based communication.

clip_image017

One final piece of verification is to hit up the workflow endpoint over HTTP in a browser. And everything looks good.

clip_image018

If you’ve gotten this far, you are done with the farm creation process and the addition of the host to the farms. The Workflow Manager farm should be online and humming merrily at this point. But if your original intent for the farm was to lend its cool new features to SharePoint 2013, check out how to Configure SharePoint 2013 to use Workflow Manager 1.0 services.

%d bloggers like this: