Automate BRE Xml File Import - PowerShell Code, Part 2

BRE comes in two flavors - Policies and Vocabularies.  In the previous post, I gave an overview on how to publish a Policy via code.  

What about Vocabularies?  

The process is somewhat similar, but the methods are a little different.  In a Policy, you need to add the Policy, and then deploy it (optional) if you want it active.  For a Vocabulary, you just need to add it, since Vocabularies don't get deployed.

Also, if a Policy uses a Vocabulary, the Vocabulary needs to be added first (much like an assembly reference).

The code snippet below gives an overview of how I accomplished this.

Automate BRE Xml File Import - PowerShell Code

There isn't a lot of information on how to automate a BRE xml file import.  Many suggest using the PowerShell provider that used to be available on Codeplex, but unfortunately it's now a dead page.  There are other resources (QuickLearn) that explain using assemblies in the BizTalk SDK folder.  These have been available since BizTalk 2013.  It appears that what was available in Codeplex has been lifted and shifted to the BizTalk installation process (to the SDK subfolder) on your local server.

This is all good, but there are some limitations.  First, Microsoft doesn't offer any real documentation for the PowerShell SDK.  I had to revert back to a different site to get documentation (version 1.4.0.1, published back in 2014 by Randal van Splunteren and Maxime Labelle) for the PowerShell Provider documentation.

Second, upon looking at this documentation, the BizTalk PowerShell provider doesn't allow for the creation (or importing) of certain artifacts. See screenshot below, highlighted area.

In my case I wanted to automate the deployment of a BRE Policy xml file to the BRE store.  I tested this using the BizTalk SDK assemblies, and the results are the same as the (older) documentation states - function not supported.

So I came across this on the Microsoft website which had a C# snippet of doing what I wanted.  I decided to convert it to PowerShell, since the rest of my processes use PowerShell for builds, releases, and deployments.  I now can now script this out to automate deployments of BRE xml files.  In my case, I use Azure DevOps to perform this using a 'PowerShell on Target Machines' task.

So here's my version of that - use and modify at your own risk.  Enjoy!

TFS Release Notes Write-Verbose continued

A while ago I posted a note on using the PowerShell Write-Verbose command for TFS logging when using the 'Execute PowerShell scripts on remote machine(s)' Task.

One of the issues we ran into was executing a command but we weren't getting the output.  In my case we were trying to call BizTalk's btstask.exe command in a PowerShell script, which was saved to the local remote server.  Every now and then we'd get an error, but it wasn't properly displaying in the TFS Release log.  So we would need to manually run the command by remoting into the server and then look at the output to verify what the issue was (typically we didn't delete existing suspended messages, so we couldn't update the application).

Initially I thought capturing the output via a variable would work, like so:

$myBtsTaskOutput = BTSTask.exe AddResource /Source:$srcPath /ApplicationName:$appName /Type:$resType /Overwrite /Destination:"%BTAD_InstallDir%\$outputFile" $gacOptions 

However, when I tried to capture the output by using:

Write-Verbose $myBtsTaskOutput -Verbose

the command would fail with an object error.  Even using .ToString() failed.


The proper way to get the output is to immediately cast the type of the variable to a string, like so:

[string]$myBtsTaskOutput = BTSTask.exe AddResource... 

Now the Write-Verbose command will give you the proper output.   Super simple :)

Notes on building a BizTalk Build and Release Server using TFS

I created a BizTalk build server to handle building BizTalk solutions as well as releasing/deploying the artifacts to the BizTalk environments.  It's running like a champ and the group is very happy with the implementation and results.  Getting a build server properly set up wasn't difficult, but there were a few things that I jotted down for documentation.  These notes are what you see below.

Here are the background/requirements/setup:

• Visual Studio 2015 is being used to develop the BizTalk 2016 solutions
• We use two NuGet repositories:  The main NuGet repository, and our own company-based repository.  I'll discuss the NuGet setup in a later post.
• We are using the MSBuild.  XAML is not being used.
• Deployment Framework for BizTalk 5.7 is being used.
• Use of some simple, custom PowerShell scripts on local server is secondary method when BTDF doesn't make sense.
• Right now I have just one agent set up.  I really haven't come upon a need to add more.  It's easy enough to add more agents, so there's no need to fret on this.

I did follow a good portion of what Vikas Bhardwaj put in his blog - it's a fantastic resource and got me going in the right direction.  Please take the time to read all parts, as there is good information in each one.

For my environment, I had the server team in my company create a new (small) server just for BizTalk builds/releases - you may want to do the same as there extra components that need to be installed.  I think it's just one cpu with a 200 gig hard drive.  It's mostly inactive compared to other servers.

Some notes:

