Archive

Archive for June, 2013

Previewing the Windows 8.1 Preview

June 29, 2013 3 comments

I found some time today to see what changed with the new Windows 8.1 Preview and took some quick notes that I thought I will post here just in case someone’s curious.

The Start Button

It is most definitely back and has taken its old place down at the left bottom corner in the desktop view. It responds however in the Windows 8 way, by bringing up the tiled Metro start screen interface.

clip_image001

In the start screen mode, you still have to grope down to the bottom left corner with your mouse (if you are using one) or use a hardware Windows button but it is certainly there. I haven’t tried this with a tablet or other touch device, though.

One thing I really liked was how you could right click on the Windows button in desktop mode and get a lot of really quick ways to get to different things. I am sure many of them will require you to be an Administrator on the machine but still very handy for things such as running PowerShell console as admin, accessing the Run box, launching Device Manager or Disk Management, Task Manager, Event Viewer etc. As an admin, the number of times I do those things makes it well worth the time saving.

clip_image002

There is an option to switch between Command Prompt and PowerShell on that popup menu. It is on this Navigation tab that has been added to the Taskbar properties dialog with a bunch of other new stuff. I would personally have preferred both but this is fine.

clip_image003

Oh by the way, right here is also the setting that allows you to boot directly to desktop mode. Not something I care much about but a lot of people seem to.

Tile resizing

Since it came to the Windows Phone 8, it was certain that the next upgrade of Windows would do this as well and right clicking or tapping and holding a tile now allows you to do one of four sizes – Large, Wide, Medium and Small. Not all apps may have tiles available in all sizes. A sample of each size is seen below.

clip_image004

All apps

The All apps charm has been replaced. You could right click on the start screen to bring up a charm in the menu at the bottom of the screen. Now you see a Customize option there instead that is used to customize tile positioning.

A new little arrow has been introduced at the bottom of the screen that brings up the All apps panorama now.

clip_image005

And there is a search box here that helps with filtering apps based on a search string.

clip_image006

Changes to Desktop Search

Type to search has changed. In Windows 8, when search text was typed in, it would bring up the complete app list in the larger pane on the left and start filtering for apps which match the search string. At the same time, it would present a bunch of apps in the smaller search pane that you could click on to search for the same string within that specific app.

clip_image007

Once you zeroed in on the app you wanted, if you wanted a context menu of actions you could invoke on it, you would right click as you always did in Windows and the menu would flow up from the bottom of the screen.

clip_image008

This has all changed and I am not sure I quite comprehend it but it looks like it went back to the way search used to happen within the "Start" dialog in Windows 7. You can still do Search based app filtering but that happens to through the other search interface as described above. Not sure why this separation was created.

clip_image009

The non-program results that you see above by the way are Bing Search suggested terms and clicking on one would bring up search results for that term in the Bing Search app.

Snap

The 3-app snap feature. You can put up to 3 apps snapped side to side. And they share the real estate equally. If you have a widescreen monitor, this really is very useful to work with.

clip_image010

With two apps, the snap feature now allows a 50-50 share of the screen real estate between apps which is a lot more useful than the small area in the corner one of the apps was reduced to with the older version. And then you can bring in a third up on top and decide which of the panes it will take over or place it in a pane of its own.

Each time you bring in an app as some are already tiled, as you hover over the next app, it will swivel a bit in one direction or the other depending on where your mouse is until you click in the direction it tilts to push it into the pane on that side.

clip_image011

Personalization

There is an additional personalization settings option that can be accessed from the Settings when accessed from the start screen view. For the really color-coordinated, there are a lot of color options to personalize the desktop pattern, background and accent colors.

clip_image012

Connectivity

Having run through the above, a lot of changes seem to have been made for convenience or familiarity or just providing more options. The large changes however seem to be made with making devices running Windows 8.1 really able to communicate with work networks.

clip_image013

A quick glimpse through the Network settings shows how VPN and proxy setup have been made important and easy to configure options.

clip_image014

I guess focus is largely on enabling people to connect their own personal devices of choice to work networks in a secure way and to enable administrators on work networks to still have control over the security of the network as a whole.

clip_image015

