Posted on

BizTalk Server 2006 R2 released

BizTalk Server 2006 R2 has just been released.

The key new features differentiating the new release from BizTalk Server 2006 are:

  • Native support for Electronic Data Interchange (EDI).
  • Native support of Radio Frequency Identification (RFID).
  • While BizTalk Server 2006 integrates with Microsoft Office 2003 components and Windows XP (on a client OS), BizTalk Server 2006 R2 integrates with Office 2007 and Windows Vista.
  • Can make use of .Net 3.0 technologies such as Windows Communication Foundation (WCF) for messaging and Windows Workflow Foundation for BAM (Business Activity Monitoring).
  • New edition of BizTalk, called BizTalk Server Branch Edition. This edition is ideal for Hub and Spoke deployment scenarios for which only 1 BizTalk application is running in the Spoke nodes. Its official price is 1,800 USD; making it less than a quarter of the price of BizTalk Server Standard Edition. See BizTalk Server Editions for more details.

Both BizTalk Server 2006 and 2006 R2 supports only Visual Studio 2005 so far.
Visual Studio 2008 will be supported through a BizTalk Server Service Pack so that the BizTalk installation routine will be able to detect VS2008 and run with it.

For some, RFID is the most exciting feature introduced with BizTalk Server 2006 R2. The BizTalk RFID features include:

  • Data management capabilities.
  • Device abstraction and management capabilities.
  • Event processing engine that allows the creation of business rules and manage the execution of event pipelines for RFID events.

For more details about the new features of BizTalk Server 2006 R2, check the BizTalk Server roadmap.

Posted on

Functoid and BizTalk Application Versioning Problem

1. Problem:

I encountered a problem difficult to diagnose related to deploying a BizTalk Server 2006 application and a functoid that have been compiled together but then deployed with different versions.
For example, let’s say you have developed and compiled a BizTalk application “A” version 1 using a functoid “F” version 1. Later on, you change some of the code inside the functoid and so you have a new version of the functoid, let’s call it functoid “F” version 2.
Note that by version 1 and 2, I do not mean the assembly version number; it is just a nomenclature I use to differentiate the versions. In my case, the assembly’s version number is fixed.
I often deploy new versions of functoids without having to recompile neither redeploy the BizTalk application but this time, the following error message appeared:

