Redmond Monsoon Season / Some New Directions

I had no idea I’d be celebrating my first day at Microsoft in conjunction with the Redmond monsoon season. The skies were clear, yielding a beautiful sunrise when I left my home early that Monday morning. What kind of fool would carry an umbrella on a day like this?

By the time I reached the Overlake Transit Center, it was raining cats and dogs (in fact, I called home to make sure we could account for our cat and our dog; they were smart: they were inside). However, a simple rain cannot spoil such a red-letter day.

As I’d not written of this before, let me fill you in. While I really had no intention of ever leaving Avanade, I was caught completely off guard by an incredible position offered to me in Redmond. It’s unique, strategic, creative, sales, business and technology-focused, related to finding ways to make Microsoft technology more relevant to companies that don’t consider it their primary platform. In short, I’m a technical evangelist.

With this move, I will also be modifying the direction of this blog. Up to now, this blog has been comprised of “How-To” or problem-solving articles. While I’ve referred to the business case from time to time, I’ve steered pretty clear of discussing business values (i.e., ROI and TCO). I have also kept mum on my views of Services Orientation (formerly known as Services-Oriented Architecture, or SOA).

No more of that. I’ll still be drafting technical articles, but (since I’m paid to do it), I’ll be speaking out more in the realms of integration, services and business issues. I’ll also be covering forward-thinking technologies that I encounter in my new role; edging toward the bleeding edge as appropriate, to help guide your UI and application plans for the future.

Restoring BizTalk Server 2004

Instructions for restoring BizTalk Server 2004. See Backing Up BizTalk Server 2004 for backup instructions.

TEST ON A SAMPLE ENVIRONMENT. Always.

Determine if you’re doing full log restores or restoring to Stop Marks.

Stop the following services:

  • BizTalk Service: BizTalk Group
  • BizTalk SharePoint Messaging Manager
  • Enterprise Single Sign-On Service
  • Rules Update Service

Copy the backup files from the backup folder to your operational folder.

Create a SQL script with these commands (edit database names and paths, as appropriate):

— BizTalk Database Restoration Script
— DatabaseName = the BizTalk Database to restore.
— DB/LogFileName = the BizTalk backup data and log file names.
— StopMark = the BizTalk Stop Mark at which the backup occurred (looks like “BTS_2005_04_01_16_22_29_109“)

RESTORE Database DatabaseName FROM DISK = ‘x:\BizTalkBackupFolder\DBFileName’
WITH NORECOVERY
GO

RESTORE LOG DatabaseName FROM DISK = ‘x:\BizTalkBackupFolder\LogFileName’
WITH NORECOVERY
GO

RESTORE LOG FROM DISK = ‘x:\BizTalkBackupFolder\LogFileName’
WITH RECOVERY,
STOPATMARK = ‘StopMark’
GO

Run the MS SQL Query Analyzer:

  • Connect to the SQL server storing the BizTalk databases (you may need to provide authentication)
  • Open/Paste the script(s) you created above
  • Repeat/script these steps for each of the following databases (default names; modify for your environment):
    • BizTalkDTADb
    • BizTalkMgmtDb
    • BizTalkMsgBoxDb
    • BizTalkRuleEngineDb
    • SSODB
    • TPM

Note errors and take corrective action. Restart services when complete.

Backing up BizTalk Server 2004

Step-by-step reference to backing up BizTalk Server 2004. See Restoring BizTalk Server 2004 for restoration instructions.

Include the SSO Database as part of your backup (recommended):

  • Open SQL Enterprise Manager.
  • Open BizTalkMgmtDB (default name for the BT Management Database) and expand Tables.
  • Right click adm_otherbackupdatabases, click “Open Table” and “Return all rows“.
  • In the Data in Table diaog box add a row with the follwing values:
    • DefaultDatabaseName: SSODB
    • Database Name: SSODB
    • ServerName: (server name)
    • BTSServerName: (server name)
  • Close the Data in Table dialog box.

Alter the SQL Backup job:

  • Open SQL Enterprise Manager
  • Choose server
  • Expand Management, SQL Server Agent and click Jobs
  • Open the Backup BizTalk Server job
  • In the Backup BizTalk Server properties, click the “Steps” tab
  • Click “Backup Full” and click Edit
  • In the “Edit Job Step” dialog box, modify the “<destination path>” string to the path you’d like to save the backup files
  • Make the same path change for the “MarkAndBackupLog” step
  • Click OK to close the Backup properties dialog box and return to SQL Enterprise Manager.

Ensure SQL Server Agent is running with credentials permitting it to write to the folder specified in “destination path”, above.

Testing the backup job:

  • Open SQL Enterprise Manager.
  • Choose server
  • Expand Management, SQL Server Agent and click Jobs
  • Right-click the Backup BizTalk Server job and click “Start Job”
  • In the “Start Job” dialog box, click “Start”
  • Right-click the Backup BizTalk Server job and click “View Job History”