Since I am doing all this testing on a personal VM, I will not be trying to connect this to a work network but there are enhancements talked about including syncing work folders and being able to remotely wipe all business data off a user’s personal device. Surely there is more to the product under the cover than I could unveil in a two-hour fly-by and will take more exploration to discover but overall, it looks like a good middle ground for Windows 7 desktop lovers, touch screen users and people who like to get work done on their computers.

Advertisements
Categories: Windows Tags:

Creating an Active Directory Domain on Windows Server 2012

I am back again at the task, which I have likely performed too many times – that of creating a new Active Directory domain (and a domain controller) to join a set of virtualized lab machines to play around with. Only difference being, this time it is on Windows Server 2012. The overall experience is much the same with some minor differences.

This article is an exceptional resource for learning how to do this. All I do here is simplify it to the bare bones linear procedure required for the mentioned purpose.

I am doing this on a Hyper-V virtual machine hosted on a Windows 8 based Virtualization Server. The VM has 512 MB of RAM allocated and Windows Server 2012 was installed and a few networking related pre-requisites tasks were checked off in readiness for this. Most importantly, the virtual machine was set up to use a virtual switch created on Hyper-V to allow communication between all VMs connected to it. A static IP was assigned to the machine.

clip_image001

Started with the new Server Manager dashboard and chose to "Add roles and features"

clip_image002

The friendly Before You Begin screen that I always skip but not by default because it gives me quick link to the Remove Roles wizard. Clicked on Next >.

clip_image003

On the next screen you get to choose to install the role or feature on choose to install remote desktop services (RDS) which allows you to connect to virtual or session-based remote desktops where efficient, centralized, pooling and management of resources can be made possible. To learn more about these options, refer to this TechNet Article. It is also important to note that RDS and AD DS cannot be installed on the same server.

Chose Role-based or feature-based installation and hit Next >.

clip_image004

The following screen gives you the ability to pick a server from the pool. Since I have not added (and in fact do not even have to add) any other servers on this pool, I chose Next > to move on with the default selection. Adding servers to the pool will require going back to the Server Manager and choosing the option Add other servers to manage.

clip_image005

Next step, select to install Active Directory Domain Services.

clip_image006

Upon selection, the wizard presents a list of additional features required to run AD DS. There is really no choice about this. If you want to install AD DS, these are required. You can arguably skip installation of management tools but really, why would you? Clicked on Add Features to move on.

clip_image007

The following screen is the Add Features page and a couple are pre-selected – Group Policy Management and Remote Server Administration Tools. There are other eye-catching options but we shall not lose our focus here. Clicked Next > to move on.

clip_image008

Some best practice guidance and pointers are presented. Important to note here is how the wizard tells you that you will be prompted to install the DNS role on the server during the process. Clicked Next > again.

clip_image009

The next screen presents a summary of selections made. I selected to restart the server after installation if required and said Yes on the warning screen as well. I then went ahead and clicked Install to add the role.

clip_image010

And done. Clicked on Close to exit the wizard.

clip_image011

But now we see this in Server Manager on the AD DS node. All we did was add the role. We did not configure the server as a domain controller (DC) and that’s what this is all about. Clicked on the More… link.

clip_image012

The below is what you are shown. The substitute to good old "dcpromo". Clicked on Promote this server to a domain…

clip_image013

Since there is no existing setup, I added a new forest and chose a domain name to give it. Clicked Next >.

clip_image014

Quick notes on the next screen:

a. Chose no backward functional level compliance.
b. Selected to install the DNS Server role
c. The first DC in a forest is automatically a global catalog and cannot be read-only (no choice here).

Provided matching restore mode passwords and hit Next >.

clip_image015

Since there is a no authoritative parent zone for the server, DNS delegation cannot be configured. For a localized environment, this is just fine so hit Next >.

clip_image016

If you do choose in the above screen to see more information, the following is what you are presented. Essentially, this domain is not discoverable from anywhere and for what I am doing, that is just fine.

clip_image017

After jumping across those hurdles above, you end up on this screen where you choose the NETBIOS name for the domain. Was happy with the selection, so hit Next >.

clip_image018

The next screen is about where the files will go. Never messed with this before. No reason to start now. Hit Next >.

clip_image019

The following is a review screen. You can click on View script to view the PowerShell to run the configuration. I always keep the PowerShell even if I don’t intend to run it.

clip_image020

Here’s the PowerShell.

clip_image021

I hit Next > on the wizard to continue without the script.

