wiki

Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Friday, April 26, 2013 3:34 PM

[When troubleshooting a credentials issue in BizTalk on a file share, it turns out Windows stored password configuration was used instead of the credentials saved in BizTalk host.

Hello,

One of our Managed Services customers had a problem where a message got suspended with the following error:

They already looked into the issue, tested the username and password for the share, etc ...
The platform is a multi-server platform with 2 BizTalk servers within the same BizTalk group.

Troubleshooting

I was digging into the issue and saw that it was very likely that only one of the servers had the issue (the server where the message got suspended was always the same). 

So during the retry within BizTalk, some messages got processed by the other server as BizTalk chooses the processing server depending on load...
Sometimes though, a message got only processed through the first server, leading to a suspended message eventually.

I was digging into the eventlog and stumbled into this (system eventlog):

I checked and there was indeed a stored username/password on the first server for connecting to the server hosting the file-share:

(This were credentials of a BizTalk operator and his password had changed recently).

When I removed the stored credentials the issue was resolved. (Also when you define the credentials in the send port configuration).

So stored credentials were used instead of the credentials defined in the BizTalk host to connect to the fileshare!

For more information on stored passwords, please see MSDN: http://technet.microsoft.com/en-us/library/cc733968(v=ws.10).aspx

Hope this helps,

Brecht

Categories: BizTalk
Tags: SSO

Posted on Thursday, November 23, 2017 1:07 PM

Maxim Braekman by Maxim Braekman

Jacqueline Portier by Jacqueline Portier

Starting with SQL Server 2016, SQL Server AlwaysOn Availability Groups supports MSDTC for on-premises and using Azure VMs. As a result, the SQL Server 2016 AlwaysOn feature is supported for BizTalk databases on-premises or in Azure IaaS scenarios.

In a High Availability scenario, however, you will want to cluster the master secret server as well. You can perfectly use the SQL Server Cluster for that purpose. Microsoft has outlined to steps for clustering the SSO server in this article.

However, in Azure, some additional steps are required, which will prevent you from running into the below error message:

The master secret server (cluster-resource-name) specified by the SSO database could not be found 0xC0002A0F Could not Contact the SSO Server %1.

In this article we will describe the steps to solve this problem. We assume the Always On cluster is already installed. If not, you can find directions here and here.

Add a generic service to the cluster

Navigate to the Failover Cluster Manager on one of the SQL-servers and go to the Roles-overview. Add an additional ‘Generic Service’-role to your SQL-cluster and select the 'Enterprise Single Sign-On Service'-service from the list. Assign a name to the new role, for instance 'SSO'.

 

 

Once the role has been created, make sure to assign a static IP-address, by adjusting the properties of the ‘IP Address’-resource. In this case ’10.2.1.10’ was used:

 

 

Add a new Frontend IP Pool to the load balancer

Navigate to the Internal Load Balancer by using the Azure portal and create a new Frontend IP Pool for the static IP address you assigned to the SSO cluster resource. Make sure to select the same subnet as the SQL-servers are located in. 

Next to the IP-address, an additional health probe needs to be created as well, as this will be used in the background to forward the request. Like previously created probes, create an additional probe, referring to an unused port. In this case, the port ‘60005’ has been chosen.

Finally create a new rule that maps port 135 to 135.

 

Make sure to also execute this PowerShell-command, to set several cluster-parameters for this SSO-role, similar as what should have been done for the SQL-roles. This time fill in the IP-address and name used for the SSO-cluster.

As was the case for the SQL-servers, this command only has to be executed on a single node within the cluster, as this will connect the load balancer’s health probe, as configured in the Azure Portal, to this cluster role.

 

Add Loadbalancer rules for each of the ports used by SSO

Because we need to create a load balancing rule for each of the ports used by SSO, we need to limit the range of ports that will be used. To do this, connect to the SQL-servers and perform these steps on all of the servers:

Open Component Services and navigate to ‘My Computer’ and open the properties.

Go to the ‘Default Protocols’-tab and click ‘Properties…’ and make sure to add a range of ports that is located in the ‘Intranet Range’

 

If the port range has been assigned, go back to the Azure Portal, to create the required rules, matching these ports. Make sure to connect these rules to the SSO-IP and SSO-probe we created in the previous step.

This will result into a 'long' list of load balancing rules for all the used ports:

 

Creating the loadbalancer rules manually is a tedious task. Luckily we can script it with PowerShell. 

 

MSDTC

A similar action will be required for MSDTC, as a load balancing rule is required for all communication between the servers. However, for MSDTC you are able to specify a fixed TCP-port instead of a range of ports.

To do this, the below command can be executed, in order to add an entry in the registry to make sure that MSDTC will stick to port ‘20021’, in this case.

reg add HKLM\SOFTWARE\Microsoft\MSDTC /v ServerTcpPort /t REG_DWORD /d 20021 /f

Note: Afterwards a reboot of the servers might be required before this change in the registry will become active.

While we are at the process of editing the registry, let’s keep at it, because in order to ensure that COM+ will be accessible from all servers, the below command needs to be executed on all SQL- and BizTalk-servers as well.

reg add HKLM\SOFTWARE\Microsoft\COM3 /v RemoteAccessEnabled /t REG_DWORD /d 1 /f

Note: Afterwards a reboot of the servers might be required before this change in the registry will become active.

Finally!

When all these configurations are in place, you should be able to go ahead and create a new redundant SSO system on your SQL Server Always On cluster.