BizTalk Server

Deploy BizTalk Server 2004 Complete - Stand-Alone Server

Michael J. Hamilton, Sr. — Fri, 09 Nov 2007 20:32:35 GMT

BizTalk Server 2004 Setup/Architecture – Stand-Alone Instance(s)

To simplify this documentation, the BTS server is BTSSERVER and we will use SQL Server on a remote SQL Server called SQLSERVER.

Service Account Setup

Perform the following service account setup on both of these servers, and be sure the noted pre-requisite components are all in place:

Login as Administrator, or an account that is a member of the Administrator’s Group on the machine.
Create a user account that will be used to execute the BizTalk Server and SSO service on that machine (we’ll call this BtsService to simplify this documentation).
Do not make this account a member of any groups.
- If this machine is a member of a domain, and the Group Policy does not allow us to add this account to the run as a part of the OS policy, then it will be necessary to make this local service account a member of the local machine’s Administrator’s Group – NOTE: This is not a best practice, but is acceptable for development work.
Run the Group Policy Editor (StartàRunà”gpedit.msc”).
Expand Computer ConfigurationàWindows SettingsàSecurity SettingsàLocal PoliciesàUser Rights Assignment
Under Act as part of the operating system, add our new service account. (NOTE: Some domain configurations will not allow this, so you can only make the service account a member of the Administrator’s Group on the current machine. This is acceptable for development, but should not be done for test or production.)
Be sure the following is installed on the workstation at this point:
- Microsoft .Net Framework
- MSXML 4.0
- SQLXML 3.0 SP2 or later.
- SOAP SDK 2.0 (optional, but recommended)
- MS OWC (Office Web Components) 10
- MDAC 2.8 (MS Data Access Components)
- If workstations are XP, check KB Article 837119 to see if this update has been applied, and check to see if KB 329433 is applicable / applied.

Be sure the following is installed on the server at this point:

- (This must be Windows 2003 Server)
- SQL Server 2000 Enterprise Edition
- SQL Server 2000 Service Pack 3a
- SQL Server 2000 Analysis Services
- SQL Server 2000 Analysis Services Service Pack 3a
- Internet Information Services 6.0 (NOTE: By default IIS 6.0 configuration does not allow ISAPI extensions. You must explicitly configure this before using BizTalk Server HTTP receive handlers.)
- ASP.Net
- MSXML 4.0
- SQLXML 3.0 SP2 or later.
- SOAP SDK 2.0 (optional, but recommended)
- MS OWC (Office Windows Components) 10
- NOTE: KB Article 831950 deals with a transaction log / backup issue and should be applied to the server after SQL Server is configured.
- SharePoint Services 2.0

For the workstations, it is noted that Visual Studio 2003 is already installed. For the BizTalk server, VS 2003 w/C# should be installed to facilitate deployment in the development environment. (NOTE: IIS 6.0 must be installed before installing VS 2003). This is NOT a requisite, but will certainly make deploying your orchestrations easier for development purposes. For test / production a better practice would be to create batch files that can deploy an orchestration – much like you find in some of the online samples that are installed with BTS 04. This approach will make it easier for your development team to quickly role out orchestrations / changes to orchestrations, and will be simple enough for your support operations personnel to deploy.

Installation of Analysis Services

Ensure that a Typical Installation of SQL Server AS is performed (AS is found in the OLAP folder on the SQL Server installation CD).
Install Service Pack 3a for Analysis Services (SP3 for OLAP is found under the ...OLAP\X86\SETUP folder under the SP3).

Network DTC Configuration

While on the BTSSERVER Server, select Start MenuàAll ProgramsàAdministrative ToolsàComponent Services. This opens the Microsoft Management Console (MMC) for Component Services
Expand Component ServicesàComputers and select My Computer (NOTE: This snap-in does not always expand the tree option just by clicking the “+” sign next to the option – you may have to select the option on the left to expand it).
Right-Click on My Computer and select Properties
Click the MSDTC tab
Click the Security Configuration button.
Be sure that Network DTC Access, Network Administration, Network Transactions, and Network Clients is checked.
Ensure that XA Transactions is checked.

NOTE: If MSDTC was already configured as noted above, restarting the machine is not necessary. Otherwise, restart the machine at this time.

SharePoint Services

Install SharePoint Services making sure to install on a Server Farm and not a typical installation.