A prerequisite check is performed.

clip_image022

A couple of warnings – one we have seen before but overall, ready to move ahead. Clicked on Install.

clip_image023

And since installation was successful, we need a computer restart.

clip_image024

When back, the picture in Server Manager looks different. We have the roles added and the server is now a domain controller in the new AD forest I created.

clip_image025

That’s it for now. I have big plans for this server to be realized soon and will probably post my notes on it.

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!

Writing a simple app to use Service Bus messaging

The Service Bus 1.0 for Windows Server is a really cool way to have a local instance of what Azure uses on the cloud for messaging. What’s cool about it? Well for one, you can write applications on your local box like you would for the cloud. So in other words, you can write applications that are cloud-ready and have them run on an on-premise environment too. For another, it is a great way to write loosely coupled applications based on messaging while leveraging the benefits of the underlying technology with transport reliability and availability.

I was enamored by the Service Bus enough to want to write a simple application to test its awesomeness but found guidance in several places, doing things in different ways in a somewhat disconnected fashion. So here’s my attempt at putting together a very basic application (or two) from scratch and doing the minimum work required to get messaging working. This test will use the Brokered Messaging capability of the Service Bus.

NOTE: All of the following was done on a single server installation of Service Bus 1.0.

Firstly, I wanted to create a new namespace that custom applications that I build to work with Service Bus can use called MyAppNamespace. I did this from the Service Bus PowerShell console using the following command

New-SBNamespace -Name MyAppNamespace -ManageUsers spdev\administrator

The -ManageUsers parameter is used to specify one or more user accounts that will have the ability to managed this namespace.

Then I used the following command to get the endpoint information for this new namespace I just created. This will be useful when I need to set up the connection string using which my application will need to connect to Service Bus.

Get-SBClientConfiguration -Namespaces MyAppNamespace

clip_image001

Then I launched Visual Studio and created a new console application project called MessageGenerator. I added reference to the following:

  1. Microsoft.ServiceBus.dll – which can be found typically at C:\Program Files\Service Bus\1.0.
  2. System.Configuration – needed to read the configuration from App.config
  3. System.Runtime.Serialization – needed by the namespace manager

clip_image002

Next, I brought up the App.config file for my application and added the following to it to define the connection string that the application can use to connect to the Service Bus. The value of the connection string appSetting is the one that is returned when Get-SBClientConfiguration is run from the Service Bus PowerShell for the namespace. It is not all visible here but the entire string was copied.

And while I was at this, I added another appSetting for the path (or the name) of the queue that I am going to create through my application.

clip_image003

In the Main function of my program, I set up the following to read from configuration and prepare the relevant strings

clip_image004

Next, I set up the console to

  1. Create a namespace manager
  2. Create a queue at the specified path if one doesn’t exist
  3. Spin up a queue client that will be used to send messages at the specified queue path
  4. Prompt user for messages until they no longer want to send one
  5. Read each message input by the user, create a brokered message and send it

Some exception handling is included to catch anything that may fail.

clip_image005

And finally (no pun intended), some clean up code.

clip_image006

Now since I have an application that sends messages, I created another quick console application that receives them called MessageReceiver. It is set up in exactly the same way as the sender in terms of settings and configuration. A couple of differences are

  1. This application does not need the System.Runtime.Serialization reference we added above since it doesn’t use the namespace manager to create a queue.
  2. As already mentioned above, it doesn’t use the namespace manager. It assumes that a queue exists at the specified path.

clip_image007

The main receiver code is a little different as seen below. There is no namespace manager here. The code

  1. Creates a client
  2. Connects it to the queue
  3. Receives a message every second
  4. Writes it to the console

And this goes on until the application is terminated by the user.

clip_image008

And the finally block

clip_image009

And that’s about it. Compiled and ran the applications and here’s the output.

clip_image010

Well there you go. Nothing really fancy in there but a really simple publish-subscribe model in action. You’ll need to be a geek to appreciate how cool this is. And a Pink Floyd fan to see what I did there. Happy messaging!

Categories: Service Bus Tags: ,

Installing Workflow Manager 1.0

June 2, 2013 1 comment

