ESB Toolkit  Configuration Files

1. On every computer where ESB Toolkit is configured, navigate to C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.0, and make a backup of the file esb.config before any modification.
2. Open the esb.config file for editing.
3. Under ConnectionString node, change the Data Source attribute to point to the new Database cluster:
4. <connectionStrings><add name="ItineraryDb" connectionString="Data Source=NEWDBSERVER;Initial Catalog=EsbItineraryDb;Integrated Security=True"providerName="System.Data.SqlClient" />...</connectionStrings>
5. Save the edited file.
6. On every computer running BizTalk Server, navigate to C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.0\Bin, and make a backup of the file “ESBConfigurationTool.exe.Config”  before any modification.
7. Open the ESBConfigurationTool.exe.Config file for editing.
8. Change below keys to point to the new SQL Cluster:

9.            <add key="ItineraryServerInstance" value="NEWDBSERVER" />

              <add key="ServerInstance" value="NEWDBSERVER" />

10. Save the edited file.

ESB Portal Configuration Files

1. On every computer where ESB Portal is configured, navigate to C:\inetpub\wwwroot\esb.portal make a backup of the file Web.config before any modification
2. Open the Web.config file for editing.
3. Under connectionStrings node, change the Data Source attribute to point to the new Database cluster<connectionStrings>...<add name="AdminDatabaseServer" connectionString="Network Library=dbmssocn;Data Source=NEWDBSERVER;Integrated Security=True;Initial Catalog=ESBAdmin;" providerName="System.Data.SqlClient"/>...</connectionStrings>
4. Save the edited file.
5. Repeat Step 1-4 for the file C:\inetpub\wwwroot\esb.portalONO\Web.config

UDDI Services Registry Information

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\UDDI\Database\ReaderConnectionString
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\UDDI\Database\WriterConnectionString
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\UDDI\Setup\WebServer\databaseName

Custom Configurations files

1. Make a backup of *.config before any modification
2. Edit each configuration file and modify “Data Source” attribute to point to the new SQL Cluster. Note: The easy way to accomplish this is replacing all occurrences of   ‘OLDDBServer’ by ‘NEWDBSERVER’.
3. Save the edited file

• C:\program files (x86)\Microsoft BizTalk Server\
• C:\Program Files (x86)\Microsoft BizTalk Server\Tracking
• C:\Program Files (x86)\Microsoft BizTalk Server\BAMPortal\BAMManagementService

ESB Send Ports

After upgrading IBM MQ to v8.0, you start observing below errors in MQ Server related to Microsoft MQAgent:

• Log Name:      Application Event ID:      4786 Level:         Error Keywords:      Classic Description: The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below. Server Application ID: {C691D827-19A0-42E2-B5E8-2892401481F5} Server Application Instance ID: {2C537DA2-535B-424F-AF91-B75498C6F40B} Server Application Name: MQSAgent2 The serious nature of this error has caused the process to terminate. Exception: C0000005 Address: 0x742C83EB

• The adapter "MQSeries" raised an error message. Details "Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.BizTalk.Adapter.MQS.Agent.IMQSAgent'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{EB62BF71-65F5-4C0B-AEC2-8CFE02754F6E}' failed due to the following error: The authentication service is unknown. (Exception from HRESULT: 0x800706D3).".

• For 32-bit applications: SET PATH=<install folder>\bin\vs2005
• For 64-bit applications: SET PATH=<install folder>\bin64\vs2005

• Get-AzureRmVM : The term 'Get-AzureRmVM' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At C:\Scripts\psManageAzureRGVM.ps1:56 char:23 +         $AzureRGVMs = Get-AzureRmVM | foreach {$_.Name + "," + $_.Res ... +                       ~~~~~~~~~~~~~ + CategoryInfo          : ObjectNotFound: (Get-AzureRmVM:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException

• Action (Mandatory)]: Specifies the action you want to execute: CHECK, STOP or START. No default value.

• vmListToManage (Optional) : Specifies the list of ARM Virtual Machines you would like to manage. Empty value would mean all existing VM within your subscription. Default Value = Empty
• resourceGroupListsToManage (Optional): Specifies the list of Resource Managers you would like to manage. Empty value would mean all exisiting Resource Group within your subscription. Default Value = Empty
• forceRmAccountReload : Specifies whether you want to force Azure Rm Account reload. Default Value =False

• Check the status of all existing ARM Virtual Machines within your subscription.
• Start specific ARM Virtual Machines.
• Stop ARM Virtual Machines belonging to specific Resource Group Names

• Service Bus Gateway: All incoming requests from clients are first received and processed by the Service Bus gateway. The protocol heads process the requests and perform the necessary authentication, authorization, and address resolution. The request is then forwarded to the appropriate message broker (which can reside on the same machine or remotely in another server of the farm)
• Service Bus Message Broker: Manages the send and receive operations from Service Bus queues/topics/subscriptions, hosting one or more message containers. The service registers itself with Windows Fabric to provide high availability in this component.
• Windows Fabric: This process contains the core logic necessary for high availability, farm and cluster formation, and internal Service Bus Message Broker balancing across computers in the farm.

• Gateway: This is the ‘visible’ Endpoint for Service Bus client application. Depending how client application define connection string to Service Bus Gateway:
  • Client app supports Multiple SB nodes in Connection String. The client application will try with the first one, if that node is down, the client will contact the next SB node. You achieve high availability as long as you specified all SB Nodes as connection string.
  • Client app supports just one SB Node in Connection String. If just one SB node can be specified, such as the case for BizTalk SB-Messaging Adapter, then the SB node you are pointing might become a single point of failure for your infrastructure, regardless the fact you have 3 or 5 SB nodes Farm. This is the scenario where configuring Load Balance for Service bus makes sense to achieve High Availability in this component.
  • Note: To avoid such single point of failure at Service Bus Gateway service, you should use a Virtual Service Bus name as connection string, instead of pointing directly to one of the nodes of the SB farm.

• Message Broker: This service registers itself with Windows Fabric to provide high availability in Broker component. Windows Fabric contains the core logic necessary for high availability, farm and cluster formation, and internal Service Bus Message Broker balancing across computers in the farm. The only thing you should consider to achieve such High Availability is having 3 or 5 SB Nodes Farm.

• [1.RunOnOneNode] Stop-SBFarm Set-SBFarm -FarmDns ‘SBFarm.contoso.com’
• [2.RunOnAllNodes] Update-SBHost
• [3.RunOnOneNode] Start-sbfarm

You get the following error message when trying to install Microsoft BizTalk 2013 R2 Accelerator for HL7:

“Error: Installation cannot be performed because the BizTalk server has not been configured or user account is not a member of the BizTalk Server Administrators group.”

1.     Confirm that user executing Microsoft BizTalk 2013 R2 Accelerator for HL7 is part of the BizTalk Server Administrator Group.

2.     If installing HL7 in a distributed environment, computer and logged user  (the one executing HL7 wizard) must have access to Primary Domain Controller (PDC).  If it fails to access PDC, it will fail early on in the installation and it won’t allow you to continue.

3.     BizTalk Server should have a default 32bit BizTalk Host ‘BizTalkServerApplication’.

4.     Confirm that SQL client tools is installed on BizTalk servers.

1. Execute Workflow Manager Configuration Wizard, selecting the option either “Configure Workflow Manager with Default Settings” or “Configure Workflow Manager with Custom Settings” depending on your preferences. Follow the wizard till you reach the “Summary” tab and then click “Get PowerShell Commands”.

2. Modify connection string accordingly. Please notice that you can modify the connection string for both “Workflow Manager” and also for “Service Bus”. Following our example, we are modifying all the connections string to add “Failover Partner” attribute, for simplicity just parameters for New-WFFarm cmdlet is shown:

New-WFFarm WFFarmDBConnectionString 'Data Source=<SQL Server>;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False; Failover Partner=<SQL Mirroring Server>' -InstanceDBConnectionString 'Data Source= <SQL Server>;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Encrypt=False; Failover Partner=<SQL Mirroring Server>' -ResourceDBConnectionString 'Data Source= <SQL Server>;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Encrypt=False; Failover Partner=<SQL Mirroring Server>' -AdminGroup 'BUILTIN\Administrators' -HttpsPort 12290 -HttpPort 12291-CertificateAutoGenerationKey $WFCertAutoGenerationKey -Verbose;

It is important to highlight that Direct update of DB is not possible (to adhere to Windows Server Security Guidelines all Secure strings are encrypted, also modifying db is not just enough as there are other places where this info is present). So, follow below steps to modify existing connection strings:

1.  Execute "Get-WFFarm" cmdlet, to collect information about your current configuration: Certificates thumbprint, connection string, RunAsAccount , Ports numbers, etc. You will need that info on step 3 and 4.

2.  Remove all nodes from the Workflow Manager Farm. You can do that from Workflow Configuration Wizard (selecting the option  ‘Leave Farm’) or by using Remove-WFHost powershell cmdlet.

3. On one of the farm nodes, call the Restore-WFFarm using the new Connection string. . The cmdlet would be like below:

$SBCertificateAutoGenerationKey = ConvertTo-SecureString -AsPlainText  -Force  -String '<Pwd you specified during configuration>' -Verbose;

Restore-WFFarm  -RunAsAccount 'Administrator' -WFFarmDBConnectionString 'Data Source=<SQL Server>;Initial Catalog=WFManagementDBNew;Integrated Security=True;Encrypt=False; Failover Partner=<SQL Mirroring Server>' -InstanceDBConnectionString 'Data Source= <SQL Server>;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Encrypt=False; Failover Partner=<SQL Mirroring Server>' -ResourceDBConnectionString 'Data Source= <SQL Server>;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Encrypt=False; Failover Partner=<SQL Mirroring Server>' -CertificateAutoGenerationKey $SBCertificateAutoGenerationKey -HttpPort 12291 -HttpsPort 12290 -InstanceStateSyncTime 'Monday, August 31, 2015 10:30:00 AM' -ConsistencyVerifierLogPath 'c:\ConsistencyVerifierlog.txt' –Verbose;

Note: When using Auto-generated certificates, Restore-WFFarm will create a new set of certificates, so thumprint in Workflow Manager Farm (get-WFFarm) will change. If you are using WFM from SharePoint, then you should import the new certificate into SharePoint servers.

Note: The Restore-WFFarm cmdlet creates a new Workflow Management database (WFManagementDBNew, you can delete the old WFManagementDB at the end of this procedure. Once above cmdlets are executed, next two connections strings will have been changed: InstanceDBconnectionString and ResourceDBConnectionString.

4. On all WFM farm nodes, run the Add-WFHost cmdlet.

$WFRunAsPassword = convertto-securestring "<RunAs Account Password>" -asplaintext -force

$WFCertAutoGenerationKey = ConvertTo-SecureString -AsPlainText  -Force  -String '<Pwd you specified during configuration>' -Verbose;

$SBClientConfiguration = Get-SBClientConfiguration -Namespaces 'WorkflowDefaultNamespace' -Verbose;

Add-WFHost -WFFarmDBConnectionString 'Data Source=BTS2013AAW;Initial Catalog=WFManagementDBNew;Integrated Security=True;Encrypt=False;Failover Partner=<SQL Mirroring Server>' -RunAsPassword $WFRunAsPassword -EnableFirewallRules $true -SBClientConfiguration $SBClientConfiguration -EnableHttpPort  -CertificateAutoGenerationKey $WFCertAutoGenerationKey -Verbose;

5. If you also need to update connection string for Service Bus databases, then follow the procedure described at https://blogs.msdn.com/b/feseca/archive/2015/01/19/how-to-modify-service-bus-connection-string-in-an-existing-service-bus-farm.aspx

You are trying to deploy into Workflow Manager a SharePoint Workflow 2013 from SharePoint designer, but you got the following error:

By default, the maximum number of Arguments that a workflow can receive in Workflow Manager is 50. However, you can modify it as required.

The only supported way to modify configuration parameters in Workflow Manager is by using WFM PowerShell cmdlets. For this specific case the cmdlet  to use is “Set-WFServiceConfiguration.”. Below all the steps required:

 a)    Change the value of “WorkflowServiceMaxArgumentsPerActivity” parameter by executing:

Set-WFServiceConfiguration -ServiceUri <Your WFM FQN URI> -Name WorkflowServiceMaxArgumentsPerActivity -Value <New Value>

b)     Confirm that the value was changed properly by executing: Get-WFServiceConfiguration -ServiceUri <Your WFM FQN URI> -name WorkflowServiceMaxArgumentsPerActivity

c)     Restart WFM services so that the change takes effect: Open a Workflow Manager Powershell command and execute "Stop-WFHost" and then "Start-WFHost" in every WFM server.

 1.  Execute "SB-GetFarm" cmdlet, to collect information about your current configuration: Certificates thumbprint, connection string, RunAsAccount , MessageBrokerPort , etc. You will need that info on step 3.

 2.  Remove all nodes from the Service Bus Farm

 3. On one of the farm nodes, Restore the SBFarm using the new Connection string. As an example, let’s imagine that we need to modify SB connection string to add “Failover Partner” attribute. The cmdlet would be like below:

Restore-SBFarm -FarmCertificateThumbprint F91C37410FBE53B92E1B24FAC7A0D82EA4391B81 -GatewayDBConnectionString "Data Source=<SQL Server>;Failover Partner=<SQL Mirroring Server>;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False" -SBFarmDBConnectionString "Data Source=<SQL Server>;Failover Partner= Mirroring Server>;Initial Catalog=SbManagementDBNew;Integrated Security=True;Encrypt=False" -EncryptionCertificateThumbprint  91C37410FBE53B92E1B24FAC7A0D82EA4391B81 -RunAsAccount <YourAccount> -MessageBrokerPort <MessageBrokerPort> -HttpsPort <HttpsPort> -TCPPort <TCPPort>