Create a new Application Pool.
Because we are configuring for BTS BAS, call it BASPool, for lack of a better imagination.
Select Configurable option under Select a Security Account for This Application Pool.
Provide the username / password to use for this configuration (NOTE: you can use our BizTalk service account (BtsService) or you may want to create a separate service account for SharePoint).
Restart IIS before proceeding (it’s quickest to drop to a CMD prompt and type IISRESTART), then click OK.
Next, Set Configuration Database Server. Provide the SQLSERVER as the SQL Server.
Provide a name (such as BASSharePoint) for the configuration database in SQL Server 2000.
Select Users Already Have Domain Accounts for this configuration.
Click OK
From the Central Administration window, we need to create and configure the Content Database.
- Select Extend or Upgrade Virtual Server from the Virtual Server Configuration options.
- Select Default Web Site.
- Select Extend and Create Content Database.
- Provide our BASPool application pool.
- Provide the same username / password we used for our application pool setup.
- We need to now test SharePoint by creating a test site.

To verify that SharePoint is configured correctly

On the Start menu, point to Control Panel, click Administrative Tools, and then click SharePoint Central Administration.
Click “Create a top-level Web site”. Click your default Web site, typically named “Default Web Site".
On the next page, in the Web Site Address section, supply a name for the new Web site. In the URL Name box, type test. This will create the site http://BTSSERVERsites/test.
In the “Site Collection Owner” section, enter a valid username using the format domain\user (or simply the user name if not on a domain), and an email address, for example mail@mail.com.
Click OK.
On the next page, click the hyperlink for your new site. Then select a template for your site.

You should see your new Web site. This indicates that SharePoint is working correctly.

To delete this site, return to SharePoint Central Administration (to the home page) and select Delete Site Collection. Type the complete URL for the site to delete and then confirm the deletion.

· Important If the SharePoint Configuration database, Content database, and BizTalk Server 2004 exist on different computers, and if you use Windows authentication to access those databases, then you must have db_owner permissions on these databases when running BizTalk Server 2004 configuration. After BizTalk Server configuration is complete, these permissions should be removed from the SharePoint Configuration and Content databases.

Installing BizTalk Server 2004 for Development

Run the BTS 04 installation.

We want to Create a new BTS Group.

This will be the Master Secret Server.

Select UnTrusted for both Host and Isolated Host Application(s).

When prompted, we selected Yes to both, create an Analysis database for tracking and use an Analysis Server for BAM aggregations.

Next, we left the default names for the Windows Group Names, the BizTalk Host Name, Isolated Host Name, and left the Human Workflow Services Web Site the Default Web Site.

Next we specify the database for all of the database objects. NOTE: Analysis Services uses the machine name only and not the database instance name for this configuration. Also, we connect to this database using the user account current logged in as – which was used when the Analysis Services was configured (you can change this, but we are keeping it simple for this deployment).

Next we assign the service account that will be used as the log on as account for the specific Windows services. We used our new BtsService account created local to the machine.

Next, we left the default Bind Message Queuing to all IP addresses on this computer.

The last screen allows us to save the Configuration Setup.

After saving, click Next.

If there are no issues with our Groups / Permissions, the configuration will complete successfully.

Groups Needed on the Remote SQL Server

NOTE: These groups must be created manually on SQLSERVER server, and the names must match the default groups BTS ConfigFramework created on our BTSSERVER server.

· BizTalk Application Users

· BizTalk Isolated Host Users

· BizTalk Server Administrators

· SSO Administrators

Once these groups are created, we need to create the BtsService user account on the SQL Server SQLSERVER server. Create it just as you did for the BTSSERVER server. Remember to set it to run as part of the operating system.

Finally, add the BtsService account to the BizTalk Server Administrators and SSO Administrators groups that we just created on the SQLSERVER server.

This provides you a complete deployment of a stand-alone BTS environment that you can now develop / deploy against. This is not necessarily the deployment you would use where varying security issues come into play. For example, you may have web services that interact with a mainframe via Host Integration Server’s TI – and these may require a specific service account that is different from the BtsService account; also, a different instance of BTS may be needed for these orchestrations. I’ll cover this in another document addressing Multiple Instances of BizTalk Server 2004.

Clustered Enterprise Single Sign-On Deployment

Michael J. Hamilton, Sr. — Fri, 09 Nov 2007 19:45:18 GMT

Clustered Enterprise Single Sign-On (ENTSSO) Setup

When you want to configure BizTalk Server on multiple NLB (network load balancing) nodes, you will have to install / configure the SSODB (Enterprise Single Sign-On – ENTSSO) service on a clustered SQL Server instance.

For this document, SQL Server runs clustered on a 2 node cluster – SERVERNODE1 and SERVERNODE2.

This document provides a real deployment – where the domain names are generic in this case. For example, I use / and then the BTS Group name – exactly as BTS ConfigFramework would create the group name when performing a default stand-alone installation. (i.e. The Domain is HAMILTON, so I created the group HAMILTON/HAM BizTalk Server Administrators. I followed this convention with all of the Groups. Below, I simply called the domain DOMAIN and abbreviated the name as DOM and then the Group name.

Finally, you do not need to know how to install SQL Server on a clustered server, but you will need to know the VIRTUALMACHINENAME and VIRTUALINSTANCENAME of the SQL Server we're deploying to.

If they do not already exist, create two domain level groups for DOM SSO Administrators and DOM SSO Affiliate Administrators.
Add our domain DOMAIN\BtsService account to run as part of the operating system on each of the cluster nodes. (SERVERNODE1 and SERVERNODE2)¹.
Add the DOMAIN\BtsService account to the DOM SSO Administrators group.
Ensure that the service account has full control access to the cluster.
- To ensure this, start the Cluster Administrator.
- Select the cluster (on the left side, click the cluster – SQLCLUSTERNAME in this case).
- Select File-->Properties.
- On the Security tab, grant the DOM/BtsService domain account Full Control access to the cluster.

Ensure that our cluster has been configured before we install the ENTSSO.
- Cluster resources are usually created by the network administrator(s).
- We had 2 cluster resources created:
  - IP Resource (192.168.0.1)
  - Name Resource (VIRTUALSSO)
- We created one cluster group, and this group name must match the Name Resource – or our ENTSSO will fail. We created a group called VIRTUALSSO.
- During the creation of the Cluster Group (VIRTUALSSO) we include our Resource Name and IP Resource as dependencies of this new Group.
- We are now ready to run the BTS installation.

From the primary / active node of the cluster (SERVERNODE1 was primary when we did this).
Run the Host Integration Server 2004 Installation.²
Select a custom installation.
Ensure that ONLY SSO and SSO Enterprise Manager are selected for installation.

Once the installation is complete, execute the ConfigFrameWork to setup our environment.

Ensure that Yes is set for Will this Single Sign-On server (SSO) hold the master secret key? Click next.
For the Windows Accounts, use the DOMAIN\BtsService account created earlier.
For the Database Configuration, point the setup to VIRTUALMACHINE\VIRTUALINSTANCENAME.

Once this is complete, backup the master secret on the active node.

Change to the C:\Program Files\Common Files\Enterprise Single Sign-On folder.
Type ssoconfig –generatesecret . For the file name we named the file SSOINITDDMMMYY – where DD is the day, MMM is the month (i.e. JAN, FEB, MAR, etc.), and YY is the 2 digit year. Our first file may have been SSOINIT23APR05.BAK.

Now switch to the secondary node (SERVERNODE2) and execute the configframework.exe on this server.

Ensure that No is set for Will this Single Sign-On server (SSO) hold the master secret key? Click next.
For the Windows Accounts, use the DOMAIN\BtsService account created earlier.
For the Database Configuration, point the setup to VIRTUALMACHINE\VIRTUALINSTANCENAME.

Now switch back to the primary node (SERVERNODE1) and change to the ENTSSO folder (C:\Program Files\Common Files\Enterprise Single Sign-ON).

Create (or copy/paste) the following into a text file and save it in this folder (we named the file ssodb.xml).

<sso>

<secretServer>VIRTUALSSO</secretServer>

</globalInfo>

</sso>

Once this file is saved, ensure that the ENTSSO server is running. Simply type net run entsso at the command prompt and it will start if it is not already running.

We now must configure ENTSSO to reference our new Secret Server name. To do this, type the following while in this folder (NOTE: replace with the filename you just created).

Type ssomanage –updatedb

If the command is successful, you will receive a response pretty quickly showing the new server name.

You could receive a runtime error regarding MSDTC – but we configured this prior to running this setup so we did not experience the error.

If you experience an error referencing the RPC server or no more endpoints available from the endpoint mapper then there is something invalid / incorrect in the Cluster Group configuration that was setup for this service. If you encounter this, review the Cluster Group configuration and ensure that 1) your Cluster Group name is the same as the Resource Name; 2) if the Cluster Resources / Group is correct, try simply restarting the ENTSSO from the Service Manager (Start-->Programs-->Administrative Tools-->Service-->Enterprise Single Sign-On).

The final stage is to configure the service and resource parameters for the cluster.

