BizTalk Install: "RPC server is unavailable"

I'm in the process of upgrading BizTalk 2009 to 2010. The new BizTalk environment is a two-server active/active environment - the operating system for both aren't using a clustered configuration. The SQL back end is a separate tier (SQL Server 2008R2).

The first BizTalk tier went flawless with the install and configuration. The second tier installation was successful as well.

However, when I tried to configure the second tier, I got the error "(RPC: 0x800706BA: The RPC server is unavailable.) (SSO)" when trying to Join to the existing Enterprise SSO.



There is a bit of documentation out there, and most of it led to information on MSDTC issues. One of the configurations within the BizTalk install is to ensure that the DTC rules are enabled within the firewall configuration. Those were enabled, yet I still recieved errors.

A Microsoft tool called DTCPing, helped me out considerably. I copied the executable to my app tiers and also to our SQL Server tier. You have to run them all simultaneously on each tier. I was able to ping from my BizTalk Sever tier to SQL, but I couldn't successfully ping in the opposite direction.

Hmmm, firewall?

Initial test: Turn the firewalls on the BizTalk app tiers off. Restart the DTCPing process. SUCCESS with ping!

So now we know it's a firewall issue. A new rule added to the firewall was the fix.

As a side note, Chris Forster does a decent job describing some background to MSDTC and SQL.

BizTalk 2010 and BAHS

If you have installed BizTalk Adapters for Host Systems (BAHS) in the past and are now looking to do the same for BizTalk 2010 (i.e. migrate from previous BizTalk version), Microsoft has rolled the adapters into BizTalk Host Integration Server 2010.

Licensing for HIS 2010 is included as part of BizTalk 2010 (6th bullet point down), so there are no worries about that.

If you just want the BizTalk adapters, configuration of HIS 2010 is not neccessary. Thanks to Stephen Jackson and Ben Cline for quick response and clarifications.

BizTalk 2010 Adapter Pack 2.0 install issues

I'm installing a new instance of BizTalk 2010 server, and wanted to add the WCF-SQL adapter. This requires the BizTalk LOB Adapter SDK 2010 as a prerequisite. The OS is Windows Server 2008R2, 64-bit.

After I downloaded and installed the SDK (x64), I installed the x64 version of the Microsoft BizTalk Adapter Pack (v2.0). I figured at this point I could now go into the BizTalk Administration console and add the WCF-SQL adapter by selecting Platform Settings/Adapters/(right-click) new/Adapter.

The Adapter dropdown list was empty.

It doesn't seem clear, but it seems apparent that you also need to install the x86 version of the Adapter Pack as well. I did not need to install the x86 version of the LOB SDK. Can anyone verify/clarify this?

BizTalk's Table Looping Functiod in detail

There are several posts based on the Table Looping Functiod:

• Evan Koch


• Dan Schulz - dead link, view via Wayback Machine


• flatlander, explaining a repeating structure


• and BizTalk and .NET Stew, who explains the gated concept

These are all great examples, but I'd like to get into detail of what may happens when using flatlander's example without using the BizTalk .NET Stew example.

I'm going to copy flatlander's example. My source file looks like this:

Take note that I have 3 Chef nodes, but only 1 MaitreD node.

Testing the map produces the below output:


Notice that I have 3(?!) MaitreD instances of Mr. Cook. That isn't right. My initial suspicions are that you will iterate both the same time as the node which has the highest number of iterations. So if node Chef has 3 iterations (child nodes), you will have the same iterations in your output with your MaitreD nodes.

Not quite what I want.

So, going on, I'm following what BizTalk and .NET Stew explains, by using the gated functionality of the functoid. The question becomes now: How do I gate the input if I only have fewer iterations of one node vs. the other?

Being that the two root nodes in the source are iterative, I can determine which iteration I am on from the source. Taking that one step further, I can also determine if a particular iteration of a node is not null. The assumption is that the node you are comparing cannot be null.

So in this exercise, let's take the Chef/Name and MaitreD/Name as the 'gate' nodes to compare, since I have determined they cannot be null or empty. If a node at a particular index doesn't exist (i.e. Chef/Name[20]), then it will be blank/null. I pipe the 'value' of that index to a NotEqual functoid. I compare it to an empty string, and from there I should have a boolean value which determines if that index of the node exists - my gate.



Let's take a look into the functoid's configurations.
Index:


And NotEqual. The string value is empty (no spaces).


I use these two outputs as column1 of the Table Looping functiod. Also note that I have the Gated checkbox checked, as in BizTalk and .NET Stew explains:


Testing the map, and you have a cleaner representation of the output:


This may not be the most elegant solution, but in this scenario we are using only functiods in the map and staying away from XSLT, scripting, or an external assembly - as many have suggested to do instead.

I personally lean towards the approach that if it's not too difficult, stay within a single pattern or two for supportablity within your development environment.

Scheduled task may execute indefinitely when using certificates on Windows

I'm an administrator of an FTP server (on Windows Server 2008R2) which has a well-known FTP client on it. We use SSH and SSL, depending on our partners. Most of the time we use scheduled tasks to trigger FTP scripts. I've been noticing within the Windows Task Scheduler that tasks aren't completing, and are always in a 'running' state.

Typically I use my account to log in and make changes. However, I use a different local adminstrator account to execute the scheduled tasks. I have found out that this is bad practice.

In my case, when using SSL, SSH, (and I *think* PGP), the keys are saved somewhere within the C:\Users\{username}\AppData folder. I believe this is a common practice throughout the industry - not sure if this is a Microsoft policy.

So when you log in using a different username to set up the environment and use a different username to execute the task, your results aren't as anticipated. This is likely due to the fact that the keys you saved/accepted are NOT in the proper user folder.

I logged into the server using the same credentials as the scheduled task, accepted the certs, and all has been working well since.

BizTalk Inline XSLT Call Template and Namespaces

If you have used the Inline XSLT Call Template at all, you will notice at times that your map will validate just fine, but the output may not be exactly what you want (sometimes just an empty single node).

A little gotcha is that you need to be aware of the namespaces within your schemas, or the output of your map will be less than desirable.

Let's take a simple scenario. I'm mapping one source schema to a single destination schema.



In this example, I'm trying to iterate through a node and essentially pass the input parameter through:



Unfortunately my output looks a little small:



Interesting. Not a single error, but not what I was expecting.

The problem here is that with my XSLT code, I overlooked the namespace of my source schema. To get the proper namespace, I save the latest version of my map, validate it,



...and then take a look at the output XSL file. The location of this file is displayed in the output window.



Within the .xsl file, I will now be able to get the proper namespace of my schema,



In this case, the namespace is s0, as in s{zero}. Now I can apply this to my XSTL Call functoid.



A subtle difference, with drastic results:

Creating Dev SharePoint 2010 Instance

I'm installing a development BizTalk 2010 environment. Part of the environment is to install a local SharePoint 2010 instance.

Like other blog postings, you'll come across using New-SPConfigurationDatabase command to create the database ad-hoc.

What you may not notice is that you need to use the SharePoint 2010 Management Shell, not the base PowerShell. It's located within the Microsoft SharePoint 2010 Products folder in the Start Menu.