This post covers the installation of a new Workflow Manager 1.0 farm. For this installation, we are choosing to use an existing SharePoint 2013 farm. The intent is to have the SharePoint farm configured to leverage Workflow Manager to enable the SharePoint 2013 workflow platform. It is not required that you install a workflow farm on a SharePoint farm. Workflow Manager 1.0 can be installed on its own server farm and SharePoint 2013 can be setup to communicate with it over the standard service endpoints.

Planning

Before installing the Workflow Manager and Service Bus components on a new environment, it will help greatly to plan a few things out and have them ready for when the installation and configuration of the product will commence.

The following documentation has been captured from an installation on a single server SharePoint 2013 farm but if you are installing on a larger farm, it may be advisable to install the product on more than one server and add them to the farm that is created through the configuration process after the installation on the first server. This ensures the workflow services are highly available and are not prone to a single point of failure.

Prerequisites

To prepare for the installation of workflow manager, check for the pre-requisites where installing.

The following are the pre-requisites to install Workflow Manager 1.0

  • .NET Framework 4 Platform Update 3 or .NET Framework 4.5
  • Service Bus 1.0
  • Workflow Client 1.0
  • PowerShell 3.0

The following are the pre-requisites to configure Workflow Manager 1.0

  • Instance of SQL Server 2008 R2 SP1, SQL Server Express 2008 R2 SP1, or SQL Server 2012.
  • TCP/IP connections or named pipes must be configured in SQL Server.
  • Windows Firewall must be enabled. [Windows Firewall is Off on target server]
  • Ports 12290 and 12291 must be available.

Supported platforms

Check for supported platforms. The below represents the platforms on which installation will be attempted and the confirmation that they are supported.

  • Windows Server 2012 x64 Standard and Enterprise are supported
  • SQL Server 2012 with Default Collation and Windows Authentication is supported

The installation will be performed using an account that is a domain account on the domain the SharePoint 2013 farm servers are joined to and also a local administrator on the machine.

Runas Account

The Workflow Manager and Service Bus components of the Workflow solution will both expose a service endpoint that clients can connect to. The service will need a domain account to run as. The service account spdev\spsvcs which corresponds with the SharePoint Managed Account for SharePoint services will be used as the RunAs account for Workflow Manager. This account will automatically be granted Logon as a service privilege during configuration.

Database names

The Workflow Manager and Service Bus components of the solution will each create three databases that they can work with. If you have naming conventions for databases or need to do some general cleanup of names for better future understanding, this is the time to do it. Here are the names that I am going with.

Workflow Manager databases

  • WFManagement
  • WFInstanceManagement
  • WFResourceManagement

Service Bus databases

  • SBManagement
  • SBGateway
  • SBMessageContainer01

Installing

The product can be installed directly through the Web Platform Installer on a machine that is connected to the Internet. However, the installation on the target SharePoint 2013 farm that I am attempting will be done in Offline mode based on the instructions provided here.

Download the Web Platform Installer

On a machine connected to the Internet – to be referred to as the source machine – access this location and download the installer file for the Web Platform Installer. Once downloaded, run the MSI and the Web Platform Installer should be installed to %ProgramFiles%\Microsoft\Web Platform Installer.

Launch a new command prompt as administrator and run the following command

webpicmd /offline /Products:WorkflowManager /Path:C:\WorkflowManagerFiles

The required files will be copied down to the location indicated.

clip_image001

If the specified directory doesn’t exist, it gets created during the download process and the required files should now be available there if the process was successful as indicated below.

clip_image002

The next step is to copy these files over to the target machine.

clip_image003

Once the files are copied to the target server, launch an elevated command prompt and navigate to the bin folder contained within the Workflow Manager files folder used. This location will contain the Web Platform Installer executable that can be run in offline mode. Run the following command

WebpiCmd.exe /Install /Products:WorkflowManager
/XML:C:/WorkflowManagerFiles/feeds/latest/webproductlist.xml

NOTE: The command provided in the TechNet article referenced above does not work with the list of files available through the download. Run the command as provided here.

clip_image004

Once the files required are identified, the EULA for the files is presented. Type ‘Y’ and press Enter to proceed.

clip_image005

Once the installation is done, the following messages is what you should see unless there was an error somewhere.

clip_image006

Also, the Workflow Configuration tool is launched as shown below

clip_image007

This article focused on the planning and installation of the Workflow Manager product in offline mode on a target SharePoint 2013 environment. Check out how to Configure Workflow Manager 1.0 to continue.

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: