Phidiax Tech Blog

Recently, I was tasked with reconfiguration of BizTalk Server Users and Groups, but without deleting the databases. The main goal was to reconfigure the User Account and Groups that the initial configuration had set. There are many reasons for this, for example:

• Re-purpose a tier from PROD to UAT, and switch User and Groups domain objects to TEST rather than PROD.
• Promote a tier, and switch User and Group domain objects to ensure specificity in security

Seems easy enough, but as we all know, this is no easy task. We may utilize traditional BizTalk configuration (un-configuration) methods through the BizTalk Configuration tool, but this will cause databases to be lost.

Below are the manual steps used to reconfigure the group configuration to utilize different User Accounts and Groups.

Warning: These steps are not supported by Microsoft. You should not perform this in Production. You should back up your servers before attempting this. This may or may not be a comprehensive list of steps for your environment and usage. Any other warning that I could make,, please assume it is listed here. Finally, most BizTalk installations are different, so the following steps may or may not be comprehensive for your build.

Assumptions

• All domain object including Service Accounts and Groups are:
• Organized in accordance with Microsoft BizTalk requirements - Windows Groups and User Accounts in BizTalk Server
• Already set up on the organizations domain

Reconfigure SSO System

Your SSO configuration may exist on the same server as the BizTalk Application, on a separate SQL server, or on a SQL Cluster. Depending on your SQL setup, your SSO reconfiguration steps will vary. 

On the SQL server node, perform the following:

1. Be sure to know the location of your SSO.bak file, and the Master Secret password
2. Open the SSO Administration tool
1. Right-Click System, Select Disable
2. Right-Click System, Select Properties
3. Under SSO Administrators and SSO Affiliate Administrators, Add the new SSO Accounts, leave the current ones, respectively
4. Right-Click System, Select Enable

You now must update the SSO Service account credential. 

On all SQL server nodes, perform the following: 

1. Navigate to Services.msc and locate Enterprise Single Sign-on
2. Right-Click, Select Properties, Select Log On, Update the Service Account
3. Restart the Service

1. Navigate to Services.msc and locate Enterprise Single Sign-on
2. Right-Click, Select Properties, Select Log On, Update the Service Account
3. Restart the Service
4. On restart it will pull SSO details from the SSO service running on the SQL node or SQL clustered service. You should see in the event log, Master Secret Server Started Successfully.

Update the BRE Accounts

1. Navigate to Services.msc and locate the Rule Engine Update Service
2. Right-Click, Select Properties, Select Log On, Update the Service Account
3. Restart the Service

Update the BAM Accounts

1. Navigate to the BizTalk Server Configuration tool
2. Select View, Select Service Accounts
3. Update the BAM Portal Accounts
4. Select Close
5. Select Apply Configuration
6. Upon Success, you can verify that IIS AppPool Settings are updated
7. Validate proper AppPool Settings on other BizTalk nodes

Update the BizTalk Group Settings

1. Using SQL Server Management Studio, connect to your Database Engine SQL instance(s) which contain BizTalk objects
2. Open the BizTalkMgmtDb, and Edit the dbo.adm_Group Table
3. Update the following columns with the respective domain account, Save
1. BizTalkAdminsGroup
2. BizTalkOperatorGroup
3. BizTalkB2BOperatorGroup
4. To verify, Open the BizTalk Administrators Console
5. Select the BizTalk Group, Right-Click, Properties
6. Verify that Fields are as expected

Update SQL Server Security

For SQL Server Analysis Services, on a SQL Server node:

1. Using SQL Server Management Studio, connect to your Analysis Services SQL instance which contains BizTalk objects
2. Expand Databases, BAMAnalysis, Roles
3. Right-Click BAM Administrator, Properties
4. Select Membership, Add the proper BizTalk Server Administrators Group

For SQL Server Database Engine, on a SQL Server node:

1. Using SQL Server Management Studio, connect to your Database Engine SQL instance(s) which contain BizTalk objects
2. Expand Databases, Security, Logins, Right-Click, New Login
3. Create the Login entity in accordance with the below configuration table for all listed Groups and Users. This should bring your new AD objects up to BizTalk requirements, similar to the original Groups and Users.
1. Be sure to implement all entries in the "SQL Login" column
2. For each SQL Login, implement:
1. "Server Roles" column
2. "User Mapping" column - Database
3. "User Mapping" column - Database Role Membership

Below is sample of utilizing the SQL Server Management Studio to create Logins.

Update BizTalk Server Applications

This final section updates the BizTalk Server Applications to the desired User and Group AD objects. 

It is important to preserve the default BizTalkServerApplication, and BizTalkServerIsolatedHost. Many applications, sdk, sample code, development code, including BizTalk ESB, make use of these default applications. Preserving them will save some heartburn down the road. You can only change the Host Windows Group, if Hosts Instances do not exist. You can only delete Host Instances if artifacts are not bound to the Host Instance. Further, you may have many new Hosts and Host Instances to deal with, which you may have artifacts deployed and bound, and would be painful to delete or re-bind. 

There are a couple options here:

Option 1: Traditional Application Update

If possible, you will need to remove Host Instances, then select Properties of the target Host, and update the Windows Group. Then re-create the Host Instances, with the new Windows User. This will manage all the manipulations to the backend and application server. However, depending on your current application deploy state, this could end up being cumbersome.

Option 2: Non-Traditional Application Update

This approach is quick, leaves the current application state in place, and manages the manipulations utilizing the backend of the BizTalk application server. This is unsupported, and adds risk. However, it gets the job done, quickly, with minimal fallout.

Update Host Windows Groups

1. Stop all Host Instances
2. Using SQL Server Management Studio, connect to your Database Engine SQL instance(s) which contain BizTalk objects
3. Open the BizTalkMgmtDb, and Edit the dbo.adm_Host Table
4. Update the following columns with the respective domain account, Save
1. NTGroupName
5. Perform this update for all Hosts, observed through the Name column. Be careful to select the proper AD Group, for example: Host Account vs Isolated Host Account

Update Host Instances Service Account(s)

1. Navigate to the BizTalk Server Admin Console
1. Select Host Instances
2. For each Host Instance, Right-Click, Select Configure, Enter new Service Account credential
1. We are assuming all Service Accounts have proper Windows Group membership

Verification

After performing this, you can verify that your Host and Host Instances are as expected:

1. Navigate to the BizTalk Server Configuration tool
1. Select View, Select Service Accounts
2. You should see that the BizTalk Runtime accounts are updated as expected
2. Navigate to the BizTalk Server Admin Console
1. Select Hosts and Host Instances to verify Group and Service account configuration
3. Navigate to the Services.msc and verify that your BizTalk Services are running as the expected Service Account

Update BizTalk Server Registry

1. Run regedit.exe
2. Navigate to node: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration
3. Select Administration, Update the key, BizTalkAdminNTGroup, with the new Windows Security

Follow-Up Steps