Start the Cluster Administrator
Click on our VIRTUALSSO cluster group
From the File menu select New-->Resource
In the New Resource dialog enter:
- ENTSSO for the Name of the resource
- Select Generic Service for the resource type
- Click Next
In the Possible Owners dialog, ensure that our two nodes appear as owners of the resource
In the Dependencies dialog, select our VIRTUALSSO Name Resource and click Next.
In the Generic Service Parameters dialog, type entsso for the service name, leave Start Parameters blank, and click (enable) Use Network Name for Computer name, then click Next.
At the Registry Replication dialog, simply click Finish.

Be sure to bring our Cluster Group (and resources) On-Line.

Now we’re ready to begin the BizTalk Server deployments.

NOTES

We created a DOMAIN level account named BtsService (the name is not case-sensitive. I spell it that way to emphasize there are two ‘s’ characters in the name). For each server that this account will need access to, we must set the service to Act as part of the operating system. To do this (and this must be done on each server / host computer that BizTalk communicates with), follow these steps:
1. At the server select Start-->Run and type in gpedit.msc and press .
2. Expand Computer Configuration-->Windows Settings-->Security Settings-->Local Policies and click on User Rights Assignment.
3. On the right side locate Act as part of the operating system and double-click here (or right-click and select Properties).
4. Click the Add User or Group option and add <domainName>/BtsService.
5. Click OK and OK again, to close out.
6. Now close the Group Policy MMC console.

Host Integration Server installs a newer version of the Enterprise Single Sign-On service, so we use HIS to setup our clustered SSODB and related service. Otherwise the HIS remote servers will fail indicating that the database is an older version and must be upgraded before proceeding. To get around this issue, simply install ENTSSO from the HIS 04 CD.

Either another TDDS is processing...

Michael J. Hamilton, Sr. — Fri, 09 Nov 2007 19:42:13 GMT

Either another TDDS is processing the same data or there is an orphaned session in SQL server holding TDDS lock. Either another TDDS is processing the same data or there is an orphaned session in SQL Server holding TDDS lock. SQL Server: \. Database: BizTalkDTADb

The above error seems to indicate that more than one TDDS is processing at the same time / on the same data, locking it and preventing access to it. If you experience this error in a clustered / multi-node BizTalk Server environment, follow these steps to ensure that your domain groups are added to the proper SQL Server database rolls that are created when BTS is installed. (NOTE: You will have to do this on each SQL Server instance where BizTalk is installed.)

Execute SQL Server Enterprise Manager (EM).
Expand the SQL Server instance we are working with, and expand Databases.
Expand the BAMArchive database, and select Roles.
Double-click (or right-clickàProperties) the BTS_ADMIN_USERS role. If the domain group BizTalk Server Administrators group is not a member of this role, click the Add button to add it. (NOTE: If the group does not appear as available when you click add, you will need to cancel this, select Logins for this database, and add the \BizTalk Server Administrators group as a new login to this database before you can add it as a role.)
Click okay to save.
Select Users on the left and ensure that the BizTalk Isolated Host Users group is a login for this database. If it is not, right-click on the right pane, select New User and add this login to this database.
Select Roles on the left, and double click the BTS_HOST_USERS role. IF the \BizTalk Isolated Host Users group is not a member of this role, click Add and add this login to this role. Click OK when done.
Expand the database BAMPrimaryImport on the left.
Select Users and here we need to add our BizTalk Service Account. This is not done automatically during the ConfigFramework.
Right-click on the right pane, select New User and add our service account login to this database.
Next, click Roles and double click the BAM_EVENT_WRITER role on the right. Add our service (BtsService) account, and the BizTalk Server Administrators logins to this role.
Click OK to save.
Double click the BAMQueryWS role and add our service (BtsService) account and the BizTalk Isolated Host Users accounts to this role.
Click OK to save.
Next, expand the BizTalkDTADb database object, and select Roles on the left.
On the right double-click the BAM_EVENT_WRITER role, and add the BizTalk Server Administrators login and the service (BtsService) login to this role. Click OK to save.
Double-click the HM_EVENT_WRITER role, and add the BizTalk Server Administrators and the service account to this role as well. Click OK to save.
Next, expand the BizTalkMgmtDb database object, and select Roles on the left.
Double-click the BAM_CONFIG_READER role, and add the service account to this role. Click OK to save.
Next, expand the BizTalkMsgBoxDb database object, and select Users.
Right-click on the right pane, select New User and add the service account as a login to this database. Click OK to save. Now select Roles on the left.
Double-click the BAM_EVENT_READER role, and add the service account to this role. Click OK to save.

