Challenges in BizTalk360 Licensing after Environment Changes

In BizTalk360 support, we often face a lot of interesting issues and we thought we would bring out a series to discuss the different cases that come our way and how we dealt with them. A previous blog by my colleague spoke on the Culture variant issue, a very unique case. Recently we came across a very interesting support case. The customer was not able to view BizTalk applications due to the reason that BizTalk admin group name present in BizTalk360 License information did not match with the customer’s domain BizTalk Administrator’s group.

What happens during the activation of License in BizTalk360?

During the activation of an environment in BizTalk360, BizTalk360 License will fetch the information about BizTalk Admin Group, BizTalk server Management SQL Instance, Management Database name and BizTalk version information from customer’s environment.  These details are stored into BizTalk360 license database and are embedded with the License after activation. If anything has changed at the BizTalk environment level, it will reflect in BizTalk360 UI or in performance. Say for example: BizTalk servers were removed/added, changing BizTalk Admin Group name, BizTalk Server Management SQL Instance name, Management Database name, upgrading BizTalk server in one machine in multi-server environment., these changes will not be reflected with the BizTalk360 License information that is stored in the License database and hence it will display an exception message in BizTalk360 UI.

Screenshot of License history from BizTalk360 License application manager

It is always recommended that before making any environment related changes, you need to perform the license deactivation or else to contact our BizTalk360 support team for updating the changes into the License information and also for any guidance required. Say for example: If the customer was not sure about moving the BizTalk360 database from one server to another server as a part of migration, we request our customers to contact our support team for the guidance.

Prologue to this story

From the BizTalk360 version 8.0 onwards, you will not be allowed to perform any action in BizTalk360 UI without activating the License. The problem faced by the customer was that the name of the BizTalk Administrator group didn’t match with the information in the license.

• BizTalk Environment Domain: BT360\BizTalk360-SG-Kovai-Biztalk Administrators-Dev,
• License Key Domain: BT360\BizTalk360-SG-?Kovai-Biztalk Administrators-Dev

BizTalk Administrators group has the least privileges necessary to perform most administrative tasks. Members of that group can perform administrative tasks through the BizTalk Administration console or directly using the WMI provider and can deploy solutions, manage applications, and resolve message processing issues. Users will be added into the BizTalk Administrator’s group so that they can perform these administrative tasks. Customer can change the name of the BizTalk Administrators group from BT360\BizTalk360-SG-Kovai-Biztalk Administrators-Dev to BT360\BizTalk360-SG-?Kovai-Biztalk Administrators-Dev which may resolve their problem. But, if they make any changes in BizTalk Administrators group, it may affect the BizTalk server process via the users who are added to that group to perform any operations.

Screenshot of the exception from BizTalk360 UI

The exception what the customer exactly faced

We noticed that there was a question mark added in between the domain name and the BizTalk Administrator’s group (Domain: BT360\BizTalk360-SG-? -Biztalk Administrators-Dev). The customer conveyed that they worked with the domain admin team and removed the question mark symbol. But we are very sure windows server/operating system doesn’t allow to create a name with ‘?’ question mark while creating the group or a user. We wanted to investigate within customer environment and so we requested a screen sharing session to see what’s happening and from where the name was taken from. Before going to any customer call, we would prepare a list of questions related to the necessary information we wanted from the customer end and where all we want to check. Also, we will try to reproduce the same at our end.

How did we back track the case?

During the testing, we tried to replicate the same. So we just copied the same BizTalk Administrator’s group ‘BT360\BizTalk360-SG- Kovai-Biztalk Administrators-Dev’ name from the exception and created a group in our test machine and we added to BizTalk360. Once after adding as a NT Group in BizTalk360 we found a strange thing it got created with a special character ‘?’ question mark BT360\BizTalk360-SG-?Kovai-Biztalk Administrators-Dev. Then we checked by using PowerShell command, found a special character added which was like a mobile phone character.

Screenshot of the BizTalk Admin group by using PowerShell

We asked the customer to change the Group name manually in all places in the database and in Windows Groups as well. But, it still showed the same exception even after the changes made by the customer. We requested for the desktop sharing session and checked all the places where the fault might be. But, we did not get any clue. The idea was to verify the group name by editing and checking each and every individual character in the name by moving the cursor (that’s how we found special character during the testing). But we were not able to find the special character in the database and in Windows Groups. Finally, in the properties of BizTalk Groups at BizTalk server we checked the BizTalk Administrator Group by each individual character by moving the cursor and we found the special character was still persisting. We asked the customer to remove the special character. They contacted their admin to change/modify the name, after which the exception was gone. BizTalk360 started working and the customer was able to view the applications without any problem.

What needs to be avoided?

We should try to avoid copy/paste while creating the group/user names most of the time instead type the name manually. Sometimes, while copying from a clipboard and pasting it in a password field may show some mismatch error due to the addition of special characters. This was a good experience as a support engineer and had a different experience to learn as well.