Note: The Restore-SBFarm cmdlet creates a new Service Bus for Windows Server farm database (SbManagementDBNew). You can delete the old Service Bus for Windows Server farm database. Once above cmdlet is executed, next two connections strings will have been changed: GatewayDBConnectionString and SBFarmDBConnectionString

4. On all new farm nodes, run the Add-SBHost :

$secure_string_pwd = convertto-securestring "<Your Password>" -asplaintext -force

Add-SBHost -SBFarmDBConnectionString "Data Source=<SQL Server>;Failover Partner=<SQL Mirroring Server>;Initial Catalog=SbManagementDBNew;Integrated Security=True;Encrypt=False" -RunAsPassword $secure_string_pwd -EnableFirewallRules $T

5. Call the Stop-SBFarm cmdlet to stop all Service Bus for Windows Server services on all hosts, that’s a prerequisite for next step.

6. Restore the message containers. This step is required to modify the connection string to the message containers. Remember that you can have more than one (For more information, see the Get-SBMessageContainer cmdlet).

 Restore-SBMessageContainer -Id 1 -ContainerDBConnectionString "Data Source=<SQL Server>;Failover Partner=<SQL Mirroring Server>;Initial Catalog=SBMessageContainer01;Integrated Security=True;Encrypt=False"

7. Call the Start-SBFarm cmdlet to start all Service Bus for Windows Server services on all hosts.

You have Service Bus 1.0/1.1 installed in a Service Bus Farm. You observe a five minutes delay when you restart Service Bus Farm Services (by executing "SB-StopFarm" and "SB-StartFarm")

In Microsoft-ServiceBus Operational Windows log several Informational messages like below are shown:

 Windows Fabric Runtime create failed (Retries left 6) Exception System.TimeoutException: Operation timed out. ---> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80071BFF   at System.Fabric.Interop.NativeRuntime.FabricEndCreateRuntime(IFabricAsyncOperationContext context)   at System.Fabric.FabricRuntime.NativeFabricRuntimeFactory.InitializeFabricRuntimeEndWrapper(FabricRuntime runtime, AsyncCallOutAdapter adapter)   at System.Fabric.Interop.Utility.FinishNativeAsyncInvoke[TResult](String functionTag, Func`2 endFunc, TaskCompletionSource`1 source, AsyncCallOutAdapter adapter, Boolean expectCompletedSynchronously)

   --- End of inner exception stack trace ---   at System.Fabric.FabricRuntime.Create(Action fabricExitCallback)    at Microsoft.Cloud.ServiceBus.MessageContainerHost.Ring.Join()

The delay is caused by Windows Fabric and the behavior is by design. When you take down the entire ring (Stop-SBFarm) and bring it back online (Start-SBFarm) it waits for a global lease duration of 5 minutes before it reforms the ring. This is to prevent split brain.

So, if you wait for 5+ minutes after "Stop-SBFarm" to let go off the global lease duration, and then run "Start-SBFarm", it will complete normally within a few seconds.

You cannot see any BizTalk Performance counters for a specific BizTalk Isolated Host

1. BizTalk Performance counters are just shown for Active Biztalk Process:

• [In-process] BizTalk services running • [Isolated] Hosting process running with BizTalk information loaded, so that it is linked with Biztalk receive locations.

Note: If you are using any BizTalk Web Services (.svc or wsdl), Hosting process is running within IIS worker Process (App Pools).

If your isolated BizTalk Host is not shown in Performance Counters, that would means that Hosting Process is not linked with your Biztalk receive locations:

1. There has not been any call to any of the BizTalk Web Services linked with this BizTalk Host (SOAP/WCF receive location). 2. IIS worker process has been unloaded after inactivity period, by default it is after 20 minutes.

In order to be able to see BizTalk Performance Counters for you BizTalk Isolated Host, you need to make sure that Hosting process is running with BizTalk information loaded, so that it is linked with Biztalk receive locations. To confirm this is the reason why you cannot see the performance counter in your enviornment, please try one of the following actions :

1. Send a message through any of the Receive Location linked with this Isolated Host. 2. Open an Internet Explorer, and browse to any of the URL defined as Receive Location linked with this Isolated Host.