Microsoft.XLANGs.Core.XTransformationFailureException: Error encountered while executing the transform XXXX. Error:Unable to create the transform.. —> System.ArgumentNullException: Value cannot be null.
Parameter name: extension
at System.Xml.Xsl.XsltArgumentList.AddExtensionObject(String namespaceUri, Object extension)
at Microsoft.XLANGs.BaseTypes.TransformBase.get_TransformArgs()
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData..ctor(Type transformBaseType)
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData._creator(Type t)
at Microsoft.XLANGs.RuntimeTypes.MetadataCache._slowFor(Type t)
at Microsoft.XLANGs.RuntimeTypes.MetadataCache.For(Type t)
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData.For(Type t)
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
— End of inner exception stack trace —
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
at Tourico.Tourico_SmartSearch.segment2(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

2. Solution:

The message was not recorded in the Windows Event Log but as I catch and log exceptions in an exception handler; I could see the exception in my log.
As the message is rather vague, I spent quite a lot of time checking the maps and schemas used in the orchestration but found no clue.
I finally noticed that a functoid’s code had been changed and once I recompiled and re-deployed the BizTalk Application, everything worked fine!

I am not sure of the exact reason as normally you don’t need to redeploy the BizTalk application after having updated and GACed a functoid.
Anyway, if one day you encounter an error message of the same flavor, recompiling and redeploying the application might just work fine. Maybe this hint can help someone in the future 🙂

3. Note about exception handler in BizTalk Server 2006.

For the people who do not know, you just need to use a scope shape and its exception handler to have the equivalent of a try-catch block in a BizTalk orchestration. That gives you the opportunity to take action and/or log errors when exceptions are thrown from the orchestration.

To create an exception handler, drop a scope shape into your orchestration, right click on it and select “New Exception Handler”. Note that only scopes that are non-transactional or long running transactional can have an exception handler.
Here is how it looks like:
Scope shape with its exception handlerEverything in the first square (Scope_1) will be the “try” part and everything in the second square (CatchException_1) will be the “catch” part.

Posted on

Biztalk 2006 multiserver installation

This article explains how to install BizTalk Server 2006 on multiple servers for a configuration with 1 SQL Server and 1 BizTalk Server.

Doing a multiserver BizTalk installation should be done once for practice before doing it on the production servers so that all the specificities to a multiserver install are well understood.
I will here share my experience in a practice multiserver BizTalk installation done on 2 Virtual Machines.

Simplified BizTalk Server Installation scenario.

For a first multiserver installation, I will keep a simplified scenario with only 2 servers and neither BAS nor BAM features installed. Only the following components will be installed:
– Enterprise Single Sign-On (SSO).
– BizTalk Group.
– BizTalk Runtime.
– MSMQT.
– Business Rule Engine.

There will be 2 virtual servers:
– 1 Virtual Machine to host SQL Server and act as a Domain Controller
– 1 Virtual Machine to host BizTalk Server.

This is the most basic multi-server install possible. It will nevertheless help you to understand how a multi-server BizTalk installation works.
For more complex installation scenarios with BAM, BAS and/or clustered servers, Microsoft provides a complete installation guide document, “BizTalk Server 2006 Installation Guide – Multiserver”. See in the reference section of this article for a link to the documentation.

Note that to follow this article as a lab, you will need the following software:
– Microsoft Virtual PC 2007 (Virtual PC is now free and you can download it here)
– Windows Server 2003
– SQL Server 2005
– BizTalk Server 2006

The need for a Domain Controller.

A very important difference between a single server and a multi-server installation is that the multi-server configuration requires you to use domain users and groups to run the various BizTalk services making having a domain controller a necessity.
On the other hand, a single server configuration can run with local windows groups and users.
To be more precise, these domain accounts and groups are used for the security configuration of the BizTalk Server databases. Indeed, the user account which runs the BizTalk server service must have access to the SQL Server. As SQL Server is installed on a separate machine, the use of a domain user account is therefore a necessity so that the account can have access rights on both the BizTalk machine and the SQL Server machine.

The important point to remember is that when you plan to install a multi-server configuration of BizTalk in your production environment, you will have to check with your hosting company to have access to a domain controller or to have them create all the necessary domain users and groups.

Create Domain Groups and Users.

For a single server installation, the setup procedure is able to create the Windows Groups and Users necessary for BizTalk as they are created on the local machine.
On a multi server installation, BizTalk Windows Groups and Users must be created manually on the Domain Controller. The setup procedure is not able to create the Windows Groups and Users on a Domain Controller.

BizTalk Installation, Configuration and Applications Deployment considerations.

To be able to install and configure BizTalk Server 2006, you have to log on the server using a Domain User who has Administrator rights on both the SQL Server and the BizTalk Server. Moreover, that domain user must also be part of the BizTalk Server Administrators group and the SSO Administrators group.
The user must also have the sysadmin role on the SQL Server.

I found out something that is, as far as I know, NOT mentionned in the BizTalk documentation: the user installing BizTalk Server must also have the Domain Administrator role. Technically, this privilege does not have to be granted when installing BizTalk Server but only when configuring it. It is because when the BizTalk Server Configuration tool runs, the tool must be able to check if the Windows accounts assigned to the various BizTalk services belong to the Windows groups set for these services. Only a user being domain administrator has the right to check other users properties.

After BizTalk Server is configured and installed, the user does not have to be part of the Domain Administrators group anymore. Moreover, its privileges on the SQL Server can be lowered to dbo instead of administrator. That way the user can be used to install BizTalk Applications without having unnecessary privileges.
FYI, installing BizTalk application creates tables, and executes SP on the BizTalk DBs.

To simplify things I advise to create a “BTSAdmin” domain user who has these rights. Only the person who will install, configure and manage BizTalk applications should have that user login information.

The BizTalk Server 2006 installation guide provides a list of all the necessary Groups and User that need to be created. Microsoft also provides a best practice guide on how to implement the Windows Groups and Users for BizTalk Server 2006.

Microsoft Distributed Transaction Coordinator (MS DTC) considerations.

Network DTC access and Network COM+ access must but enabled for all BizTalk and SQL servers. It is turned off by default on Windows Server 2003.

SQL Server Considerations.

SQL Server client tools must be installed on all BizTalk servers. The client Tools installed must be of the same version as the SQL Server installed.
SQL server must be started and running when running the BizTalk Server Configuration tool.

1. Creating the Virtual Servers.

To install the Virtual Servers, you will need Microsoft Virtual PC 2007 and Windows Server 2003.

In this step, we will create 2 Virtual Machines, one named SQLServer and another one named BizTalkServer. Windows Server 2003 will be the OS installed on both of them.
The machine named SQLServer will run SQL Server and also act as a Domain Controller while BizTalkServer will host BizTalk Server.

As installing Windows Server 2003 on a virtual machine is particularly slow, please refer to a previous post that explains how to install and clone virtual servers efficiently.

Once the 2 virtual machines are ready, set their networking setting to “Local only”. This option gives you networking support between virtual machines only. For a description of the different network settings available for Virtual PC, check the following link: http://support.microsoft.com/kb/833134

2. Installing the Domain Controller and creating Windows User and Groups.

2.1. Complete the setup of the SQLServer Virtual Machine.

1. Rename the VM. If you created the SQLServer Virtual Machine by using a base virtual machine and “sysprepped” it, you will need to rename it first. To do so, go to Control Panel > System > Computer Name and click “Change”. Input “SQLServer” in the machine name field. When prompted, do not restart the machine yet.
2. Set the Virtual Machine IP address. Set the SQLServer VM to have a static IP address of 192.168.0.1 – The 192.168.x.x address range is a typical IP range for private networks.
To modify the IP address of the VM, go to Control panel -> Network Connections -> Local Area Connection -> Properties -> TCP/IP -> Properties and use 192.168.0.1 for the IP address as well as the DNS server. In the subnet mask field type in 255.255.255.0 and leave the default gateway blank.

You must now reboot the SQLServer virtual machine.

2.2. Installing the Domain Controller.

Start the SQLServer virtual machine as it is the machine chosen to act as a Domain Controller (DC).
For this step, have the Windows Server 2003 installation disk at hand as it might be needed.

1. Make sure that you restarted the server after it has been renamed. This is because Active Directory can’t be installed after you changed the computer name without rebooting first.
2. Run “Manage Your Server”, and click “Add or Remove a Role” (next to “Adding Roles to Your Server” area).
3. Select the radio button “Typical configuration for a first server” and click “Next”.
4. Type in “biztalk.local” for your Active Directory domain name and click “Next”.
5. In the NetBIOS Name screen, accept the default setting and click “Next”.
6. In the Forwarding DNS Queries screen, select “No, do not forward queries” and click “Next”.
7. Click “Next” again and “OK” in the pop up window. If prompted to insert Windows Server 2003 disk, click on “Use Physical Drive” in the “CD” menu of the windows containing the Virtual Machine. You might additionally have to point to some files in the \I386 folder located on the Windows Server installation disk.
8. When the installation is almost complete, the VM will restart and finish the DC setup. Once the virtual machine has rebooted itself, a “Server Configuration Progress” window will open; click “Next” and “Finish”. The domain controller installation is now completed.

Note: Once your server is promoted to be a Domain Controller, the local administrator is promoted to become the domain administrator.
Moreover, it is not possible to log on the local machine anymore; you can only log on the domain. The concept of local Users and Groups doesn’t exist anymore and if you try to run lusrmgr.msc, a message will be displayed saying that is not possible to manage local groups and users on a Domain Controller. Only domain groups and users can be created and managed.

2.3. Create BizTalk Domain Users and Groups.

Start the Domain Controller, the SQLServer VM.
As we don’t install all the features of BizTalk Server, we create only a subset of the Windows Users and Groups defined for BizTalk Server 2006. This subset of Groups and Users is tailored for the features installed in this article.

1. Run “Manage Your Server” and click on “Manage users and computers in Active Directory”, located next to the “Domain controller (Active Directory)” area. This will open the Active Directory Users and Computers MMC (Microsoft Management Console). Alternatively, you can open it by going to: Control Panel > Administrative Tools > Active Directory Users and Computers.
2. Expand biztalk.local
3. Create a BizTalk Organizational Unit. To keep things tidy, we place the BizTalk Users and Groups in an Organizational Unit (OU). To do so, right click on “biztalk.local” and click New -> Organizational Unit. For the Organizational Unit name, enter “Biztalk”.
4. Create the Windows Groups. These groups will be used for the security configuration of the BizTalk Server databases. Right click on the Organizational Unit “BizTalk” and click New -> Group. For each group created, enter the group name specified in the table bellow, keep the default settings and click “OK”.

Group Name
SSO Administrators
SSO Affiliate Administrators
BizTalk Server Administrators
BizTalk Server Operators
BizTalk Application Users
BizTalk Isolated Host Users

There are 6 Groups created in total.
5. Create the BizTalk Windows Service Accounts (Windows Users). Windows Users are required for the various BizTalk services. You might want to set all the users to use the same password so that managing them is easier. Right click on the Organizational Unit “BizTalk” and click New -> User. For each user created, enter the full name and the user logon name specified in the following table (under the “Full Name” and “User logon name” columns) and click “Next”. In the following screen, enter the user’s password, uncheck “User must change password at next logon”, check “User cannot change password” and “Password never expires”. Finally, click “Next” and “Finish”. Repeat the procedure for every Windows User.

Full Name User logon name
Enterprise Single Sign-On Service SSOService
BizTalk Administrator BTSAdmin
BizTalk Host Instance Account BTSAppHost
BizTalk Isolated Host Instance Account BTSIsolatedHost
Business Rule Engine Update Service Account ReuService

6. Add the Windows Service Accounts to their respective Groups.

Windows Group Windows User
Server Administrators biztalk\BTSAdmin
SSO Administrators biztalk\BTSAdmin and biztalk\SSOService
BizTalk Application Users biztalk\BTSAppHost
BizTalk Isolated Host Users biztalk\BTSIsolatedHost

7. Close the Active Directory Users and Computers MMC.

Remember that the Windows Users will be used to run the different BizTalk services and the Windows Groups are used to manage security and access rights to the SQL Server.

In case you would install all the BizTalk server features, you can find a complete list of Windows Users and Groups needed for BizTalk Server in the BizTalk Server 2006 installation guide. You should also read the Microsoft guideline to implement Windows Groups and Users for BizTalk Server 2006.

2.4. Chose the Domain User performing the BizTalk multiserver installation.

If you continue the installation procedure logged on the virtual servers with the Domain Administrator, you don’t need to do this step. Nevertheless, in real environments, you will most likely not want or have the possibility to use the Domain Administrator to install BizTalk Server. In that case, you will have to create a domain user who is Administrator on both BizTalk and SQL Server machines and also member of the “BizTalk Server Administrators” and “SSO Administrators” groups.

In this practice installation, we will choose the BTSAdmin domain user that we have just created to execute the BizTalk Server 2006 multi-server installation. As we added BTSAdmin in the “BizTalk Server Administrators” and “SSO Administrators” groups already, the remaining task is to give the user administrator privileges on both the SQLServer and the BizTalkServer VMs.

2.5. Configure the SQLServer VM Administrator and SQL Server sysadmin Role.

To give BTSAdmin administrator privileges of the SQLServer VM:
1. Run “Manage Your Server” and click on “Manage users and computers in Active Directory”, next to the “Domain controller (Active Directory)” zone.
2. Under the “Builtin” folder, add “biztalk\BTSAdmin” to the “Administrators” group. Note that in our lab this will unintentionally make the BTSAdmin user a domain administrator, but in a normal scenario, SQL Server would not be a Domain Controller and so BTSAdmin would just be administrator of the local machine.

As by default the Windows Builtin\Administrators group has the sysadmin SQL role on the SQL Server, the BTSAdmin user will also have the sysadmin role as BTSAdmin is now part of the Administrators group. Once SQL Server is installed, you will be able to check that by opening the SQL Server Management Console, go to “Security\Server Roles” and double click on the “sysadmin” role. The pop up window will show all the windows and SQL logins having the sysadmin role.

3. Installing SQL Server.

3.1. Install SQL Server.

In this step, we will install SQL Server 2005 on the virtual machine that will host the BizTalk databases.

Only a subset of the SQL Server 2005 components are needed for the BizTalk features we have chosen to install. These are: “SQL Server Database Services” and “Workstation components, Books Online and Development tools”.
If you plan to install the BAM component of BizTalk Server, you will have to additionally install the following SQL Server 2005 components: “Analysis Services”, “Notification Services” and “Integration Services”.

The SQL Server service should use the Local System account as the Service Account, and you should configure the SQL Server Agent to start at the end of the setup.

SQL Server 2005 installation procedure:
1. Start the Virtual Machine SQLServer. Log on using the domain user you have chosen to use for the BizTalk multiserver installation (see paragraph 2.4).
2. Start the setup of SQL Server from its installation disk.
3. On the SQL Server Installation welcome screen, click “Server components, tools, Books Online, and samples”.
4. Accept the license terms and conditions and click “Next”.
5. On the Installing Prerequisites screen, click “Install”. Note that all the necessary prerequisites, such as the .Net Framework 2.0, are present on the installation disk.
6. Once the prerequisites are installed, click “Next”.
7. On the Welcome to the Microsoft SQL Server Installation wizard, click “Next”.
8. On the System Configuration Check, click “Next”.
9. Enter the registration information on the Registration screen, click “Next”.
10. On the Components to Install screen, chose the 2 components “SQL Server Database Services” and “Workstation components, Books Online and Development tools”, click “Next”.
11. Leave the “default instance” radio button selected on the Instance Name screen, click “Next”.
12. On the Service Account screen, make sure that the check box “Customize for each service account” is cleared; select the radio button “Use the built-in System account” with “Local System” selected in the dropdown list. Note that you could also use a Windows User account instead and if you do so, enter a local account or domain account and its password. Lastly, tick the check box “SQL Server Agent” in the “Start Services” section so that the SQL Server Agent starts once the setup is completed. Click “Next”.
13. In the Authentication mode select “Windows Authentication Mode”. Note that Mixed Mode can also be used but it is potentially less secure and not advised by Microsoft. Click “Next”.
14. On the Collation Settings screen leave the default and click “Next”.
15. Click “Next” again and then “Install”.

3.2. Configuring the SQL Server Virtual Machine.

Once SQL Server is installed, you need to configure it.

3.2.1 Configure SQL Server for Remote Connections.

In order for the BizTalk servers to connect to SQL Server, remote connections need to be enabled.
To do so you need to:
1. Run SQL Server Surface Area Configuration, found in Programs -> Microsoft SQL Server 2005 -> Configuration Tools
2. Once the tool opens, click on Surface Area Configuration for Services and Connections.
3. Locate “Remote connection” under the Database Engine tree and enable local and remote connections for both protocols by selecting “Local and remote connections” and “Using both TCP/IP and named pipes” radio buttons.

3.2.2. Configure Microsoft Distributed Transaction Coordinator (MS DTC).

In order for BizTalk to run against its databases located on a remote SQL server, you will need to turn on MS DTC options (both on the SQL Server and BizTalk Server).
Follow the next steps on the SQLServer VM:
1. Open the Control Panel and open “Add or Remove Programs”. Once open, click “Add/Remove Windows Components”.
2. Once the Windows Components Wizard open, select “Application Server” and click on de “Details” button.
3. Select the check boxes in front of “Enable network COM+ access” and “Enable network DTC access”. Click “OK”
4. You are now back to the Windows Components Wizard window; click “Next” and then “Finish”.
5. Restart the server.

If your SQL Server is installed on the Domain Controller like in this practice installation, enabling Network DTC Access will not work as there is a bug between DTC and the Domain Controller service. I posted a previous article explaining the problem and how to solve it, see: Enabling network DTC access fails on a Domain Controller server.

3.3 Install and Configure Enterprise Single Sign-On Master Secret Server.

I chose to install the Enterprise Single Sign-On Master Secret Server on the SQL Server virtual machine so that I could try it out.
Nevertheless, it is more common to install the Master Secret Server on the BizTalk Server machine when there is only 1 BizTalk machine.
In case you have a cluster of several BizTalk Server machines, you can chose to either install the Master Secret Server on a separate machine (such as in this example) or install it on one of the BizTalk Server.
The points to remember are:
– There can be only 1 machine being the Master Secret Server. It can either be one of the machines hosting BizTalk Server or any other.
– All machines running BizTalk and the machine being the Master Secret Server will have the Enterprise Single Sign On Windows Service running.

See the Microsoft documentation on installing BizTalk Server 2006 for more details on how to cluster SSO.

1. Start up the BizTalk Server 2006 Installation.
2. On the Microsoft BizTalk Server 2006 Installation Wizard page, click “Install Microsoft BizTalk Server 2006 on this computer”.
3. On the Customer Information page, type your user name and organization, and then click “Next”.
4. Accept the License Agreement and click “Next”.
5. On the Component Installation page, select ONLY “ESSO Administration Module” and “ESSO Master Secret Server”, found under “Additional Software”. Unselect all other components.
6. After the installation, make sure that the checkbox “Launch BizTalk Server Configuration” is selected and click on “Finish”. The BizTalk Server Configuration will start.
7. In the BizTalk Configuration, select the “Custom Configuration” radio button. In the “Service Credential” zone, type in “BIZTALK\SsoService” and its password. It is the domain account that will run the SSO Windows Service. Click “Configure”.
8. In the summary window, click “Next”.
9. On the final window, click “Finish”
10. Use Event Viewer to verify the ENTSSO service has started successfully.

4. Installing BizTalk Server.

In this step, we will install the BizTalk prerequisites, BizTalk Server 2006 and operate the necessary configuration.
Before starting the BizTalk virtual machine, make sure that its network configuration setting is set to “local only”.

4.1. Complete the setup of the BizTalkServer VM.

1. Start the virtual machine BizTalkServer.

2. Change machine name and join the domain. If you created the BizTalkServer Virtual Machine by using a base virtual machine and “sysprepped” it, you will have to rename the VM first. To do so, go to Control Panel -> System -> Computer Name and click “Change”. Change the computer name to “BizTalkServer”.
In the same window, join the domain by selecting the “Domain” radio button and type “biztalk.local” for the Domain name. Click “OK”. You will be prompted to enter the Domain Administrator user name and password.
Before restarting the Virtual Machine you should execute the next step.

3. Set static IP address. To modify the IP address of the VM, go to Control panel -> Network Connections -> Local Area Connection -> Properties -> TCP/IP -> Properties and use 192.168.0.2 for the IP address, 255.255.255.0 for the subnet mask, leave the default gateway blank and set the DNS server IP to 192.168.0.1

You can now reboot the BizTalkServer virtual machine. Note that for the BizTalkServer VM to boot and run properly as being part of the Domain, the virtual machine acting as the Domain Controller will have to be running as well. This means that from now on, the SQLServer VM must already be running when you start the BizTalkServer VM.

4.2. Configure BizTalkServer VM Administrator.

From now on, you will always log on the BizTalkServer VM using a domain account so that you are logged on the domain.

If you chose to execute the installation of Biztalk Server 2006 for a multi-server environment using the Domain Administrator, you don’t need to do this step and you will log on the BizTalkServer VM using the domain administrator account to you install BizTalk Server. Otherwise, continue.
See paragraph 2.4 for more details about choosing a domain account to install BizTalk Server 2006.

Once you have rebooted the BizTalkServer VM, log on the machine using the Domain Administrator account, so you have to log on the domain, not the local machine which is the default choice.

We have previously chosen to give the domain user BTSAdmin administrator privileges on both the SQLServer and the BizTalkServer VMs so that it can execute the BizTalk setup procedure.

To add BTSAdmin user as an Administrator of the BizTalkServer VM;
1. Open “Computer Management” found under Control Panel -> Administrative Tools.
2. Under the “Builtin” folder, add “biztalk\BTSAdmin” to the “Administrators” group.

You can know log off or reboot the BizTalkServer VM and log on again using the BTSAdmin domain user which is now administrator of the BizTalkServer machine.

4.3. Installing prerequisites.

4.3.1 Install IIS 6.0.

BizTalk server requires IIS for the HTTP Adapter, SOAP Adapter, Windows SharePoint Services Adapter, SSL encryption, Business Activity Services (BAS), Human Workflow Services (HWS).

In this step you might need access to the Windows Server 2003 installation disk.

IIS 6.0 installation procedure:
1. Click Start, point to Control Panel, and then click “Add or Remove Programs”.
2. In the Add or Remove Programs dialog box, click “Add/Remove Windows Components”.
3. In the Windows Components Wizard, select “Application Server” and then click “Details”.
4. Select “ASP.NET” and make sure that “Internet Information Services (IIS)”and “Enable network COM+ access” are selected as well. Click “OK”, and then click “Next”.
5. On the Completing the Windows Components Wizard page, click “Finish”.

4.3.2 Install the .Net framework 2.0 or Visual Studio 2005.

If the machine is used for the BizTalk runtime-only (such as on a production environment), you should install the .Net framework 2.0. You can download a redistributable version of .Net 2.0 framework here.
If the machine is used for the BizTalk runtime and/or development, Visual Studio 2005 or the .Net Framework 2.0 SDK should be installed instead.

4.3.3. Install SQL Server 2005 Client Tools.

1. Insert the SQL Server 2005 DVD in the DVD-ROM drive and browse to the \Tools folder and double click “setup.exe“.
2. Accept the licensing agreement on the End User License Agreement page and click “Next”.
3. On the Installing Prerequisites page, click “Install”. Once the prerequisites are installed, click “Next”.
4. On the Welcome to the Microsoft SQL Server Installation Wizard page, click “Next”.
5. On the System Configuration Check page, ensure that there are no errors before you continue. Note that as we are running on a virtual machine there will be a warning for the “Minimal Hardware Requirement”, ignore it and click “Next”.
6. On the Registration Information page, click “Next”.
7. On the Feature Selection page, under “Client Components”, select “Will be installed on local hard drive” for the following Components: “Connectivity Components”, “Management Tools”, “SQLXML Client Features” and “Legacy Components”. Click “Next”.
8. Once the components are installed, click “Next” and then “Install”.
9. Once the setup is finished, click “Next” and then “Finish”.
10. Restart the virtual machine.

4.3.4. Configure Microsoft Distributed Transaction Coordinator (MS DTC).

To be able to install BizTalk server (run the BizTalk Configuration tool, to be more precise), install BizTalk applications and run BizTalk applications, network DTC access must be enabled.

Follow the next steps to do so:
1. Open the Control Panel and open “Add or Remove Programs”. Once open, click “Add/Remove Windows Components”.
2. Once the Windows Components Wizard open, select “Application Server” and click on the “Details” button.
3. Select the check box in front of “Enable network DTC access” and make sure that “Enable network COM+ access” is also selected. Click “OK”
4. You are now back to the Windows Components Wizard window; click “Next” and then “Finish”.
5. Restart the VM.

4.4. Installing BizTalk Server 2006.

4.4.1. Considerations:

Before you install BizTalk Server 2006, consider the following:
– If your computer name is longer than 15 characters, BizTalk Server Configuration will not work.
– The account you are logged on as must be part of the local administrators group and have DBA rights on SQL Server. After configuration is complete, you can lower the privileges to DBO.
– When installing BizTalk Server, there will be prerequisites components to install such as ADOMD.NET, SQLXML 3.0 SP3… You can either let the BizTalk Installation Wizard download them and install them for you or you can pre-download a cab file that contains all the prerequisites. You can see a list of all the prerequisite components required by BizTalk server here.
As we don’t have access to the internet from the Virtual Machine in this practice installation (we set the VM Network settings to “Local only”), we first need to download the BizTalk Server 2006 redistributable prerequisites cab file for Windows Server 2003 (32-bit) (BtsRedistW2k3EN32.cab) and then copy it on the virtual machine hard disk.

4.4.2 Install BizTalk Server 2006.

1. Start the BizTalkServer Virtual Machine and log on using the domain user you have chosen to use for the BizTalk multiserver installation (see paragraph 2.4).
2. Start up the BizTalk Server 2006 Installation; Double click on “Setup.exe” located on the root of the BizTalk Server 2006 installation disk.
3. On the Microsoft BizTalk Server 2006 Installation Wizard page, click “Install Microsoft BizTalk Server 2006 on this computer”.
4. On the Customer Information page, type your user name and organization, and then click “Next”.
5. Accept the License Agreement and click “Next”.
6. On the Component Installation page, select the following components: “Documentation”, “Server Runtime (without Base EDI Adapter)”, “Administration Tools” and “Business Rules Components”. Click “Next”.
7. On the Redistributable Prerequisites page, select “Automatically install the redistributable prerequisites from a CAB file” and specify the cab file location. This is the cab file that we pre-downloaded in paragraph 4.4.1. Click “Next”.
8. On the Summary page, verify that the components you selected to install are correct. Click “Install”.
9. On the Installation Completed page, unselect the “Launch BizTalk Server Configuration” check box, and then click “Finish”.
10. You can eventually stop your virtual machine and commit your change if you are using undo disk so that you start a new session when you are running the BizTalk Server Configuration tool.

4.5. Check that MS DTC network access is enabled on all servers participating in the BizTalk multiserver installation.

The last step to install BizTalk Server 2006 is to run the Configuration Tool. For the BizTalk Server Configuration Tool to run, all SQL Server and BizTalk Server machines must have Network DTC access and Network COM+ access enabled. So, before continuing and configure BizTalk, verify that this is the case on all the machines participating in the BizTalk multiserver installation.
In paragraph 3.2.2, I highlighted that there is a bug in turning on Network DTC access on a machine which is a Domain Controller so, double checking that Network DTC access is enabled on all machines can save you from a lot of trouble.

4.6. Configure BizTalk Server and other components.

The BizTalk configuration is the most likely point of failure of the BizTalk multiserver installation. If you use Virtual Machine with undo disks, you should commit your changes to the VM’s virtual hard disk before running the BizTalk Server Configuration Tool so that you have a fresh session when starting the configuration process. In that case, if the configuration fails, you will be able to cancel the change and go back to the state the Virtual Machine was before starting the BizTalk configuration. This means that the only thing you would have to re-do is to run the BizTalk Configuration again (after fixing the cause of the problem) but all previous installation tasks will be preserved.

1. Starts the BizTalk Server Configuration from the Microsoft BizTalk Server 2006 menu (Programs -> Microsoft BizTalk Server 2006).
2. Select the “Custom configuration” radio button. “Basic configuration” can be used for single server installation only. For the “Database server name”, type in the name of the machine hosting SQL Server: “SQLServer“. For the “User Name” type in “BIZTALK\BTSAdmin” and its password. Click “Configure”.
3. You are now on the Overview Panel of the BizTalk Configuration tool. You will now configure all the BizTalk components per section.
4. Enterprise SSO. Click on Enterprise SSO; tick the checkbox “Enable Enterprise Single Sign-On on this computer”. Select the radio Button “Join an existing SSO Sytem”. For the Database configuration, make sure the Server Name is “SQLServer” and the DB Name is “SSODB”. Set the account name to “BIZTALK\SsoService” for running the SSO Windows Service.
5. Enterprise SSO Secret Backup. No change as the Master Secret Server is the SQLServer machine, not the BizTalkServer machine. See paragraph 3.3 in which we installed the Enterprise SSO Master Secret Server. Once BizTalk is fully configured, you will be able to verify that by running the SSO Administration snap-in and check the value of “SSO Secret Server” field under the “system” sub-tree.
6. Group. Tick the checkbox “Enable BizTalk Server Group on this computer”. Select the radio button “Create a new BizTalk Group”. Under “Data Stores”, check that the Database Server Name is set to “SQLServer” for the 3 BizTalk databases that will be created. Under “BizTalk Administrative Roles”, change the Windows Group to use “BIZTALK\BizTalk Server Administrators” and “BIZTALK\BizTalk Server Operators”. Be careful that the default values are Windows Groups with the same name but local to the BizTalk machine (not the Groups defined in the Domain).
7. BizTalk Runtime. Tick the checkbox “Register the BizTalk Server runtime components”. Make sure that both checkboxes “Create BizTalk In-Process Host and Instance” and “Create BizTalk Isolated Host and Instance” are checked. There is no need to tick the “Trusted” checkboxes. Select “Trusted” only if you want to pass the credentials (SSID and/or Party ID) of the sender when submitting messages to the MessageBox database. This is equivalent to creating a trust relationship between the servers.
Under “Windows Service”, Change the account names to “BIZTALK\BTSAppHost” for the BizTalk Host Instance Account and “BIZTALK\BTSIsolatedHost” for the BizTalk Isolated Host Instance Account.
Under “Windows Group”, change the Windows Group to “BIZTALK\BizTalk Application Users” and “BIZTALK\BizTalk Isolated Host Users”. Be careful that the default values are Windows Groups with the same name but local to the BizTalk machine.
8. MSMQT. No changes.
9. Business Rule Engine. Tick the checkbox “Enable Business Rules Engine on this computer”. Make sure that the Server Name is “SQLServer” and the Database Name is “BizTalkRuleEngineDB”.
Under “Windows Service”, set the Account name to “BIZTALK\ReuService”.
10. HWS Runtime. No changes.
11. BAM Tools. No changes.
12. BAM Alerts. No changes.
13. The configuration is now finished. Click on “Apply configuration”. Review the configuration settings and click “Next”. This is the most likely point of failure in this lab, hence the usefulness of undo disks. If things go bad, look at the problem carefully (you can find clues from the log file generated by the BizTalk Server Configuration tool) and check that you have completed every step of the setup correctly on each server.

4.7. Verify Configuration.

You can check if the configuration went well by having a look at the Windows Event Log, there should be a lot of Information entries and no errors or warning related to BizTalk.

You should also start the BizTalk Server administration console and verify the BizTalk Server host instance is started (found under BizTalk Group\Platform Settings\ Host Instances). Try stopping and starting the host instance.

Finally, deploy and test a simple orchestration, such as the HelloWorld orchestration found in the BizTalk SDK samples.

5. References.

MS documentation – BizTalk Server 2006 Installation and Upgrade Guides.

Simplified BizTalk Server 2006 Installation.

Guidelines for Implementing Active Directory Permissions on Multi Server BizTalk Installations.

Posted on

Enabling network DTC access fails on a Domain Controller server

For a personal lab I did a few days ago, I noticed a bug when trying to enable Microsoft Network Distributed Transaction Coordinator Access (Network DTC Access) on a server which is a Domain Controller.

I installed Windows Server 2003 on a machine and promoted the server to be a Domain Controller. As it was a lab, I re-used the same server to host SQL Server 2005 and wanted to enable Network DTC access.

I enabled Network DTC access and Network COM+ access doing the standard following procedure:
1. Open the Control Panel and open “Add or Remove Programs”. Once open, click “Add/Remove Windows Components”.
2. Once the Windows Components Wizard open, select “Application Server” and click on de “Details” button.
3. Select the check boxes in front of “Enable network COM+ access” and “Enable network DTC access”. Click “OK”
4. Back in the Windows Components Wizard window; click “Next” and then “Finish”.

Everything seemed to be fine and no error message was displayed. Nevertheless, warning messages could be seen in the Windows Event Log:

MSDTC Warning message when trying to enable Network DTC accessThe main message saying:
“MS DTC could not correctly process a DC Promotion/Demotion event. MS DTC will continue to function and will use the existing security settings. Error Specifics: d:\nt\com\complus\dtc\dtc\adme\uiname.cpp:9351, Pid: 3368
No Callstack,
CmdLine: C:\WINDOWS\system32\msdtc.exe”

Going back to the “Add/Remove Windows Components”, I could see that the Network COM+ access was enabled but Network DTC access was not, the check box was unselected:

Network DTC access can't be enabled on Domain Controller
I rebooted the machine, tried to enable Network DTC access again but it still did not work and the same error kept appearing in the Event Log.

I checked if MS DTC was running with the correct Windows Account as I read that sometimes MSDTC could be running under the Service Account “Local System” instead of “NT AUTHORITY\NetworkService” but MSDTC was running with the correct account:

MSDTC run under NetworkService Windows Service Account

Solutions:
(updated 27th of August 2007)

I found 2 solutions to solve this issue:

1. Un-install and re-install MS DTC manually using the following procedure:
– Open a command prompt.
– Stop the MSDTC Windows Service by running the command: net stop msdtc.
– Uninstall MSDTC by running the command: msdtc –uninstall.
– Delete the following registry hives out of the registry if they exist:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msdtc
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC
– Reboot the machine.
– Open the command prompt and run msdtc –install (this will recreate the MSDTC’s registry keys with proper value).
– Go to the “Add/Remove Windows Components” and enable Network DTC access.

2. Use the following trick.
– Start Administrative Tools -> Component Services.
– Navigate the tree view on the left to:
   Console Root -> Component Services -> Computers -> My Computer
– Right click on “My Computer” and select Properties.
– Select the MSDTC Tab
– Under Transaction Configuration near the bottom, click “Security Configuration“
– On the Security Configuration screen, click “OK“, don’t change anything.
– Back on the My Computer Properties screen, click “OK” again.
– Right click on “My Computer” in the tree view and click on “Stop MS DTC“
– Right click on “My Computer” in the tree view and click on “Start MS DTC“
– Close the Component Services snap-in.
– Go to the “Add/Remove Windows Components” and enable Network DTC access.
Note that we haven’t changed any settings! It works nevertheless meaning that something must have changed behind the scene.

Conclusion:
Using either of these solutions, MS DTC Network Access will be really enabled and no warning message signaling a problem will appear in the Windows Event Log anymore.

Posted on

Cloning a Virtual Server Machine

If you need to install more than one Virtual Machine using the same O.S. with Virtual PC, creating each virtual machine and installing the O.S. separately is very time consuming. To speed up the process, it is possible to create 1 virtual machine, install the Operating System, all other applications common to all virtual machines and then clone it.

The first virtual machine and its clones should be created as a stand alone machine (belonging to the workgroup “WORKGROUP”) and, if needed, add them to a domain after the cloning process. I did not try to clone a virtual machine that was already belonging to a domain. It might work but as I did not test it so I will not comment on it.

To install the Virtual Servers, you will need of the following software:
– Microsoft Virtual PC 2007
– An Operating System, Windows Server 2003 is used in this example.

For Windows Server 2003, you can either use the disks or .iso files as Virtual PC allows you to use .iso files directly as virtual disks.

1. Install Virtual PC.

Firstly, you need to install Virtual PC on your host machine. Virtual PC is free and can be found here.

Virtual PC can host client operating systems such as Windows XP but also server operating systems such as Windows Server 2003 – even if the documentation does not mention about Server versions of Windows.

There is another Virtualization product from Microsoft: Virtual Server – the current version being Virtual Server 2005.
Virtual Server 2005 and Virtual PC use the same technology under the hood but Virtual Server is more oriented to real world production usage, it performs better, scales better and has more administrative tools so that administrating all the virtual servers is easier.
It is nevertheless more complicated and not needed for most testing scenarios or for private use. It is easier to use Virtual PC when the host machine is either a desktop or a non production server.
In my opinion, Virtual Server should be used only when your goal is to implement virtualization in your production environment.

2. Creating the Virtual Machines.

As said earlier we need to first create a “base” virtual machine on which all other virtual machines will be cloned.
Each virtual machine clones needs to be renamed but just changing the machine name is not sufficient, the cloned machine also needs a new SID, GUID, MAC Address and so on. This is especially important for COM components such as MSDTC. There is a tool provided by Microsoft that does all these tasks: sysprep.
Note that once a machine is “sysprepped”, the new SID, GUID and so on are given only AFTER the machine reboots for a first time.

2.1 Creating the Base Virtual Machine

In this step we will create a base virtual machine and install its OS, Windows Server 2003. You may additionally install other applications that you want to have in all your cloned virtual machines.

2.1.1 Create a Virtual Machine.

Download in install Virtual PC, run the Virtual PC Console and create a new virtual machine. The new virtual machine wizard asks you for 2 important configuration settings:

Memory allocation.
The memory you should reserve for the virtual machine depends on how many virtual machines will run in the same time and how much memory your host machine is equipped with.
If you have 1 Gb of memory and plan to install 2 virtual servers on it so 320 Mb per virtual machine is a good choice. If you have 2 Gb, chose 640 Mb.
It is important to know that the entire block of memory will be allocated to the virtual machine when you start it and fully released when you stop it.
If you create more virtual machines than your machine has memory for, the virtual machine will refuse to start.
So, if all virtual machines must be able to run in the same time, the rule of thumb is trivial; just divide your amount of memory by the number of virtual machine + 1 (for the host machine). If you need to run more programs on your host OS, you might want to give less memory the to guest OS and more to the host.
Note that the minimum amount of memory for installing Windows Server 2003 is 256 Mb.

Hard disk allocation.
When asked to choose the size of the virtual hard disk, you can keep the default value as it does not really matter. By default, the size of the file containing the virtual hard drive (.vhd file) will NOT be size of the virtual hard disk but rather the size of the data contained in the virtual hard disk.

2.1.2. Set up the Base Virtual Machine

Install Windows Server 2003.
Once a virtual machine is created, you can click on “start” and the virtual machine will boot up in a new window. You will see a BIOS-like startup sequence displayed and you can install Windows Server 2003 from there. You can click on “CD” on the menu of the Virtual Machine windows and either chose “Use Physical Drive” or “Capture ISO Image”. After that, click on “Ctrl+Alt+del” in the Action menu of the Virtual Machine window so that it reboots on the installation disk. Note that the shortcut on the keyboard for that is “Right Alt + Del”.
When asked for Networking Configuration, just chose “Typical setup” and continue.

Install Virtual Machine Additions.
After Windows Server 2003 is installed you should install Virtual Machine Additions. This helps improving performance and also resolves issues in the handling of the mouse. Indeed, before installing this component, you might notice difficulties in having the mouse pointer exiting the virtual server windows. You can always bring back focus on your host OS by doing an “Ctrl+Alt+del”.
To Install Virtual Server Addition, click “Action” in the top menu of the windows containing the virtual machine and then chose “Install or Update Virtual Machine Additions”.

Install Service Pack
You should download and install the last Service Pack for Windows Server 2003 (SP2 at time of writing).

Lastly, you should install other common components / applications that you need on all your cloned virtual machines.

Tip: You can copy files or folder from your host machine to your guest machine and vice-versa simply by drag and drop.
Alternatively, you can setup a share folder. To do this, right click on the folder icon on the lower right corner of the window in which the guest OS is running and click “Share Folder…”

2.1.3. Sysprep the base virtual machine.

Before cloning the base virtual machine, it is important to run a tool called Sysprep on it. That way, when you create a virtual machine that uses a copy of the base virtual machine’s .vhd file, the cloned guest operating system will be assigned a new SID, GUID, MAC address, and so forth the first time it boots. This way you won’t end up with network / COM conflicts between different virtual machines that used a copy of the same base .vhd file.

You can get sysprep from 2 places:
– The Download center of Microsoft, here for Windows Server 2003 SP2. The download is an .exe file, run it and it will put a cab file, deploy.cab in your C:\WINDOWS\system32 folder. Sysprep is located in that .cab file.
– The file sysprep.exe is also located in the CAB file DEPLOY.CAB in the SUPPORT\TOOLS folder of the windows install disk.

To sysprep the cloned machine follow the next steps:

1. Start the base virtual machine and login as local administrator.

2. Download or copy the package containing sysprep into the virtual machine hard drive so that it is installed in the virtual machine (NOT the host machine!). Once you have access to the file DEPLOY.CAB on the virtual machine, extract all its files to a location, C:\Tools for example.

3. Create an answer file. The answer file contains the configuration settings used by sysprep. Sysprep comes with a help file called “deploy.chm” (also located in the deploy.cab package) which explains how to create the answer file for the specific version of Windows you are using (each version of Windows having a different version of sysprep). You can generate and answer file using a tool, the Setup Manager Wizard (setupmgr.exe).

Steps to create an answer file:
3.1. Start the Setup Manager wizard, setupmgr.exe, located in C:\Tools (the location where were extracted the files contained in deploy.cab).
3.2. Click “Next”.
3.3. Select “Create New” and click “Next” to create a new answer file.
3.4. Select “Sysprep Setup” and click “Next”.
3.5. Select the version of the Windows you are creating an answer file for, Windows Server 2003 Standard Edition in our case and then click “Next”.
3.6. Select “Yes – Fully automate the installation” and click “Next.”. So that we are not prompted for any information when “sysprepping” the cloned Windows.
3.7. Type in a default User Name and optionally an Organization for the cloned Windows, click “Next”.
3.8. Accept the default display settings by clicking “Next”.
3.9. Select your time zone and click “Next”.
3.10. In Product Key type the product key and click “Next”.
3.11. In licensing, select the type of license for the guest operating system, and click “Next”.
3.12. Type a computer name and click “Next”.
3.13. Set the administrator password and click “Next”. To ensure that the password will be set, the virtual machine’s password must be blank. Press Right-ALT + DEL (or click on CTL+ALT+DEL in the Action Menu of the virtual machine) and click “Change Password.” Type the old password and leave the new password blank. Click “OK.”
3.14. In the networking components settings, select “Typical Settings” and click “Next”.
3.15. Leave the machine in a workgroup (you can join a domain later) and click “Next”.
3.16. The remaining screens are less important so I will skip them. On the last screen, click “Finish”.
3.17. Keep the default location and name of the generated answer file (C:\Tools\sysprep.inf for our example), click “OK”. This is because the sysprep.inf file and sysprep.exe needs to be located in the same folder.
3.18. The answer file is now created, click on “Cancel” to exit the wizard.

4. Sysprep the Operating system. In this step we will run sysprep with its answer file so that the machine is fully renamed and reconfigured to avoid any clash between the base machine and the cloned machines.

Steps:
4.1. Run sysprep.exe located in C:\Tools
4.2. Click “OK” to clear the warning dialog.
4.3. In the option zone at the bottom of the window, check the “Don’t reset grace period for activation” box.
4.4. In the dropdown list, Make sure that the shutdown mode is “Shutdown”
4.5. Click “Reseal”
4.6. When prompted about regenerating SIDS, click “OK”. The guest operating system will be “sysprepped” and will automatically shut down. Once shutdown, do NOT restart the base virtual machine.
4.7. Copy the base .vhd file from the virtual machine into a folder you will use to store your base virtual machine. Then, in the file system, make the base .vhd file read-only.
It is important to know that from now on, the base vhd file should never be rebooted in a virtual machine. Instead, it should always be copied first to create a new virtual machine. If you rebooted on the original base vhd file, it would not be possible to reuse it as a base file again. This is because the virtual machine OS is assigned a new SID, GUID, MAC address, and so forth ONLY the FIRST time it reboots.
So, it is advised to make the base .vhd file read-only so that it can not be booted/modified accidently.

2.2 Creating other Virtual Machines by cloning the Base Virtual Machine.

Once the base virtual machine is ready, you can clone it to create new virtual machines.
My host Operating System being Windows XP, all virtual machines (guest Operating System) are by default located in My Documents\My Virtual Machines, each virtual machine having its own subfolder.

2.2.1 Cloning the virtual machine.

1. Under My Documents\My Virtual Machines, create a new subfolder with the same name as the new virtual machine you are about to create. For this example let’s call it “VirtualServer2”.
2. Copy the base virtual machine’s virtual hard disk file (.vhd) into that subfolder, rename it to match the cloned virtual machine name (i.e. VirtualServer2.vhd) and remove the read-only attribute on the renamed vhd file.
3. Open the Virtual PC Console and click on “New”.
4. When asked for the name and location of the virtual server, just type in the name of the virtual machine you chose, “VirtualServer2” in our example. The wizard will find the folder you created in step 1 and create a VirtualServer2.vmc file it it.
Vmc files are the file containing the configuration of the Virtual Machine. If you open it using notepad you will see that it is just an XML file.
5. Chose the Operating system “Windows Server 2003” and adjust the memory settings to your preference and click “Next”.
6. When arriving on the “virtual hard disk option”, make sure that the radio button “an existing virtual hard disk” option is selected so that you can select the virtual hard disk you copied in step 2.
Note that you might want to select the option to enable undo disk. With undo disks, at the end of a session, you can chose to either commit the changes you made to the virtual hard disk or cancel the changes. This gives you the possibility to not save the state of your Virtual Machine in case you did something wrong, thus revert back to the state you were when you started that session.
7. When the new Virtual Machine is created, start it and it will receive a unique SID, GUID and other identifiers.

You are now done and can repeat the operation to create other cloned virtual machines.

Final Remarks.
It is also possible to not sysprep the base virtual machine but sysprep all the cloned virtual machine individually instead.
I have read that the fourth time you run Sysprep on the same media, you receive the message, “Your grace period limit has been reached and will not be reset.”. If that occurs you might be able to re-sysprep that machine or to work from a base virtual machine that is not sysprepped yet.