There are many things to consider when planning this type of installation. This whitepaper will explain in detail – a step-by-step guideline – how to install and configure Microsoft BizTalk Server 2020 on a basic multi-computer environment using Windows Server 2019, i.e., installation of BizTalk Server with a remote SQL Server (1 SQL Server and 1 BizTalk Server). There will be 3 virtual servers:
1 Domain controller
1 Virtual Machine to host SQL Server
Windows Server 2019
SQL Server 2019SQL Server 2019 Enterprise Edition
1 Virtual Machine to host BizTalk Server.
Windows Server 2019
BizTalk Server 2020 Enterprise or Development Edition
In this scenario, I will perform a basic full installation of Microsoft BizTalk Server 2020, except for the SharePoint Adapter and additional components like Accelerators, ESB Toolkit or UDDI, emulating a production environment. The following components will be installed:
Enterprise Single Sign-On (SSO)
BizTalk Group
BizTalk Runtime
Business Rule Engine
BAM Tools and Alerts
BAM Portal (Although Microsoft has deprecated the BAM portal, it is still possible to install it.)
BizTalk EDI/AS2 Runtime
Microsoft BizTalk Adapters
This information will help you plan the installation and configuration of BizTalk Server 2020, applications, and components on which it depends focused on creating a UAT or Production environment (you can also follow this tutorial to help you create developer environments. However, if this is the case, you need to add some steps and additional components or software, in especially Visual Studio 2019).
Of course, it is assumed that all machines are already installed with the operating system and the latest critical Windows updates from Microsoft. Another presumption is that the domain controller is already installed and configured.
What’s in the Whitepaper for you?
This whitepaper will give you a detailed understanding of the following:
The need for a Domain Controller – Windows Groups and Service Accounts
Preparing Computers for Installation – Important considerations before setting up the
servers
Preparing and Install SQL Server 2019 machine
Prepare and install prerequisites on BizTalk Server 2020 machine
There was a lot of inconsistent and incorrect information about the BizTalk WCF-SAP Adapter installation process and how it works, especially in old versions of the adapter where there was a need to use the classic RFC library to connect to SAP.
Fortunately for us, this process is now simpler and more direct, and this is due specifically to two points:
The Classic RFC Library has been discontinued and is no longer supported (support ended on March 21, 2016). All customers should, if not already using, the “new” SAP .NET Connector (NCo)
Notice that the BizTalk Adapter Pack WCF-SAP adapter has been re-engineered to use SAP .NET Connector instead of the classic SAP RFC SDK. The SAP .NET Connector is available through the ConnectorType property within the WCF-SAP binding. This feature is available from BizTalk Server 2013 and above.
On BizTalk Server 2020, the Microsoft BizTalk Adapter Pack x86 and x64 are now installed with the default installation process. That means that the WCF-SAP adapter is already registered on the server and present on the BizTalk Server Administration Console.
However, that does not mean that everything is ready for you to be able to use this adapter. Unfortunately, you still need to install the SAP Connector for Microsoft .NET available for you to download through the SAP Service Marketplace.
Notice that, like any other adapter, the 64-bit version of the SAP Connector for Microsoft .NET is optional, but if you have a 64-bit BizTalk environment and you want to run it under a 64-bit Host Instance, then you need to also install both versions of the SAP Connector for Microsoft .NET.
BizTalk Server 2020: Step-by-Step WCF-SAP Adapter installation guide
By reading this whitepaper, decision-makers should have more information on the following areas:
Pre-requirements resources that are necessary and how to install them
Register the adapter in BizTalk Server Administration Console
I’ve been a big fan of this amazing Visual Studio Addin for BizTalk Server since the first days that Nino Crudele decided to create this resource. I still remember the long hours during the night that we were discussing the features and testing this addin using skype. And I have continued to be a fan since BizTalk360 took over this resource.
The purpose of BizTalk NoS Ultimate is to help all BizTalk Developer, and why not, all BizTalk Administrators, in a lot of different situations, by improving the developer experience and reducing the development time in new or existing BizTalk projects, providing better documentation and help to troubleshoot some scenarios/issues you may encounter. But it is mainly a Visual Studio Add-in that enables BizTalk Server developers to be more efficient.
BizTalk development is not pretty easy and requires a lot of patience sometimes, and anyone who has worked with BizTalk long enough will acknowledge this statement. For instance:
It takes immense effort to find out the internal & external dependencies between different artifacts (schemas, maps, orchestrations, and so on).
Testing pipelines within the Visual Studio is not possible.
Some tasks occupy a massive time during development and eventually may delay the project. Unfortunately, no other tool in the market helps in making the BizTalk developer’s lives easier. That is why I love this tool: BizTalk NoS Ultimate.
BizTalk NoS: Your BizTalk Dev Buddy
And now, I also decided to create a whitepaper in a way to be a step-by-step guide to help you get started with the tool and explain all the features available like:
Quick search inside artifacts
Fast DLL register/unregister in GAC
Find critical, internal, or external dependencies
JackHammering, which will compare your VS artifact with the artifact deployed in the BizTalk environment
With this feature, you can also extract the artifact (Orchestration, map, Schema, and so on) from the BizTalk environment and put it in the VS solution
Test your pipeline in VS simply
And many more functionalities that will be useful in our day-by-day work and a time saver in a lot of situations.
BizTalk NoS Ultimate is available for the following BizTalk Server versions:
Windows Management Instrumentation (WMI) is the Microsoft implementation of Web-Based Enterprise Management (WBEM). Basically is a set of specifications from Microsoft for consolidating the management of devices and applications in a network from Windows computing systems. You can write WMI scripts or applications to automate administrative tasks on remote computers, but WMI also supplies management data to other parts of the operating system and products—for example, System Center Operations Manager (formerly Microsoft Operations Manager (MOM)), or Windows Remote Management (WinRM).
WMI is designed for programmers who use C/C++, the Microsoft Visual Basic application, or a scripting language that has an engine on Windows and handles Microsoft ActiveX objects. Nevertheless, many administrators and IT professionals access WMI through PowerShell. The Get-WMI cmdlet for PowerShell enables you to retrieve information for a local or remote WMI repository.
WMI comes pre-installed on Microsoft’s newest operating systems.
The purpose of WMI is to help administrators manage different Windows operational environments, including remote systems. One big advantage of WMI is that it reduces maintenance and the cost of managing enterprise network components.
BizTalk Server WMI classes
Windows Management Instrumentation (WMI) classes are used to programmatically access the administrative functions available in Microsoft BizTalk Server. Working together with PowerShell will be a winning match for IT Teams that need to manage BizTalk Server infrastructure and applications.
The Windows Management Instrumentation (WMI) classes in this table are used to manage the core objects associated with BizTalk Server, such as servers, queues, groups, and message handlers.
Class
Description
MSBTS_AdapterSetting
Registers new adapters with Microsoft® BizTalk® Server.
MSBTS_BTSObject
This type of member supports the BizTalk Server infrastructure and is not intended to be used directly from your code.
MSBTS_DeploymentService
Encapsulates BizTalk assemblies for deployment or undeployment and bindings export or import.
MSBTS_GroupSetting
Represents a logical grouping of BizTalk Servers.
MSBTS_Host
Represents a BizTalk Server Host.
MSBTS_HostInstance
Represents a single instance of a BizTalk Host.
MSBTS_HostInstanceSetting
Updates the IsDisabled property when a host is in the stopped state.
MSBTS_HostQueue
Represents an application.
MSBTS_HostSetting
Creates a BizTalk Server Host setting.
MSBTS_MessageInstance
Represents a message instance.
MSBTS_MessageInstanceSuspendedEvent
Represents a suspended event for a BizTalk Message Queuing (MSMQT) message instance.
MSBTS_MsgBoxSetting
Represents a single MessageBox setting in the BizTalk Server group.
MSBTS_Orchestration
Represents an instance of an orchestration that belongs to the installed module.
MSBTS_ReceiveHandler
Represents an individual receive handler defined by BizTalk Server.
MSBTS_ReceiveLocation
Represents an individual receive location defined by BizTalk Server.
MSBTS_ReceiveLocationOrchestration
Represents all possible combinations of receive locations and orchestrations.
MSBTS_ReceivePort
Represents an individual receive port defined by BizTalk Server.
MSBTS_SendHandler
Represents an individual send handler defined by BizTalk Server.
MSBTS_SendHandler2
Represents an extended individual send handler defined by BizTalk Server.
MSBTS_SendPort
Represents an individual send port defined by BizTalk Server.
MSBTS_SendPortGroup
Represents a group of send ports defined by the BizTalk Server.
MSBTS_SendPortGroup2SendPort
Represents an extended group of send ports defined by the BizTalk Server.
MSBTS_Server
Represents computers within a group that have BizTalk Servers installed.
MSBTS_ServerHost
Reflects mappings between BizTalk servers and BizTalk Hosts.
MSBTS_ServerSetting
Represents specific computers within the BizTalk group that have BizTalk Servers installed. Instances of this class are intended to be created and deleted internally through BizTalk Server only. Do not create or delete instances of this class explicitly through WMI.
MSBTS_Service
This type of member supports the BizTalk Server infrastructure and is not intended to be used directly from your code.
MSBTS_ServiceInstance
Provides an instance of service with a start and stop functionality.
MSBTS_ServiceInstanceSuspendedEvent
Represents a suspended event for a service instance.
MSBTS_Setting
This type of member supports the BizTalk Server infrastructure and is not intended to be used directly from your code.
MSBTS_TrackedMessageInstance
Represents a message instance.
MSBTS_TrackedMessageInstance2
Represents an updated message instance.
What’s in store for you?
This whitepaper will give you a complete overview with a detailed understanding of all BizTalk Server WMI classes and how to use them. For each BizTalk Server WMI classes we will provide a sample on how to use it.
And once again, the Azure Logic Apps team is looking to learn about how are you using BizTalk Server artifacts, this time: what kind of BizTalk Server Custom Pipeline Components are you using in your Enterprise Applications to better understand how Microsoft can best address future integration needs within the Azure Integration Services platform and maybe bring identical capabilities into it.
No matter if you are considering migrating in the future to Azure Integration Services or staying on-premises for a couple of more years (or forever) this is ANOTHER great opportunity to provide feedback to the Microsoft Integration team and positively influence the outcome of new features.
So, for customers that are using BizTalk Server or were using BizTalk Server in the past, this survey is for you! If you are a consulting company providing services to clients using BizTalk Server, this surveyis also for you! The Azure Logic Apps team would love to hear from you!!! They want AGAIN to enter and poke around your brain, your world and gather all the feedback regarding BizTalk Server:
How many Custom Pipeline Components do you have?
Why do you use Custom Pipeline Components?
Within your Custom Pipeline Components, do you leverage message streams?
For messages that are processed by your Custom Pipeline Components, what is the largest file you process?
What is your comfort level with the Custom Pipeline Components that your organization has?
As we consider how to best support Custom Pipeline Component functionality (capabilities) in Azure Integration Services, is there anything that you would like us to consider?
Once again, don’t complain in the future about the lack of features that will suit you better. The team is interested in how they can best support customers transitioning integration workloads to Azure Integration Services (AIS)… you are not going to move to Azure? The survey does not take that long to respond to, so if you are using BizTalk Server try to respond nevertheless, by doing that you can help other customers on their journey.
I did my part!
Please fill out the following survey to help Azure Logic Apps:
And ONCE AGAIN! For the bad mouths of this universe or for those who like to create rumors because they have nothing to say… this survey does not mean that BizTalk Server is dead! The goal is to help Microsoft prioritize upcoming investments in Azure Integration Services (AIS).
And the most expected email arrived, this time on 5th July! Once again, I’m delighted to share that I was renewed as a Microsoft Azure MVP (Microsoft Most Valuable Professional). I’m deeply humbled to have received this award for the 12th year in a row.
Thank you Microsoft for this outstanding award and for continuing this fantastic journey and experience in the MVP Program. For me, this journey started in 2011 as BizTalk MVP, and since then, it has given me the opportunity and still does, to travel the world for speaking engagement, sharing knowledge, and meeting the most impressive and skilled people in our industry.
This longevity in the program currently makes me the “Godfather” of the Portuguese MVPs alongside my dear friend Rodrigo Pinto (but I am a few months older :)).
Jokes apart, I want to send a big thanks to Cristina González Herrero for all the fantastic work managing the program in my region. To Microsoft Portugal and to Microsoft for empowering us to support the technical communities. To my coworkers and team at DevScope, all my blog readers, friends, and Microsoft Enterprise Integration Community members, and in special to my beautiful family – THANKS! Thanks for your support during these years.
It’s a big honor to be in the program and be one of this fantastic worldwide group of technicians and community leaders who actively share their high-quality and real-world expertise with other users and Microsoft. I’m looking forward to another great year!
Long time since I played with PowerShell and BizTalk Server, but today I had a request from one of my clients who want to restart to SAP receive locations on a scheduled base. So, while helping them, I decided to publicly publish a series of resources related to this:
How to restart a BizTalk Server Receive Location with PowerShell/BizTalk360 – will be soon published on the BizTalk360 blog
How to restart a BizTalk Server Send Port with PowerShell/BizTalk360 – will be soon published on the BizTalk360 blog
How to restart a BizTalk Server Send Group with PowerShell/BizTalk360 – will be soon published on my blog
and this one of course.
There may be several reasons we want to stop and start BizTalk Server applications. One of the reasons is for planned external or internal systems interventions. For example, we know that our external system is down for maintenance on the first day or the last day of each month. There are several ways to do this, Stopping only the send ports or the receive location or entirely stopping the application.
You can do this by using BizTalk360, and many customers are actively using it, but that doesn’t mean that you cannot use this PowerShell script. Actually, BizTalk360 allows you to extend its out-of-the-box capabilities by allowing you to integrate PowerShell scripts with BizTalk360.
Of course, to use this script on a scheduled basis, you need to use it inside BizTalk360, or you can create a Task Scheduler on the BizTalk Server machine or any other machine with access to BizTalk Server.
PowerShell to Stop and Start a BizTalk Server Application
With this script, we can accomplish exactly that: Stop or/and Start a BizTalk Application by using PowerShell.
The function below accepts the BizTalk Application name and guarantees that a full stop is made.
function stop-bts-application (
[string]$appName,
[Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer]$btsCataloglog)
{
# Get the BizTalk Application
$application = $Catalog.Applications[$appName]
# Going to check if the application status is stopped or not
if ($application.Status -ne "Stopped")
{
# Force a full stop to the application
$application.Stop("StopAll")
$btsCataloglog.SaveChanges()
}
}
The function below accepts the BizTalk Application name and guarantees that a full start is made.
function start-bts-application (
[string]$appName,
[Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer]$btsCataloglog)
{
# Get the BizTalk Application
$application = $Catalog.Applications[$appName]
# Going to check if the application status is stopped or not
if ($application.Status -ne "Started")
{
# Force a full stop to the application
$application.Start("StartAll")
$btsCataloglog.SaveChanges()
}
}
THESE POWERSHELL SCRIPTS ARE PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
Download
You can download PowerShell to Stop and Start a BizTalk Server Application from GitHub here:
Use BizTalk360 to Start and Stop a BizTalk Application
At the time of writing, the BizTalk360 team is working on v10.3. An important feature of that release will be the Automated Task feature. This will allow you to stop/start/restart ports, orchestrations, host instances, and logic apps on a scheduled basis.
See below, a couple of screenshots of the feature. Be aware, that the feature has not been released, so the screenshots are subject to change.
Azure Logic Apps team is looking to learn about how are you using BizTalk Server Business Rules Engine (BRE) and how often you deploy them to better understand how Microsoft can best address future integration needs within the Azure Integration Services platform and maybe bring identical capabilities into it.
No matter if you are considering migrating in the future to Azure Integration Services or staying on-premises for a couple of more years (or forever) this is ANOTHER great opportunity to provide feedback to the Microsoft Integration team and positively influence the outcome of new features.
So, for customers that are using BizTalk Server or were using BizTalk Server in the past, this survey is for you! If you are a consulting company providing services to clients using BizTalk Server, this surveyis also for you! The Azure Logic Apps team would love to hear from you!!! They want AGAIN to enter and poke around your brain, your world and gather all the feedback regarding BizTalk Server BRE:
What type of Business Rules facts are you using?
Explain how you use these features
How frequently do you deploy new versions of your policies?
How important is publishing your policies outside of your integration configuration?
Do you need to specifically call a version of your policy or is the latest version sufficient?
Is using the existing BizTalk Rules Composer to create/edit rules acceptable, if your rules end up being deployed to Azure?
Do you use the Policy Tracking Feature?
Do you use the BizTalk Rules Engine from outside of BizTalk?
Do you have sensitive information stored in your Policies?
or to Briefly describe your business scenario that the Business Rules Engine addresses
Once again, don’t complain in the future about the lack of features that will suit you better. The team is interested in how they can best support customers transitioning integration workloads to Azure Integration Services (AIS)… you are not going to move to Azure? The survey does not take that long to respond to, so if you are using BizTalk Server try to respond nevertheless, by doing that you can help other customers on their journey.
And ONCE AGAIN! For the bad mouths of this universe or for those who like to create rumors because they have nothing to say… this survey does not mean that BizTalk Server is dead! The goal is to help Microsoft prioritize upcoming investments in Azure Integration Services (AIS).
I did my part!
Please fill out the following survey to help Azure Logic Apps:
As you most likely are aware, when a document is received by a BizTalk Server adapter, the adapter creates a BizTalk message for the document. The BizTalk message contains the document that was received as well as a message context. The message context is a container for various properties that are used by BizTalk Server when processing the document. Each property in the Message Context is composed of three things, a name, a namespace, and a value.
Message context properties are added to the message context throughout the lifetime of the message as it passes through the BizTalk Server. These properties:
Are either extracted from the message itself, for example, order id or shipment number
Or added by pipelines and adapters at the receive location, for example, transport name or receive port name
There are mainly two benefits of this context:
The first is to provide the various components of BizTalk, an easy access to these properties, without having to parse the message
The second is to support content-based routing.
There are two different types of message context properties used by BizTalk as described below:
Distinguished Fields
Property Fields.
In this whitepaper, you will learn the key differences between Distinguished and Property Fields but most importantly you will have access to a complete list of known property schema and properties used internally by the BizTalk Server out-of-the-box components.
What’s in store for you?
This whitepaper will give you a detailed understanding of the following:
BizTalk Message Context Properties
What are Property fields and how to promote properties?
What are distinguished fields and how to create a distinguished field?
Summary of differences between Property Fields and Distinguished Fields
System property schema and properties
Error Report property schema and properties
Legacy schema and properties
Microsoft BizTalk XLANGs BTXEngine schema and properties
Message Tracking schema and properties
BizTalk Framework Schema and Properties
MIME-SMIME Property Schema and Properties
XML and Flat File Property Schema and Properties
File adapter property schema and properties
FTP Adapter Property Schema and Properties
HTTP Adapter Property Schema and Properties
MQSeries Adapter Property Schema and Properties
MSMQ Adapter Property Schema and Properties
POP3 Adapter Property Schema and Properties
SMTP Adapter Property Schema and Properties
SFTP Adapter Property Schema and Properties
SOAP Adapter Property Schema and Properties
SQL Adapter Property Schema and Properties
WCF Adapters Property Schema and Properties
Windows SharePoint Services Adapter Property Schema and Properties
Azure Service Bus Adapter Property Schema and Properties
Azure Blob storage Adapter Property Schema and Properties
Azure Event Hubs Adapter Property Schema and Properties
Office 365 Outlook Calendar Adapter Property Schema and Properties
Office 365 Outlook Contact Adapter Property Schema and Properties
Office 365 Outlook Email Adapter Property Schema and Properties
SharePoint Online Adapter Property Schema and Properties
Microsoft BizTalk Accelerator for HL7 (BTAHL7) Property Schema and Properties
How to write or promote properties in the context of a messages through the BizTalk API
Azure Logic Apps team is looking to learn about your BizTalk architectures and scenarios to better understand how Microsoft can best address future integration needs within the Azure Integration Services platform.
No matter if you are considering migrating in the future to Azure Integration Services or staying on-premises for a couple of more years (or forever) this is a great opportunity to provide feedback to the Microsoft Integration team and positively influence the outcome of new features.
So, for customers that are using BizTalk Server or were using BizTalk Server in the past, this survey is for you! If you are a consulting company providing services to clients using BizTalk Server, this survey is also for you! The Azure Logic Apps team would love to hear from you!!! They want to enter and poke around your brain, your world and gather all the feedback regarding BizTalk Server:
What version you are using or were using?
How many applications do you have?
How many orchestrations, receive locations, and send ports do you have?
What features you are using?
If you are like me, all! depending on the client I even select others
Which connectors are being used in your BizTalk Server implementation?
Do you have any custom adapters?
What Integration Patterns are you currently using?
and many other simple questions
Don’t complain in the future about the lack of features that will suit you better. The team is interested in how they can best support customers transitioning integration workloads to Azure Integration Services (AIS)… you are not going to move to Azure? The survey does not take that long to respond to, so if you are using BizTalk Server try to respond nevertheless, by doing that you can help other customers on their journey.
For the bad mouths of this universe or for those who like to create rumors because they have nothing to say… this survey does not mean that BizTalk Server is dead! The goal is to help Microsoft prioritize upcoming investments in Azure Integration Services (AIS).
depending on the client 
