This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here. Why do we need this feature? For a BizTalk environment to work properly, BizTalk Server depends on multiple components. One of such components are the Windows NT … Continue reading Why did we build Windows NT Service Monitoring
This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here
Why do we need this feature?
For a BizTalk environment to work properly, BizTalk Server depends on multiple components. One of such components are the Windows NT Services, which run on the BizTalk and SQL servers. There are many Windows NT Services which are of vital importance for the correct working and health of BizTalk Server. Let’s have a look at a couple of these services and see what happens when they are not running properly.
- BizTalk Host Instances – these are the services which are taking care of receiving and transmitting messages, processing orchestrations and moving Tracking data between the MessageBox and the Tracking database. Obviously, without the Host Instances running, no processing will take place.
Note: Although the Host Instances are Windows services, they can be monitored as Windows services. We advise, however, to handle monitoring them as Host Instances (under Monitoring / Manage Mapping / BizTalk Environment)
- SQL Server Agent – This is a component of SQL Server, which takes care of executing all kind of maintenance jobs of BizTalk Server. For example, making backups of the BizTalk databases, cleaning up MessageBox and Tracking data is all done by the SQL Server Agent. So, when SQL Server Agent, which also is a Windows Service, the jobs won’t run, jeopardizing the health of your BizTalk environment
- Enterprise Single Sign-On Service (ESSO) – BizTalk uses ESSO for storage and retrieval of, amongst others, passwords of endpoints. Although these passwords are being cached in the Host Instances, when the ESSO service is not running, you will end up with BizTalk not being able to receive and transmit messages
- Internet Information Services (IIS) – You might have published BizTalk Schemas or Orchestrations as WCF services. In these cases, the IIS on the BizTalk server(s) will be used to host these WCF services. So, when IIS is not running, the WCF services cannot be accessed and no messages can be received
- Third Party Application Services – Maybe you have Windows Services of 3rd party software which is used in your integrations. These services might be used for receiving or transmitting messages from/to BizTalk. We have seen scenarios where an ERP product uses Windows Services. Without the Windows Services of that software running, the integration flows with that software would not work
We mentioned many realistic cases, which makes it clear how important these Windows Services are and what might happen when the services don’t run properly. With that, it is identically clear that the well-being of these services should be monitored frequently.
What are the current challenges?
That being said, we now know that we have to incorporate monitoring a number of Windows Services in our daily tasks. These services will probably reside on several servers, which makes it rather time-consuming to constantly be aware of the current status of the Windows Services. Probably, when monitoring manually, you will end up with checking the state only once or twice per day and maybe even forgetting it.
Chances are, that on a bad day, you will run into problems with BizTalk, which are caused by not properly running Windows Services.
Also, in case you are off for a few days and you have instructed your colleagues to check the state of the Windows Services, it is not unlikely that they will forget your request, as they must fit it in their own busy daily schedule, again bringing your BizTalk environment at risk.
It could also be that your Windows Services are being monitored by a general monitoring solution like SCOM. Although that should work nicely, it is not efficient as can be, as this makes it harder to keep the overview, because you will have to check multiple consoles, to be aware of the overall health of BizTalk Server.
Lastly, you might use custom developed command line or PowerShell scripts to monitor the Windows Services. Although that too could work nicely, but developing and maintaining such scripts can be time-consuming and error prone.
How BizTalk360 solves this problem?
Instead of manually monitoring the services, use 3rd party software, or develop custom scripts, with BizTalk360 you have a consolidated user interface, which makes monitoring these Windows Services, and all other artifacts which are relevant for proper BizTalk Server monitoring, easy.
Related to Windows Service monitoring, BizTalk360 has the following features:
- monitoring BizTalk servers – you can setup monitoring of Windows Services for all the BizTalk servers which are part of the BizTalk Group for which you have a BizTalk360 license
- monitoring SQL servers – you can also setup monitoring for multiple SQL servers. BizTalk360 allows you to configure 2 SQL servers
- positive/negative monitoring – in most cases, you’ll want to monitor whether your Windows Services are in the Started state. This is being called Positive monitoring. But there might be cases where you explicitly want a certain Windows Service to be in the Stopped state; for example, you don’t want certain Windows Services to take valuable resources (CPU/Memory). This is called Negative Monitoring. BizTalk360 supports both Positive and Negative Monitoring of Windows Services
- receive notifications – once a Windows Service is not in the expected state, you will receive a notification of that fact. The default notification channel is email, but you can also receive notifications in Slack, ServiceNow, HP Operations Manager, Microsoft Teams and EventLog
- auto-healing – besides just monitoring and notifying you of any Windows Service being in the wrong state, you can also have BizTalk360 to try to bring the Windows Service back to the expected state. This is the concept of auto-healing
The Windows Service monitoring feature of BizTalk360, can take away a pain point in your day to day operations as a BizTalk administrator. After setting it up, you don’t have to perform manual checks of your Windows Services anymore, as BizTalk360 will take care of that. The product not just monitors and notifies you of any Windows Services being in the unexpected state, it can also try to recover the Windows Service, thereby reducing the downtime of the Windows Service and improving the overall availability of your BizTalk environment.
Do you want to read more on the ins and outs of Windows Service monitoring with BizTalk360, feel free to read this article:
Get started with a Free Trial today!
Why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness the benefits of Windows Service monitoring on your own BizTalk Environments. Get started with the free 30 days trial