• You will need to ensure you have opened ports HTTP, HTTPS, and Windows Remoting (80, 443, 5985, and 5986) between the build server and the destination servers when using the build server to do Releases/Deployments. The port for PowerShell is needed only if you are going to perform a 'PowerShell on Target Machines' task.  This has been a huge plus, as I'll explain later.
• Since we are using BizTalk 2016, I installed Visual Studio 2015.  Make sure you install all the necessary components (i.e. C#, VB.NET, whatever) you require in order to do a proper solution build.  For me, I left the default values alone.
• Install BizTalk 2016, but select only the following:
• Just the Developer Tools and SDK
• Server Runtime (and all sub-categories) - you need this to compile a BizTalk solution.
• Administration Tools And Monitoring (and all sub-categories)
• Additional Software
• Enterprise Single Sign-On Administration
• Enterprise Single Sign-On Master Server
• BAM Client
• Project Build Component
• Allow the installation wizard to install the Prerequisites
• DO NOT CONFIGURE BIZTALK !!!!!
• Note on the above: my interpretation is that a BizTalk license isn't necessary.  See BizTalk Pricing.  Send me a note if that is incorrect.
• We installed the Deployment Framework for BizTalk, version 5.7.  Select everything but the samples.
• We found that we came across two scenarios for building/deploying BizTalk artifacts: 
  • Large, complex applications worked very well under the BTDF
  • Small projects (single map, receive location, etc) worked just fine running the btstask.exe command via a PowerShell on Local Server task.  This is where opening port 5985 was critical.  PowerShell remoting (WinRM) is VERY powerful.
• Installing an Agent wasn't difficult.  However, having the proper rights/permissions was difficult.  Make sure you have a good relationship with your server admins.  ☺☺

After I got the above finalized, we were hitting the ground with getting Build Definitions set up.

Microsoft TFS Build and Release Notes - Write-Host errors in PS Script

When developing out TFS 2015/2107 build and release definitions, it is good to log your steps when you queue out a build or release.  I write out to the logs when I'm using any of the PowerShell tasks ('Run a PowerShell script' or 'Execute PowerShell scripts on remote machine(s)', for example) in a build or release.


There is, however, a good and bad way to log in a PowerShell script in VSTFS 2015/2017.


In your PowerShell tasks, do NOT use Write-Host, as this will fail when you try to run a Build or Release. 

Instead, use Write-Verbose in the PS script and you will get the results you need.

BizTalk 2016 - WCF-Custom Transport: Unrecognized attribute 'ApplicationName'

Today I came across an error with the WCF-Custom Transport.

I have a send port that uses the WCF-Custom/sqlBinding type as a send port on my local dev machine.  Everything works as expected, so I exported the MSI and bindings to use on our Test environment.

When I imported the bindings file, I received an error: "Error loading properties. (System.Configuration.ConfigurationErrorsException) Unrecognized attribute 'ApplicationName'.

I compared the settings on my local dev to the Test environment and noticed some differences.  This screenshot is from our Test environment

and this is from my local dev environment

Notice the highlighted configurations don't exist in the other one.

This is because I have installed BizTalk 2016 Feature Pack 1 on my local machine, and the Test machine does not have this installed.

See https://docs.microsoft.com/en-us/biztalk/core/connect-to-sql-server-always-encrypted-columns-with-biztalk-server?redirectedfrom=MSDN.

Cannot delete a send handler that is used by a send port

We had a mislabeled Host/Host Instance name in one of our lower environments - it wasn't the same name as our production or qa environments, and a request was sent to rename it. So, a colleague performed the following:

1. Create a new Host and Host Instance with the desired name.  
2. Once that was done, add the Host to the appropriate adapter. For us it was adding it to the FILE adapter.
3. Then re-configure all appropriate send ports to use the new Host Instance.

Restart Host Instances, and the send ports were properly using the newly created Hosts.

Once that was done, the thought was that the old host could be deleted. We came across a few things (some are obvious, others aren't so):

1. You need to remove the Host Name from all adapters using the (old) Host you wish to remove:

At this point, an error popped up - "Cannot delete a send handler that is used by a send port":

The issue is that, although all the static send ports were updated to use the new Handler, the dynamic send ports weren't - this isn't as obvious. Here's how to do that:

1. In the BizTalk Admin Console, select Applications/All Artifacts/Send Ports
2. Sort by Transport Type. Here is where you will see some that don't have the Transport Type as blank. These are your Dynamic Ports.
3. For each Dynamic Port, open one up and, in the General tab, select 'Configure'.
4. You will see a list of Send Handlers associated to each Adapter. You will need to make your changes in this list according to how you made your changes with your static Ports.

Once these changes are made throughout, you should be able to now remove the Handler completely, and thereby able to remove Host Instances, then the Host itself.

Further explanation here by the-one-and-only Saravana Kumar:

https://blogs.biztalk360.com/can-you-use-dynamic-send-port-without-orchestration-yes-you-can/

The "Behind the Scene" section was the eureka! moment for me. 







FYI - This was tested in BizTalk 2016.  I don't believe you can navigate the same way in BizTalk 2010.