How does BizTalk360 deal with the Host Instance Pending State

Introduction

Throughout our 10-year journey, we have never failed to satisfy our customers. We’ve always believed that gathering feedback is the most effective way to improve a product. Furthermore, our existing customers stated that we provide excellent customer service. If you are new to BizTalk360 and our services, follow the link to know more!

stuck in Stop pending state

BizTalk Server Host Instance stuck in “Stop pending state”

If you are a BizTalk Server user, you might have probably seen something like this! When you try to restart the host instance, your host instance might get stuck into the “Stop pending state” for an extended period. During a client relationship sync up with one of our customers, we observed them encountering this issue and how this has been encountered by logging in to the admin console and looking for various methods to solve the issue. . To assist our customers, the BizTalk360 team felt that this issue should be automated to some extent.

BizTalk host instances

The root cause of the problem and the solution

We are still not exactly sure why this happens, but we can take a few of the steps to resolve the issue. The root cause of the problem can be if your machine is not updated with the most recent Cumulative Update (CU), and if there is any issue in deployment.

The solution to this issue could be to keep the CUs updated and in-synced in all your BizTalk servers. If the problem is not in your production environment, you can kill the process in your Task Manager. However, the Task Manager might not be approachable if the issue is in your production environment. Another step would be, to log in to your BizTalk Server Administration Console or Services window and start the process.

Another precaution that you can think of, if you have multiple Host Instances, then know what the process id of the host instance is and terminate the correct one. You can accomplish this following the steps in this post:

Let us see how BizTalk360 deals with the issue. First and foremost, to be able to use BizTalk360, users must have a certain level of access. Let us see how we can achieve them.

User permission is required for access

Note: Regarding host instances, it is common for all tiers in BizTalk360. Click here to get a quote for each tier.

By default, super users will have all access to the host instances and set up monitoring of host instances. However, if you’re not a super user, you must ensure to have access to the following:

  • Manage Infrastructure Setting
  • Monitoring of Host Instances

Once all feature permissions are set, you can start/stop/enable/disable your host instances from within BizTalk360. In this way, your admin people or support people do not require any admin access to use BizTalk360. So, if you wish to evaluate our product, please do so by signing up for our free trial.

How does BizTalk360 handle this problem?

By using BizTalk360, users can operate and monitor their host instances using BizTalk360. The first thing users must do to use monitoring, is to create alarms. Navigate through the steps as follows: Select environment -> Infrastructure settings-> Host instances. Here, users can easily turn on/off/enable/disable/restart their host instances.

biztalk host instance stop pending

As a result, the status of each host instance will be visible in BizTalk360. Like in the above screenshot you can see the host instance “BizTalkServerApplication” is in the Running state, same as in the standard admin console.

Stop pending

If your host instance is stuck in the Stop pending state, in BizTalk360, the status will be displayed as Unknown.

Monitor your Host Instances

Once the status of the host instances has been set up, the next step is to navigate to the Monitoring section of BizTalk360: Select environment -> Monitoring -> Manage Mapping -> BizTalk Environment-> Host Instances

Monitor your Host Instances

Configuring monitoring for host instances in BizTalk360 is simple. It just takes 5 minutes of your time. BizTalk360 allows users to select particular host instances and set the required state (“Expected”) state. Let’s consider an example, if your host instance is in the “Unknown” state then you can set up your host instances according to your business requirements.

With respect to Host instances, BizTalk360 can monitor four states:

  • Started
  • Stopped
  • Disabled
  • At least one active

monitor the host instances

You will be notified whenever the expected state differs from the current state of the host instance. Your next question is, how will you be notified?

Let’s take a look at the inbuilt notification channels in BizTalk360.

Notification channels in BizTalk360

Currently, BizTalk360 offers custom notification channels for the following:

To know more, follow the steps to configure custom notification channels in BizTalk360. Clustered Host Instances Monitoring

To achieve high availability for adapters, that cannot have multiple host instances running at one point in time, BizTalk allows you to cluster hosts using Windows Failover Clustering. This will result in only one host running for the clustered host and in case of any failure, it will failover by running the host instance in a different server.

BizTalk360 has the capability of monitoring Clustered host instances. Setting up monitoring for clustered instances is the same as all for other artifacts in the environment.

Autocorrect functionality

For a healthy BizTalk environment, there are lots of things that should all work to have a healthy environment. With the help of the “autocorrect” feature any state-based artifact can be automatically brought to the desired state such as enabled, disabled, started, and stopped. This helps in providing a higher service availability.

The following artifacts can be configured with AutoCorrect:

  • Receive locations
  • Orchestrations
  • Send Ports
  • Send Port Groups
  • Host Instances
  • NT Services
  • Azure logic apps
  • SQL Jobs

To know more, and to set up autocorrect in your environment, follow the link.

Alarm Reset Capability

The AutoCorrect configuration will get reset in two scenarios. The AutoCorrect will get reset, once the autocorrect is successful:

  1. The AutoCorrect “Max Retry” counter will be reset after the successful auto-healing of the mapped artifacts
  2. Associated Auto Correct mappings will be reset after the alarm reset.

Now, with AutoCorrect parameters “Max Retry” and “attempt”, an additional parameter has been added, which is “Reset Interval”. The user can configure the time interval to do automatic Auto Reset. This configuration will reduce the manual intervention whenever the “Max Retry” counter reaches its limit.

Conclusion

Hopefully, we have made it clear how you can use BizTalk360 to efficiently monitor the various states of BizTalk Server host instances. We are always happy to discuss any challenges you may be facing, so please feel free to reach out to us and have an obligation-free conversation. You can request a demo or take a free trial.