Clustering Host Integration Server 2004

Michael J. Hamilton, Sr. — Fri, 09 Nov 2007 19:33:32 GMT

I had a challenge recently that was quite a blast sorting through.

The architecture included HIS 04 on the BTS NLB clustered nodes - where the HIS database objects were to be on a A/P Failover SQL Server 2000 Cluster.

By design, you cannot deploy the database objects to a clustered instance of SQL Server. I sent the following to PSS after implementing a successful 'work-around'.

Deploy Host Integration Server 2004 on a Clustered SQL Server 2000 Instance

PROBLEM

When you have SQL Server 2000 Enterprise installed on a A/A or A/P (active/active or active/passive) cluster, and you are running Virtual Instances of SQL Server, you will experience a problem when you try to install HIS on a different server, pointing the database connection to one of the virtual instances on the cluster. The ConfigFramework fails with the following found in the error log:

· [12:50:59 PM Info DatabaseHelper] Configuring HISAdmin database role.

· [12:50:59 PM Info DatabaseHelper] Executing database stored procedure:

· [12:50:59 PM Info DatabaseHelper] sp_grantlogin '\HIS Administrators'

· [12:50:59 PM Error ConfigHelper] Windows NT user or group '\HIS Administrators' not found. Check the name again.

In our case, we provided the \ for the database to connect to. For example, SERVER_A\SQLSERVER_A.

HIS passes the virtual machine name to SQL Server, and SQL Server cannot resolve the name because it is a virtual instance, and the groups are on the physical machine, and the command sp_grantlogin on that \GroupName will fail.

SOLUTION

Microsoft is aware of this problem, and provided us part of the following solution. We note additional items not provided in the solution, but necessary for the HIS, TI (Transaction Integrator MC), and ENTSSO to work properly.

For this to work, you must already have the ENTSSO installed on a SQL Server cluster where the SSODB resides. Also, you will need a stand-alone SQL Server that is not a virtual / clustered instance to install HIS onto.

Install HIS, pointing it to the stand-alone SQL Server (if SSODB does not already exist on a stand-along SQL Server, create it at this time, otherwise JOIN it).
Create the MSHIS_xxx database objects manually on the clustered, virtual instance of SQL Server. (MS)
On each node of the cluster, manually create the HIS Administrators and HIS Runtime Users security Groups. (MS)
Create logins for these security Groups on the virtual instance of SQL Server you created the database objects on. (MS)
Add these logins to the database objects created. (MS)
For each database object created, create 2 rolls – HISAdmin and HISRuntime.(MS)
Add the HIS Administrators login to the HISAdmin roll in each of the databases. (MS)
Add the HIS Runtime Users login to the HISRuntime roll in each of the databases. (MS)
From the machine you installed HIS, copy the file HIPTables.sql from the \Program Files\Microsoft Host Integration Server\System folder to a folder where the clustered SQL Server instance is running.
Run Enterprise Manager on the clustered SQL Server.
Select ToolsàQuery Analyzer from the menu bar, and execute the Query Analyzer.
Ensure that you are in the MSHISxx_HIP database.
Open the file HIPTables.sql file – from within Query Analyzer.
Execute this script at this time (MS).
Close Query Analyzer.
With Enterprise Manager still open, expand the MSHISxx_HIP database.
Select Tables on the left tree, and locate the table Computers on the right.
Right-Click and Return All Rows of this table object.
Here you will see the machine name of the computer you are on. You will want to change this to the machine name that HIS is actually going to be running from. NOTE: If you are running HIS from a NLB cluster, you will have more than one machine name here. For each HIS machine that will be using this database, enter those machines names now (KB 885003).
Save the edits, and exit Enterprise Manager.
On each machine that HIS is installed on, and that you want to interface with the clustered SQL Server, you must make the following registry edits.
Execute the registry editor – StartàRun and type in regedit and press .
Locate HKLM\Software\Microsoft\Host Integration Server\HIP and select HIP.
You will see and entry for Connectionstring in the right pane – double-click this (or right-clickàproperties) to edit this entry.
Change the database reference here to the \ of your clustered SQL Server.
Now, locate HKLM\Software\Microsoft\ENTSSO\SQL and select SQL
You will see an entry for Server in the right pane – double-click this to edit this entry.
Change the database reference here to the \ of your SSODB clustered SQL Server.
Performing these registry edits on each HIS machine that must use the clustered server will allow all components of HIS to work.

We had a lot of fun sorting this one out.