The job should have run successfully, otherwise interpret any error messages (typically invalid path or permissons), resolve and test again.

This process backs up both the data and log files. Running the job a second time should create only a log file as the period for the next database backup should not have been reached (by default, it is set to 15 minutes).

Once you’ve set these jobs up, you will need to manage the files, archiving to another share or deleting on a regular basis.

IIS: Redirect from http to https

I had the need to move access to a site from http to https to accommodate a customer requirement. We had already published the http URL, and wanted to minimize the effect on the customer by redirecting requests to the SSL port.

Once SSL is required to access a web site, accessing the site via port 80 generates a useful error that advises the user to use https instead of http when accessing the site. Confirm you have access to the site over SSL by navigating to it using the https protocol.

To redirect from port 80 to 443, we must create an ASP file that redirects to the same URL over SSL upon the 403.4 (SSL required) error. The redirection file queries the request for Port 80 and reconstructs the URL for access via https. We must also create a virtual directory that points to the original application directory to support redirection.

For the purposes of this example:

  • The original (and newly secure) directory is called ‘AppDirectory’.
  • The redirection file is called ‘AppDirectory_Redirect.asp’.
  • The redirection support directory is called ‘AppDirectory_Redirect’.

First, create the redirection file and save it to ‘AppDirectory’ as ‘AppDirectory_Redirect.asp’. Here is the code:

If Request.ServerVariables("SERVER_PORT")=80 Then
Dim strQUERY_STRING
Dim strSecureURL
Dim strWork

‘ Get server variables
strQUERY_STRING = Request.ServerVariables("QUERY_STRING")

‘ Fix the query string:
strWork = Replace(strQUERY_STRING,"http","https")
strWork = Replace(strWork,"403;","")

‘ Now, set the new, secure URL:
strSecureURL = strWork
‘response.write(strSecureURL) ‘ uncomment for sanity check.
Response.Redirect strSecureURL
End If

In this example, do not change “SERVER_PORT” or “SERVER_NAME” as they’re the hard-coded names of the server variables.

In IIS, use the virtual directory creation wizard to create the redirect virtual directory ‘AppDirectory_Redirect’, pointing to ‘AppDirectory’ as the physical path. Leave the access permissions as Read.

In IIS, right click the original application directory ‘AppDirectory’ and click properties. Follow these steps:

  • Click the ‘Custom Errors’ tab and double-click 403.4.
  • In the ‘Message Type’ box, click URL.
  • In the URL box, type ‘/AppDirectory_Redirect/AppDirectory_Redirect.asp’ (redirecting to the redirect file you created earlier).
  • Click the ‘Directory Security’ tab.
  • Under secure Communications, click ‘Edit’.
  • Select ‘Require secure channel (SSL). Set 128-bit encryption as appropriate for your certificate.
  • Click ‘OK’ until your changes are saved.
  • Restart IIS Admin.

Note: you can always restore the original 403.4 error message by clicking ‘Set to Default’

Test the site by navigating to ‘http://AppDirectory&#8217;; you should be redirected to the site over https.

Failed to deploy system assembly .." Microsoft.BizTalk.GlobalPropertySchemas.dll"

This may occur when applying a BizTalk configuration file in silent or interactive mode. The full error (from the log in silent) is:

Failed to deploy system assembly "C:\Program Files\Microsoft BizTalk Server 2004\Microsoft.BizTalk.GlobalPropertySchemas.dll".

The rest of the error message is informative as well; giving you a hint on where to go:

“The network clients for the Distributed Transaction Coordinator (DTC) Network must have the remote clients/transactions option enabled. The partner transaction manager has disabled its support for remote/network transactions.”

This is a DTC issue; in this case, DTC isn’t properly configured on a non-local SQL Server. Help and troubleshooting will give you a text string containing “You must enable network clients DTC access before configuring BizTalk Server“. Check your installation steps and ensure you:

  • On the SQL Server, navigate to Component Services, Computers.
  • Right-click the My Computer icon and select Properties, MSDTC.
  • Click Security Configuration, Network DTC Access.
  • Ensure Network Clients is selected.

To save time, perform / confirm these steps on the BizTalk server as well. Failing to do so will generate a different error (which I’ll publish when I see it), but you may as well perform the steps on both servers at the same time to cover all bases.

Enabling DTC and BizTalk Server 2004

I’m sure I’ve written about this; at the least, it’s in my install documentation (see my reference posts category) and also the Official Microsoft BizTalk Installation documentation.

When firing BizTalk up pointing to a non-local SQL Server, you might see the following error: "The transaction manager is not available".

I’m careful to point out you must set client network access for DTC in my installation documentation. I also found reference to a MS article titled “How to enable network DTC access in Windows Server 2003“. Be sure to restart DTC when you’ve finished the configuration steps.

I located a link to “How To Use DTCTester Tool“, which contains a DTC Test application and instructions on how to set it up to test your DTC installation is configured correctly.

