The year 2018 passed away just like few months have passed phew…! As a support engineer, we receive different cases on daily basis. Every support case is unique because the problem will be faced by different customers in different environment architecture. But some of the support cases will be interesting by the root cause of the problem and the way of troubleshooting the case.
We have already written a series of blogs about the interesting support tickets we often receive.
In a similar way, this blog post highlights 5 interesting cases we have received and solved in the past year. We are sure this consolidated blog will be useful for our customers if they come across any of them in the near future.
A customer tried to upgrade BizTalk360 to the latest version 8.9.3153.0310. The installer ran the upgrade process till the end, however, for some reason, it failed without a failure warning or exception message shown in the installer.
During the troubleshooting, the customer informed that while installing the BizTalk360 default URL has been used.
Say for example:
Later they have changed the URL from HTTP (80) to HTTPS (443). Once after changing to the new URL, they have deleted the default port (HTTP: 80) in IIS.
In the log file, we found that the installer is still trying to find the default port.
Most of the customers will not delete or remove the default port from IIS. During the upgrade process, the installer will look for the registry values for the default port information. If there is any mismatch in the stored port information and available in IIS, the installer will be forcefully stopped, which leads to unsuccessful installation.
As a best practice, we recommend before deleting the default port, the new values (Custom Port number) required to be updated in the registry to experience a seamless installation.
Web APIs are becoming increasingly vital to the organization across all sectors. We exposed our APIs specifically to facilitate the creation of their own scripts to ease the use of BizTalk Server integration space much better. To access the BizTalk360 API documentation you must contact license@biztalk360.com as we are providing this feature as an Add-on pack.
In this case, a customer can access all the features except the API documentation menu, though they have a valid license to access it. After the investigation, we have observed an error “Access is denied” in Internet Explorer browser.
Most of the customers wanted to access the BizTalk360 application in a secure way (HTTPS) based on their Organisation policy. As we progressed on our investigation, we had identified the root cause is because of deleted/removed the default port configuration in the IIS.
We suggested them to add the HTTP port into IIS and check the API. Yes, it helped after adding the HTTP and they were able to access the API documentation.
The interesting part was the fix to the problem. We are using Swagger for the API documentation. Since they removed the HTTP, Swagger kept on checking the HTTP as per mentioned in the configuration in the schemes. As a workaround, we recommended them to change the schemes upside down, it helped them to access the API documentation. Later we handled the part in the code for the permanent fix.
It took few months to solve this case because of the restricted access at a client side, we would like to appreciate the customer for their patience in this case as it took a long time to identify the root cause.
Sometimes we don’t believe our own eyes as the support ticket makes us think beyond the limit. One such interesting support case we have received is about the Analytics section. A customer added few widgets in the dashboard, but the changes were not persisted when they moved them around to different places and removed a few of the widgets. We suspect it’s a ghost activity, absolutely it’s an old joke, have a smile! 😛
As it is difficult to identify the root cause, we went for a web sharing session and found that a few widgets don’t have any data. We presumed that the issue is related to “Event Log data count” widget.
There were 4 Event log data count widgets added with different server names, out of that 2 were with data and 2 were empty.
In the generated widget, we were able to see two problems.
The Event Log widget will collect information from all the servers (if permission is provided). When we check for the permissions in all the enabled servers, we were able to see some server hadn’t had local admin permission. After providing the necessary permission, they were able to remove the event log data count widget from the dashboard.
The second widget is with custom sources, this was identified as an issue at our code and we provided the fix in the related stored procedure to resolve the issue.
Monitoring few NT services leads to an exception “no longer exist in the server” in the alert email.
We monitor the NT services by using the service name. Every time while logging off the user, the monitored services were removed from the server and when logging in to the machine or once after a reboot, a new NT service was created with the addition of some random number (at prefix for both service name and display name).
This led to the “Orphaned” status as the originally mapped service was not found by the BizTalk360 monitoring service in the actual server
Example: If the service name is CDPUserSvc_159f93a17 once after the logout and login or after a reboot, the name will be changed to CDPUserSvc_29174f
We investigated the usage of the services where those services are structured with user data like contact info, calendars, messages, and other content in Windows 10 and Windows Server 2016.
The Fix is available in our latest version, where it handles the new services created with random numbers.
An issue is that file monitoring is getting Orphaned once after configuring it with an alarm.
We started with the basic troubleshooting steps and understood that the configured File path in BizTalk Server is present in a different domain configuration than the domain of the actual BizTalk server. Technically, BizTalk360 will monitor the specific file location without any issues because BizTalk360’s monitoring service account is being used to fetch the configuration information by providing the necessary permissions
To find the exact root cause of the issue, we have developed a console application (with logs enabled) and provided it to the customer. At last, we have found that it is an issue with authentication for the service account in cross-domain architecture. We have found this as an issue at our end and fixed the same in our latest version.
This case helps me to explore more in cross-domain architecture.
For more details on this case, please refer here.
Above are 5 interesting cases of 2018 which helped me to learn and explore new areas and technically learn new concepts. Wait for another blog post series where I would like to share another 5 more interesting cases.
