If everything is a peaceful and relaxing environment, then something is wrong
Introduction to BizTalk360
BizTalk360 has been around for more than a decade in the field of BizTalk Server Administration and Monitoring. This blog shows users how they can streamline their day-to-day monitoring. Besides providing full coverage of your BizTalk Server Monitoring, BizTalk360 also fulfils many other functions. Let us see this in detail.
BizTalk Server Monitoring tools
In this section, you can get a deeper understanding of what you can monitor with BizTalk360.
Application and artifacts monitoring
Host Instance Monitoring
Host Throttling
EDI (Electronic Data Interchange) Agreement Monitoring
Database size
Event Log Monitoring
Event Log Data Monitoring
File Location Monitoring
Queue Monitoring
BizTalk & SQL Server Monitoring
SQL Job Monitoring
Application and artifacts monitoring
BizTalk360 automatically shows the applications that are deployed in the BizTalk Server environment at hand. All state-based applications artifacts can be monitored, including:
Orchestrations
Receive locations
Send ports
Send port groups
Users can set the expected state of those artifacts. When there is a mismatch between the actual and the expected state, BizTalk360 sends you an email, or a notification to any of the systems such as:
Microsoft Teams
Slack
ServiceNow
PowerShell
Webhook
Twilio
PagerDuty
Host Instance Monitoring
In BizTalk, messages can only be processed when the host instance is running. BizTalk360 allows users to manage and monitor BizTalk Host Instances. Additionally, BizTalk360 can also monitor clustered host instances. To learn more about clustered host instances, follow the link.
Host Throttling
Microsoft does not provide any tool to understand whether your BizTalk environment is working efficiently or under throttling conditions. It is typical for administrators to use Windows Perfmon to add all the performance counters associated with throttling and then analyse throttling conditions. This requires extensive knowledge of how the BizTalk Server works, various throttling counters & conditions, whether it is running at an optimum level, etc.
Setting up Host Throttling monitoring in BizTalk360 is just a 5-minute process, where users can monitor the following:
Rate throttling
Process memory
System memory
Database size
Database session
Thread count
User override
EDI agreement monitoring
Any business trading partners commonly exchange data electronically through EDI. For successful transactions, it is important to maintain the agreement state. Via BizTalk360, users can monitor the states of EDI Agreements.
Database size
For a healthy BizTalk environment, it is essential to monitor the growth of the BizTalk databases. With the Database size monitoring feature, users can monitor the database and log the file size of the BizTalk and BizTalk360 databases. Follow the link to learn more!
Event log monitoring
What happens when your Windows server gets booted without your knowledge? It may be a good idea for users to check if everything is still in good shape. Without a monitoring product, it requires manual intervention to be aware of the reboot. Wouldn’t it be more convenient if there was a tool to monitor your Event log entries?
BizTalk360 comes with a feature named Event log monitoring that enables users to be alerted about specific events being written to event logs in your BizTalk or SQL servers.
There is also another type of monitoring, which is Event Log Data Monitoring where users can configure a specific value based on conditions. Follow the link to know more.
Before moving on to the next topic, it is helpful to know the difference between Event Log and Event Log Data Monitoring. Let us say you have multiple BizTalk servers and want to correlate and monitor event IDs. In such a scenario, Event Log Data Monitoring will be helpful whereas, in Event Log Monitoring, you need to create two event logs to monitor different event IDs.
Event Log Data Monitoring
BizTalk administrators look first for the Event Logs when something unexpected happens since the Event Viewer contains the exact error information. Logging in each time to the BizTalk and SQL servers to check the event logs would be cumbersome. When BizTalk360 event log data monitoring is enabled, it is easy to check for event logs. You can get the log message count as well as event log message information in the alert email.
Wouldn’t it be helpful if we see all this information in one place? Yes, BizTalk360 provides you with this option where data can be filtered with more options and conditions. An additional filtering option is that the event logs can be filtered based on multiple event ids.
File Location monitoring
BizTalk360 lists all the locations configured in the BizTalk artifacts (Send Ports and Receive Locations) for the Transport types (File, FTP, SFTP) respectively, which helps users to monitor all the File Locations mapped with Receive Locations/Send Ports.
Queue Monitoring
BizTalk360 monitors the health of the IBMMQ and MSMQ along with other parameters, including Queue Size, Active Messages, Dead Letter messages, and Journal Messages. Monitor your local and remote queues and set threshold conditions to get notified of any violations.
SQL Jobs Monitoring
BizTalk Server heavily relies on SQL Server databases. The health of these databases is crucial for the health of the BizTalk Server. Out of the box, BizTalk Server comes with several SQL Server jobs that perform all kinds of maintenance tasks, thereby contributing to the health of those databases. BizTalk360 allows you to monitor those SQL Jobs.
BizTalk & SQL Server monitoring
This feature helps the users to monitor the availability of
Disk space
CPU and Memory usage
Event Log entries
Windows NT Services
Azure Serverless Monitoring
To support hybrid integrations, BizTalk360 becomes aligned by supporting Azure Serverless technologies. Hereby, the product prevents you from switching between BizTalk360 and the Azure portal. Let’s see what Azure Services can be monitored by BizTalk360:
Azure Logic Apps
Azure API (Application Programming Interface) Apps
Azure Logic Apps
With BizTalk360, Logic Apps can be monitored and ensure they are running correctly. You will gain deeper insight into when the expected number of runs is met and the number of failures that occur.
Azure API apps
Users can monitor the health of their API apps and the configured endpoints. Monitoring API apps includes endpoints and provides a seamless monitoring experience.
Azure Service Bus Queue monitoring
Azure Service Bus allows applications and services to communicate with other applications in the cloud, on-premises, or both and ensures message exchange occurs smoothly. With BizTalk360, configure alarms for various parameters like
Queue Size
Status
Messages
Active Messages
Scheduled Messages
Transfer Messages
Dead letter Messages
Auto Correct
Administrators can set up monitoring on “State-based” artifacts and let the monitoring service automatically heal the artifact at any time. For example, administrators can monitor the receive locations of applications and set up auto correct functionality for the Expected state of the artifact. Whenever the receive location goes down or gets disabled, there will be a mismatch and the auto correct will try to bring the artifact back to the Expected state within the next monitoring service cycle. The feature applies to the following artifacts:
Send ports
Send port groups
Receive locations
Orchestrations
Host Instances
NT Services
SQL jobs
Logic Apps
EDI Agreements
Pricing Structure of BizTalk360
There are one-year and three-year subscription options available for BizTalk360. Depending on the number of BizTalk servers in the BizTalk group, the BizTalk edition (Standard or Enterprise), and the BizTalk360 feature-based license tier (Silver, Gold, Platinum), users will pay a different license fee. A license comes with unlimited users and unlimited customer support, also users can customize their license according to business requirements. A free trial is also available.
If everything is a peaceful and relaxing environment, then something is wrong
The BizTalk360 team is always there for customers when they need Product support. They frequently reach out to each customer, to update them on the latest release, and to make sure they are using the product to the fullest.
Ask for Support
When setting up BizTalk360 monitoring, you are not alone. Whenever you have a problem, the BizTalk360 technical support team is there to help. They are knowledgeable about the product and can share their experiences with other customers as well. Directly ask them to review your setup before it fails, and you find out it was set up incorrectly.
Documentation Help
It is crucial to document exactly how users have set up their business requirements and assist team members in the future. In BizTalk360, users can easily locate any information they need through the documentation portal.
Demo & Free Trial
Currently the product contains over 80 features, but Product Consultant team of BizTalk360 provides a fully customized product demo based on business needs, so please do contact the support team without any obligation. Users can either request a demo or take a free trial.
Introduction
BizTalk Server Monitoring tools
Azure Serverless Monitoring
Pricing Structure of BizTalk360
If everything is a peaceful and relaxing environment, then something is wrong
After twelve years of working as a BizTalk Server consultant in The Netherlands and working with BizTalk360 at his customers, Lex Hegt joined Kovai.co/BizTalk360 in 2016. We interviewed Lex about the life cycle of the BizTalk Server and why BizTalk360 is needed more than ever.
Do you think Microsoft BizTalk Server 2020 is a game-changer?
Yeah, especially with Microsoft’s announcement about extending support for BizTalk Server to 2030, you can consider BizTalk Server 2020 as a game-changer. It gives customers the confidence that until that time, they don’t need to be worried about receiving support when that would be required. Also, when customers migrate from an older version of BizTalk Server, like 2013 (R2), the new cloud-connectivity capabilities open a wealth of new possibilities and integration scenarios.
What do you think about BizTalk Server 2020 and Microsoft’s end-of-support announcement?
Microsoft recommends organizations move to the cloud for their integration platform. Their announcement could mean that we won’t see the release of a newer version of BizTalk Server anymore. However, at least this gives existing (and even new) customers confidence that until the end of this decade, they won’t run unsupported with their BizTalk Server environments.
Please share some thoughts on the BizTalk Server end of life.
Although the future of integration is in the cloud, it still happens that organizations choose BizTalk Server as their integration platform. Reasons for selecting an on-premises platform include organization or industry strategy, or most integrations are happening on-premises. However, Azure Serverless is very powerful and winning in popularity. So, we expect that BizTalk Server will still be around for several years but will slowly fade away. Given the limited offerings in the market, it makes even more sense to use a powerful product like BizTalk360 to run your BizTalk environments more efficiently.
Do you think Azure can be a replacement for BizTalk Server?
Both platforms have a lot of similarities and capabilities, but each platform also has its strengths and weaknesses. In the end, we choose a platform based on the requirements. We don’t expect many new developments in BizTalk Server, while Azure Serverless gets stronger and richer every single release cycle. Over time, Azure Serverless also supports features not available in BizTalk Server, making Azure Serverless the better choice as an integration platform. Although there still is a place for BizTalk Server, it will fade to the background.
What is the ultimate advantage of using BizTalk360 for a BizTalk Server user?
BizTalk360 has over 80 features focused on streamlining your BizTalk Server operations, administration, and monitoring. Some of them are technically focused, and some of them are business-focused. Out-of-the-box BizTalk server comes with BizTalk Admin Console for everything, from development, deployment, support, operations, configuration changes, diagnosis, etc. It is a potent tool in some aspects, but it is very weak in certain aspects, especially around user security access, governance, auditing of who did what in the environment, etc. Our goal here at BizTalk360 is to provide one solid tool to solve all the operational and monitoring pain points that arise once your BizTalk applications get to production.
App registrations is a mechanism in Azure AD allowing to work with an application and its permissions. It’s an object in Azure AD that represents the application, its redirect URI (where to redirect users after they have signed in), its logout URL (where to redirect users after they’ve signed out), API access and custom application roles for managing permissions to users and apps.
As a matter of fact, through an app registration, you can restrict access to an application to only a specific group of users, if needed. An example of this is a solution I built a few years ago where we had two separate apps: a customer-facing app and a management app. Each had its app registration. I’ve restricted access to only a select group of people responsible for managing the system for the management app.
Associated with an app registration is a service principal, which is the identity of that application. As you undoubtedly know, a service principal has credentials. However, you may not know that these credentials have an expiry date (end-date). If you’re not aware of that and don’t monitor and manage that, you may end up with applications and services that stop working.
The Microsoft identity platform handles identity and access management (IAM) only for registered applications. Registering an application creates trust between the application and the Microsoft identity platform.
The trust is unidirectional which means that the registered application trusts the Microsoft identity platform, but not the other way around.
In Azure AD, applications can be represented in two ways:
Application objects – Application objects define the application for Azure AD and can be viewed as the definition of the application. This enables the service to understand how to issue tokens to the application based on its settings.
Service principals – The instance of the application in the user’s directory that controls connections to Azure AD is known as a service principal.
Monitoring
Serverless360 is an out-of-the-shelf platform to keep track of the expiration of client secrets for specific app registrations and delivering notifications prior to the expiration date, prompting you to renew it.
Navigate to the Monitoring section of the resource to specify the number of days before which the expiry alert must be received, that’s pretty much the user has to configure and the rest of the work the platform will take care for you.
Can you achieve the same from the Azure portal?
In this section, we’ll see how we can define an Azure Automation runbook that we can run periodically to detect and get a list of those credentials that are either expired or about to expire.
Setting up the automation runbook
Creating an Azure Automation runbook can be done through the Azure portal or a CLI. We’ll show the portal way here.
We first start by creating an Automation account. In the Azure portal, look for “Automation accounts”, then create a new instance:
Once the account is created, we need to make a runbook (Use an Automation account to do many tasks where each runbook will handle a given task).
Go to the “Runbooks” section, then click “Create a runbook” and enter the requested information
You’re then presented with a screen to enter the code for that runbook. Our code will be in PowerShell. We’ll get to the complete source code in the next section.
For now, I’ve displayed some sample codes:
You can notice, in line 3, that we import the “AzureAD” PowerShell module to interact with Azure AD. We use it at line 13 to get the list of all app registrations.
You can notice that, too, between lines 6 and 9, we are authenticating to Azure AD before getting the list of app registrations (again, at line 13).
From the toolbar (above the text editor), you can save the runbook, test it, publish it (you need to do that before you can use it in production), and revert to the previous version (in case the new version doesn’t work as expected).
We need first to install it since we’re importing a module (here, “AzureAD” at line 3).
For that matter, at the Automation account level, we click on “Modules”, and we look for “AzureAD”:
Since that module isn’t installed, we need to install it from the gallery by clicking on “Add a module”. We’ll pick 5.1 as the runtime version:
The code
The PowerShell code to be added to the runbook is listed?here. Replace the previous code with this one.
The code is pretty easy to understand. One thing worth mentioning is the $daysToExpire variable that you’ll have to set to an appropriate value for your scenario. It’s intended to detect the service principals whose credentials are about to expire in the x coming days.
Configuring the permissions for the runbook
At this point, if you execute the runbook, you’ll notice that it might not work. That’s because the identity under which the runbook runs doesn’t have permissions to interact with Azure AD.
An Azure Automation account has an associated identity. Find it in the “Connection” section under “Shared resources” in the Azure portal.
I’ll choose the “AzureRunAsConnection”, which is of type “Service principal”, and give it the appropriate
To find that service principal in Azure AD, I need to search for the name of the Automation account in the list of “All applications” under “App registrations”: Since we want to list app registrations from the Azure AD, we need to assign the directory role “Directory readers” to the service principal associated with our Automation account (the one that will execute the runbook) following the least privileges principle.
So, we go to “Roles and administrators” in our Azure AD tenant and select “Directory readers”: Then, we add an assignment to our service principal: And we’re done.
The post Azure AD application registration monitoring: All you need to know appeared first on Steef-Jan Wiggers Blog.
One error never comes alone! Following the error reported in my last blog post while working last week with one of my clients, I was able to catch an error that I never saw during these long years working with BizTalk Server while trying to build a BizTalk Server Visual Studio solution in this specific case a custom pipeline component:
Couldn’t process file XMLAttributesStripper.resx due to its being in the Internet or Restricted zone or having the mark of the web on the file. Remove the mark of the web if you want to process these files.??????????????????
Indeed I download that resource from the Internet, from my GitHub page, like I do thousands of times for many clients and projects!
Cause
This issue happens due to the fact that you downloaded from the web these files/resources from a machine with security restrictions configured. So, when Visual Studio attempts to build the project, this error occurs because The .NET Framework resource compiler honors this marker and refuses to compile those resource files for security reasons.
The underlying cause is that the respective resource file has the so-called mark of the web applied to it. This is a marker that browsers place on downloaded files so that other applications can make informed decisions on whether to trust that file or not.
Solution
To fix this issue, the solution is quite simple. Nevertheless, there are many ways to solve or avoid this issue.
Solution 1: Fix the issue
To solve this issue, we need to remove the mark of the web, to do that, we need to:
Right-click on the file in windows explorer and select Properties.
On the General tab, at the bottom under Security, there is a check box to remove mark of the web.
Unselect the Unblock check box and click OK.
Note: This needs to be done with Visual Studio closed.
Solution 2: Fix the issue with PowerShell script
We can also do the same functionality as Solution 1 using the following PowerShell script:
On the folder for the project, run the following script
dir -Path . -Recurse | Unblock-File
or
Get-ChildItem -Path . -Recurse | Unblock-File
Solution 3: Fix the issue from Visual Studio
Didn’t try this approach, but apparently, we can also fix this issue directly from Visual Studio by:
Select the menu option Tools > Options
From the Options windows, select the option Trust Settings under Environment and add the project path as a trusted path.
Last week I was adding new processes to an existing and old project for a client, a project that I started a few years ago, and I was caught by surprise with the following error while trying to generate a new SAP schema from Visual Studio:
Error occurred while browsing the LOB system. Adapter Message: Could not load file or assembly ‘Microsoft.Adapters.SAP.SAPGInvoker.dll’ or one of its dependencies. The specified module could not be found.
At first sight, the cause for the error is simple, and I will explain above the main causes, but in my case, the problem was that I had all the pre-requirements for the WCF-SAP adapter to work, and again that was an existing project where I had already generated several SAP Schemas.
Cause
Normally the main reason for this error is that the pre-requirements to run the WCF-SAP adapter are not installed in the environment. Even if you see the WCF-SAP adapter present and configured in the BizTalk Server Administration console, it doesn’t mean that it is ready to work. This adapter requires you to install the following SAP resources to run the adapter in the BizTalk Server box:
NCo3018_Net40_x64.msi
NCo3018_Net40_x86.msi
You can download these resources from the SAP Service Marketplace.
It is required (mandatory) to install the x86 version of the SAP Connector for Microsoft .NET. However, if you want to run the adapter under a 64-bit Host Instance, you need to install both the x86 and x64 versions of the SAP Connector for Microsoft .NET (recommended).
But once again, I knew that I had all these resources installed, and I doubled check that they were installed.
In my case, for some unknown reason, some of these DLLs got corrupted, and for that reason, I was getting this error.
Solution
To fix this issue, the solution is quite simple:
Reinstall the x86 and x64 versions of the SAP Connector for Microsoft .NET.
NCo3018_Net40_x64.msi
NCo3018_Net40_x86.msi
When asked, repair the installation of the components.
After that, I was once again able to generate SAP Schemas from my BizTalk Server Visual Studio project.