Windows Server 2003 SP1 invited the Windows Firewall into the mix, so configuring network DTC is all the more important on both the BizTalk and MSSQL servers. I have a few details which I’ll provide later, but here are two MSDN articles that helped me:

How to adjust the MSDTC settings
MSDTC Changes in Windows 2003 SP1

Newly-Promoted Master Secret Server (MSS) Hangs BizTalk Administration Console MMC

If you promoted a member server to the MSS role (see “Promote a group member to Master Secret Server“), you might observe the BizTalk Administration console MMC hanging on startup.

Most common cause is a setting in the General Tab in the BizTalk Group of the BizTalk Administration Console. The "Enterprise Single Sign-On server name" parameter is probably pointing to the old MSS server. Modify this to the new MSS name, restart the BizTalk group and the problem should go away.

MS also has instructions for “Changing the Master Secret Server“; again, promoting a group server to the MSS.

BizTalk Server 2004 Configuration Failures – Difficult

I started this post to list suspect issues that may impact loading a BizTalk configuration (i.e., running configframework.exe in either a silent or interactive mode). I’m now splitting it into separate posts (simple, medium, difficult). I am not trying to offer specific solutions to all failures in this post, although I do provide some suggestions and pointers to solutions where I’ve seen these issues. This really is a collection of things you can confirm during the configuration steps.

The application of a BizTalk configuration file can be your delight or downfall, and differs for most every environment in which I’ve installed. Kudos to the big brains at MS for spending their resources on all that’s great about BizTalk; I’m confident they’ll come around to my wish list of easier/faster/better configuration options.

So, that said, let’s look at what makes a configuration fail, from the ‘difficult’ perspective (note: these are from a multi-server deployment on a domain; some items will not apply to single-server deployments).

Difficult (cannot remove present configuration, or configuration times out):

SQL Connection loss during configuration (has the result of putting the server in a half-configured state):
Look to network or security errors. If you see SSPI errors, confirm your SQL installation. I saw this on a SQL server that had been renamed after SQL installation and a second time on a server that had lost its SID context.

WMI recycle failure
Some services may refuse to stop and prevent WMI from recycling during configuration; the configuration times out and the process must be killed. I saw this error during a BRE configuration step, with the following entries in the ConfigFramework log:

[3:38:59 PM Error RuleEngineConfig] c:\depot4000\jupiter\source\private\mozart\source\engine\rules\configfwkext\extension\ruleengineconfig.cpp(1392): FAILED hr = 80041013
[3:38:59 PM Error RuleEngineConfig] Provider load failure
[3:38:59 PM Info RuleEngineConfig] Leaving function: CRuleEngineConfig::GetFeatureConfig
[3:39:05 PM Info ConfigFramework] Showing MessageBox with text: Failed to load configuration data

You might see the string "WBEM_E_PROVIDER_LOAD_FAILURE"

For this, look carefully at the list of services in the Services window. Specifically, look for hardware and systems management tools (MS Systems Management Server, management tools from HP, Compaq and Dell). It is possible these services aren’t stopping at the request of ConfigFramework, causing it to fail).

When configuration must be terminated, the server is in a non-configured state; cannot be un-configured or configured. See the post titled “When Good Configurations go Bad“ for the fix to this state, then restore the server to vanilla. Confirm SQL connectivity and do test recycles of WMI-related services with the account under which you’re installing; some environments have a Group Policy (GPO) to prevent local administrators from managing services (ceding this responsibility to domain admins).

I am keen to receive any feedback and other posts. Please submit comments.

SSO and BizTalk Server 2004 Services Fail Post-XPSP2 (KB841893)

If you’re running Biztalk Server 2004 on Windows XP (I recommend running in a VPC or Virtual Server on 2003), you will likely encounter errors after applying XPSP2 and/or enabling XP security services.

ConfigFramework may generate this error:

Failed to generate the master secret (error code 0x800706BF)

Upon starting the SSO service, the event log will report this error:

Event Type: Error
Event Source: ENTSSO
Event Category: Enterprise Single Sign-On
Event ID: 10555
Computer: BIZTALKSERVER
Description: Secret server access denied. Client User: Domain\UserName

Note: Any component that tries to access the ENTSSO or BizTalk Server runtime services will get an "Access denied" error message, but no error written to the BizTalk Server event log.

This happens because the Remote Procedure Call (RPC) protocol is different post-SP2.

Microsoft issued a KB article “The Enterprise Single Sign-On Service and associated BizTalk Server 2004 services fail after you install Windows XP Service Pack 2 (SP2)” that addresses and resolves this issue.

BizTalk Server 2004 Backup Procedures

About BizTalk Server 2004 database backup and recovery

BizTalk Server 2004 Database Write Diagram

User Accounts for BizTalk Server 2004 Database Backups

BizTalk Server 2004: Marking Transactions, Full Backups and Log Backups