Pro BizTalk 2006 phần 8 docx

• Rule Engine (BizTalkRuleEngineDb) • BAM Primary Import (BAMPrimaryImport) • Trading Partner Management (TPM) • HWS Administration (BizTalkHWSDb) • BizTalk EDI (BizTalkEDIdb) These databases must be backed up by the Backup BizTalk Server SQL Agent job and cannot be backed up using the normal SQL Server backup procedures. The reason is because BizTalk uses SQL Server log marks to keep the set of databases consistent as part of DTC trans- actions. The Backup BizTalk Server job creates a log mark and then backs up the database log for each database that is part of the Backup BizTalk Server SQL Agent job. This log mark is used when restoring the last log file for each database so that transactional consistency is main- tained. Here are the steps to configure the Backup BizTalk Server SQL Agent job: 1. In SQL Server 2000 Enterprise Manager or SQL Server 2005 Management Studio, navi- gate to the SQL Agent jobs list. 2. Right-click Backup BizTalk Server (BizTalkMqmtDb) and select Properties. 3. In the Job Properties dialog under Select a page, click Steps to view the job steps. 4. In the Job step list, click BackupFull, and then click Edit. 5. On the General page, in the Command box, replace ‘<destination path>’ with the full path (the path must include the single quotes) to the computer and folder where you want to back up the BizTalk Server databases. Also add a new parameter by typing a comma and then a number one (“,1”) at the end of the parameter list for the stored procedure sp_BackupAllFull. Adding this parameter enables an automatic full backup after a backup failure. Click OK when finished. ■Note The default frequency for the BackupFull job is d for daily. Other values are hourly (h/H), weekly (w/W), monthly (m/M), or yearly (y/Y). The first time the job is run during a new period, a full backup is per- formed. Also, the default name is BTS, which will be part of the backup file name. Change this to reflect a better name for the a pplica tion such as OrdSys for an a pplication named Order System. 6. I n the Job step list, click MarkAndBackupLog, and then click Edit. 7. On the General page, in the Command box, replace ‘<destination path>’ with the full path (including single quotes) to the computer and folder wher e y ou want to store the B izT alk Serv er database logs and then click OK. The <destination path> may be local or a UNC path to another server. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS 339 6994ch09final.qxd 10/2/06 12:36 AM Page 339 ■Note We recommend a UNC share to store the backup files on a different file system than where the databases reside for production environments. For a dev or test environment, if you are not concerned with maintaining offsite backup sets or multiple backup sets, you can consider using a local path instead of a UNC path. Also, for the job step MarkAndBackupLog, Log Mark Name is part of the naming conven- tion for backup files: <Server Name>_<Database Name>_Log_< Log Mark Name >_<Timestamp> Replace "BTS' with a more appropriate name for the solution. 8. In the Job step list, click Clear Backup History, and then click Edit. 9. On the General page, in the Command box, change DaysToKeep=<number> to the number of days (default is 14) you want to keep the backup history, and then click OK twice to close the Job Properties dialog box. ■Note The DaysToKeep setting is not related to how many sets of backup files are maintained. Backup file sets must be handled manually by copying to another system for long-term archival. Change the backup schedule for MarkAndBackupLogSched if desired and then right-click the Backup BizTalk Server SQL Agent job and select Enable. The default schedule is to perform a log backup every 15 minutes. Once the Backup BizTalk Server job is configured and enabled, right-click and select Start Job to test. Click F5 to refresh the status on the Jobs node. If the result is not successful, check the following: • Verify that the destination folder exists and is reachable if a UNC share. • Check that the job owner has permissions on the destination folder. • Ensure that linked servers are configured properly if BizTalk databases are present in multiple SQL Ser ver database instances. ■Tip For SQL Server 2005, there are additional security settings for linked servers. When configuring linked servers in SQL Server 2005 as part of the Backup BizTalk Server SQL Agent job, click the Security tab and select the “Be made using the login’s current security context” option. Next click Server Options, set RPC Out to True, and then click OK. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS340 6994ch09final.qxd 10/2/06 12:36 AM Page 340 Be aware that the file name includes the date/time from when the backup file was cre- ated. This date/time is GMT time, not local time. If you look at the Date Modified field in Windows Explorer, you will see the local time. Also, the Backup BizTalk Server SQL Agent job does not manage disk space, meaning it will continue to copy files into the same directory until the drive runs out of space. This allows the administrator to decide how many backup sets to keep on disk as well as how many to archive to an offsite location, deleting the files from disk after archival. The next subsection covers how to configure the DTA Purge and Archive SQL Agent job. Configuring the DTA Purge and Archive SQL Agent Job With companies having to comply with IRS, general accounting, and legislative requirements for business reporting, BizTalk Server provides extensive tracking capabilities to help with complying with these mandates. This data must be kept for various periods of time to meet reporting requirements. BizTalk Server 2006 adds the DTA Purge and Archive job to help auto- mate the backup of tracking data including the ability to perform on-the-fly validation of tracking data backups using another instance of SQL Server to ensure that a complete record of activity is maintained and available. In addition to providing data archival, the DTA Purge and Archive SQL Agent job per- forms data pruning to help keep the system running smoothly. As with any database system, unchecked growth in table size will eventually push the limits of the hardware. In general, there are two solutions to this problem, buy more disks or a faster disk or have a purge and archival policy to “prune” the databases where it makes sense. While all database-based sys- tems benefit from more and faster disks, BizTalk has a process to keep the BizTalk Tracking and Messagebox databases performing optimally by automating purging and archival tasks through the DTA Purge and Archive SQL Agent job. The DTA Purge and Archive job purges various tracking information such as service instance and message information, orchestration event information, and rule engine tracking data. The purge process is based on the age of the tracking data, which is maintained by hav- ing a time stamp added when tracking information is inserted into the database. The DTA Purge and Archive job has a soft purge and hard purge process. The soft purge processes completed instances, while the hard purge processes incomplete instances. Note that both soft purge and hard purge process just the tracking data, not the actual running instances, so they hav e no effect on actual data processing data. The purge process helps to optimize track- ing processes and HAT operations when looking at historical data. Here are the steps to con- figure the DTA Purge and Archive SQL Agent job: 1. Depending on whether you are on SQL Server 2000 or SQL Server 2005, navigate to the Management node and view the SQL Agent jobs. 2. In the details pane, right-click DTA Purge and Archive (BizTalkDTADb), and then click P r operties. 3. In the Job Properties dialog box, click the Steps tab, click Archive and Purge, and then click E dit. 4. On the General tab, in the Command box, edit the following parameters as appropri- ate, and then click OK. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS 341 6994ch09final.qxd 10/2/06 12:36 AM Page 341 ■Note For the soft purge, the sum of LiveHours and LiveDays is the live window of data that will be main- tained for the BizTalk Tracking database. All tracking data associated with completed instances older than the live window will be deleted and archived. • @nLiveHours tinyint: Default is 0 hours. • @nLiveDays tinyint: Default is 1 day. • @nHardDeleteDays tinyint: Default is 30 days. • @nvcFolder nvarchar(1024): Specify the folder or UNC share to put the tracking data backup files. • @nvcValidatingServer: SQL Server instance where validation is performed. Default is null. • @fForceBackup int: Default is 0. This is not currently implemented. Here is an example command that specifies that soft purge occurs every 12 hours and hard purge occurs every 7 days: exec dtasp_BackupAndPurgeTrackingDatabase 12, 0, 7, '\\BizTalkBackupServer\data', null, 0 In the preceding example, we left the validation server value as null; however, we recom- mend that you set up a validation server for the tracking data to ensure that the backup files of the tracking data for reporting and compliance purposes are valid. Also, the data can be queried on the validation server, offloading potentially long-running queries from the produc- tion BizTalk databases. To configure a validation server for the DTA Purge and Archive SQL Agent job, you must have a separate instance of SQL Server available. Having a validation server requires that the @nvcFolder variable in the DTA Purge and Archive job points to a UNC share reachable by the validation server. The SQL Server instance where the BizTalk databases are configured cannot also act as the validating server. On the server designated as the valida- tion server, perform these steps: 1. In either ISQL on SQL Server 2000 or in SQL Management Studio on SQL Server 2005, open a file to execute a SQL file. Connect to the SQL instance that is the validation server. 2. S elect F ile ➤ O pen and then br owse to this SQL script on the server/drive where B izT alk S er v er 2006 is installed: \Program Files\Microsoft BizTalk Server 2006\ Schema\BTS_Tracking_ValidateArchive.sql. 3. Execute the query to create a SQL Agent job called ValidateArchive on the validating server. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS342 6994ch09final.qxd 10/2/06 12:36 AM Page 342 4. Open either Enterprise Manager for SQL Server 2000 or SQL Management Studio for SQL Server 2005 to set up the required linked servers. Linked servers must be created between the following: • Each of the BizTalk Messagebox (BizTalkMsgBoxDB) SQL Server instances and the B izTalk Tracking (BizTalkDTADb) SQL Server instances. The SQL instance hosting the DTA database requires a linked server to each SQL instance hosting a BizTalk Messagebox and vice versa. • The BizTalk Tracking (BizTalkDTADb) SQL Server instance and the validating server SQL Server instance. Create a linked server on each SQL instance to the other SQL instance so that the SQL instance hosting the DTA database has a linked server to the validating server and vice versa. Next, we turn our attention to monitoring best practices for the SQL Agent jobs. Monitoring the BizTalk Group SQL Agent Jobs Because the SQL Agent jobs are critical to maintaining BizTalk performance, the jobs must be monitored so that operations personnel can be alerted if a job fails. The Microsoft SQL Server Management Pack contains MOM rules for monitoring SQL databases, SQL Server Agent jobs, etc., for comprehensive monitoring of SQL Server items. The BizTalk Server 2006 Management Pack for Microsoft Operations Manager 2005 includes two rules, disabled by default, for moni- toring the health of two of the most important BizTalk SQL Server Agent jobs. The rule names as defined in the Management Pack are • Critical Error: A BizTalk SQL Server Agent job failed—Backup BizTalk Server • Critical Error: A BizTalk SQL Server Agent job failed—Tracked Message Copy To monitor all BizTalk Server SQL Server Agent jobs from within the BizTalk Server 2006 Management Pack, enable these rules and create additional rules for other jobs that you want to monitor. To enable these rules, perform the following steps in the MOM Administrator Console: 1. Create a copy of the two rules just listed in the BizTalk Server Core Rule group and rename each rule appropriately. 2. In the criteria section for the MOM rule, change the wildcard comparison for Parame- ter 1 because the job names ar e specific to the BizT alk Group configuration. You need to add the SQL Server computers into the BizTalk Server 2006 Computer Group in MOM. This is because the MOM rule needs to be ev aluated on the SQL Server computer, and the SQL Server computer will not be recognized as a BizTalk Server computer unless BizTalk and SQL Server happen to be installed on the same machine. Backup P rocedures This subsection covers the backup procedures for BizTalk applications; however, a BizTalk application is usually just one part of an overall solution that includes other applications, CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS 343 6994ch09final.qxd 10/2/06 12:36 AM Page 343 servers, and databases. In general, backup of an application solution that includes BizTalk requires the following general procedures: • Back up application code, artifacts, documentation. • Back up server configuration documentation. • Back up BizTalk servers and BizTalk Group databases. • Back up related non-BizTalk databases. Steps and procedures for backing up the first two items listed are outside the scope of this chapter; however in general, application code, artifacts, code documentation, and server con- figuration documentation should be kept in a source code control system that is backed up automatically with rotating backup sets maintained at an offsite location. The following subsections focus on the last two items listed including backup procedures for BizTalk runtime servers and for the BizTalk Group. BizTalk Servers The servers where BizTalk is installed and configured should be backed up using your corpo- rate standards for server backup. In addition, the config.xml file used to configure each server should be backed up along with documentation on what host instances, receive ports, and send ports are installed on the server. This information can be stored in your source code con- trol system as solution artifacts. Essentially the procedures used to perform the following steps must be in a format that administrators can use to perform a restore or disaster recovery event: • BizTalk installation: Document what features/service pack/hotfixes are installed on the BizTalk runtime server. Document what other products such as SharePoint, IIS, or third-party adapters are installed. • BizTalk configuration: Back up the config.xml that was used to configure the server. This file can be reused to configure the server with minor edits depending on whether the BizTalk Windows server name changed or the SQL instance location of the data- bases has changed. • Master secret: This is an extremely important backup item that is covered later in this chapter. Without the master secret, a BizTalk Group cannot be restored. The master secr et is encrypted and stor ed in the registry of the master secret server. It is required in order to access the cr edential (SSOdb) database . • B izTalk application configuration : Document host instances , r eceiv e ports, send ports, and of course versions of BizTalk application binaries. Maintaining the preceding documentation is the minimum requirement necessary to restore the BizTalk runtime servers. It is recommended to automate installation, configura- tion, and application deployment as much as possible to support normal operations as well as to provide an automated method to restore the BizTalk runtime servers. The next subsection covers procedures for backing up the master secret. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS344 6994ch09final.qxd 10/2/06 12:36 AM Page 344 The Master Secret BizTalk Server 2006 includes a new Microsoft Management Console (MMC) snap-in for man- aging Enterprise SSO and the master secret, as shown in Figure 9-2. To launch the SSO Admin- istration tool, go to Start ➤ All Programs ➤ Microsoft Enterprise Single Sign-On ➤ SSO Administration. To back up the master secret, right-click the System node and select Backup Secret within the GUI. Clicking Backup Secret displays the dialog box shown in Figure 9-3, where you enter a location for the backup file, a password, and optionally a password reminder. This file should be removed from the server and stored in a safe place such as a source control system locally as well as at an offsite location. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS 345 Figure 9-2. SSO Administration MMC console Figure 9-3. B ackup S ecr et dialog 6994ch09final.qxd 10/2/06 12:36 AM Page 345 The Enterprise SSO tools SSOManage.exe and SSOConfig.exe are still available in the C:\Program Files\Common Files\Enterprise Single Sign-On directory to support scripting, so the master secret can be backed up using the command-line tool SSOConfig.exe with the –backupSecret switch as well. Next, we cover procedures for backing up the BizTalk Group. BizTalk Group This subsection covers backup procedures for the BizTalk Group, which consists of a set of databases created by BizTalk Server 2006 during configuration. All of the normal requirements when performing SQL backups apply: allocating sufficient storage space where backup files are stored, copying backup files to an offsite location, testing restore files on a regular basis such as monthly, etc. Another consideration is to ensure backup devices and media are secure to protect business-sensitive data. ■Note BizTalk Server includes a SQL Server role named BTS_BACKUP_USERS so that BizTalk databases can be backed up without requiring System Administrator permissions within SQL Server, except for the primary server controlling the backup process. If not done already, configure the Backup BizTalk Server SQL Agent job following the instructions in the earlier subsection titled “Configuring the Backup BizTalk Server SQL Agent Job.” The Backup BizTalk Server SQL Agent job backs up the following databases: • BizTalk Configuration (BizTalkMgmtDb) • BizTalk Messagebox (BizTalkMsgBoxDb) • BizTalk Tracking (BizTalkDTADb) • Rule Engine (BizTalkRuleEngineDb) • BAM Primary Import (BAMPrimaryImport) • Trading Partner Management (TPM) • HWS A dministration (B izT alkHWSDb) • B izT alk EDI (BizTalkEDIdb) • Credential Database (SSOdb) You must also back up the following BizTalk Group databases, which are not part of the B ackup BizTalk Server SQL Agent job because they do not participate in DTC transactions: • BAM Archive (BAMArchive) • BAM Star Schema (BAMStarSchema) CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS346 6994ch09final.qxd 10/2/06 12:36 AM Page 346 These databases can be backed up using normal SQL Server backup procedures because they do not participate in distributed transactions; however, these databases require special consideration, described in the next subsection, if BAM is configured with BM.exe and used as part of a BizTalk solution. BizTalk Server 2006 includes a table named adm_OtherBackupDatabases in the BizTalk Management database (BizTalkMgmtDb). Other application databases that participate in DTC transactions (i.e., accessed within an atomic scope in an orchestration) should be added to adm_OtherBackupDatabases to remain transactionally consistent with the BizTalk databases. Table 9-2 lists the column names. Table 9-2. Columns in the adm_OtherBackupDatabases Table Field Name Value DefaultDatabaseName The alias for the database . Can be the same as the database name or the application name. DatabaseName The actual name of the database. ServerName The name of the SQL Server instance hosting the database. BTSServerName Name of a BizTalk server. Not used, but required. Databases added to the adm_OtherBackupDatabases table will automatically be backed up by the Backup BizTalk Server SQL Agent job. ■Caution You must add any non-BizTalk custom database that performs distributed transactions with BizTalk to this table so that the table can be restored to the same log mark and remain transactionally con- sistent. For example, if you have an orchestration that updates a database named App1 within an atomic scope in BizTalk, the database App1 must be added to the adm_OtherBackupDatabases table. The next step is to add the necessary schema changes to the databases added to the adm_O therBackupDatabases table. Otherwise, the Backup BizTalk Server SQL Agent job will fail. Browse to the <installation directory>\Program Files\Microsoft BizTalk Server 2006\ Schema directory, and then run Backup_Setup_All_Procs.sql and Backup_Setup_All_ T ables.sql in the destination database . This creates the necessary procedures, tables, and roles to participate in the Backup BizTalk Server SQL Agent job and assigns permissions to the stored procedures. N o w let ’ s take a look at backup procedures for the SQL Server Analysis Services databases. BAM Analysis Services and Supporting Databases B izT alk leverages SQL S erver Analysis Services for reporting and analysis functionality as part of the Health and Activity Tracking and Business Activity Monitoring features. In BizTalk Server 2006, the Tracking Analysis Server OLAP database is available in BizTalk installations as part of HA T to suppor t the ser vice metr ics and message metrics functionality for SQL Server CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS 347 6994ch09final.qxd 10/2/06 12:36 AM Page 347 2000 Analysis Services only. The Tracking Analysis Server database is not supported on SQL Server 2005 Analysis Services and is not available as an option when configuring the BizTalk Group with a SQL Server 2005 database back end. A BizTalk Group configured with BAM enabled in the BizTalk Configuration Wizard results in two additional SQL Analysis Services OLAP databases if the Tracking Analysis Server data- base is present: • BAM Analysis (BAMAnalysis) • Tracking Analysis Server (BizTalkAnalysisdb) These Analysis Services databases must be backed up following the procedures for back- ing up SQL Analysis Services databases. There are two scenarios for backing up BAM SQL Server databases when BAM is enabled through the BizTalk Configuration Wizard: • BAM enabled for the BizTalk Group but not configured • BAM enabled and configured with BM.exe (i.e., the BizTalk solution includes BAM features) The next two subsections cover these scenarios. BAM Enabled but Not Configured in a BizTalk Group Since BAM is not configured with BM.exe, there are not any BAM-related Data Transformation Services (DTS) packages present in the solution. Therefore, the BAM SQL databases can be backed up using regular SQL Server backup procedures or can be added to the Backup BizTalk Server SQL Agent job by adding the table to the adm_OtherBackupDatabases table for con- venience. Here is a list of the BAM SQL databases that must be backed up: • BAM Archive (BAMArchive) • BAM Star Schema (BAMStarSchema) This will ensure that a full set of databases for the BizTalk Group are maintained. The next subsection covers backup procedures when BAM is enabled and configured with BM.exe. BAM Enabled and Configured in a BizTalk Group When BAM is enabled and configured for a BizTalk Group using BM.exe, it results in the cre- ation of one or more DTS packages that must be backed up in case they are accidentally deleted as well as duplicated on the disaster recovery site. (Disaster recovery is covered in its own section later in this chapter.) Backup procedures for DTS packages are documented in SQL Server Books Online. B efore backing up the BAM databases, ensure that neither the BAM cube process nor data maintenance DTS packages are running when the backup package is scheduled to run. Ensure consistent schema across all BAM databases by backing up the BAM databases and DTS packages each time a BAM activity is deployed and not deployed. CHAPTER 9 ■ BIZTALK SERVER 2006 OPERATIONS348 6994ch09final.qxd 10/2/06 12:36 AM Page 348 [...]... requirements include the following: • BizTalk Server 2006 Log Shipping configuration for disaster recovery • BizTalk Server 2006 Log Shipping procedures for restoring the BizTalk Group as part of disaster recovery • BizTalk runtime environment disaster recovery procedures These items make up the core disaster recovery requirements for BizTalk Server 2006 Additional disaster recovery procedures are required for... out the procedures not found in the BizTalk Server 2006 core documentation s Caution The steps to manually update the required database fields in order to move a BizTalk Group to a new set of database server instances without using BizTalk Log Shipping are not documented for BizTalk Server 2006 Therefore we strongly recommend configuring BizTalk Log Shipping as part of any BizTalk Server 2006 production... at how BizTalk Log Shipping works How Does BizTalk Log Shipping Work? Because BizTalk Server 2006 implements distributed transactions between BizTalk databases in the BizTalk Group through log marks, typical SQL Server disaster recovery technology such as SQL Server Log Shipping cannot be used for BizTalk databases that participate in DTC transactions Therefore, BizTalk Server 2006 provides BizTalk. .. MessageBox_Message_Cleanup_ by mistake It is always disabled by default 6994ch09final.qxd 10/2/06 12:36 AM Page 359 CHAPTER 9 s BIZTALK SERVER 2006 OPERATIONS • Backup BizTalk Server (BizTalkMgmtDb) • CleanupBTFExpiredEntriesJob_ • DTA Purge and Archive (BizTalkMsgBoxDb) • MessageBox_DeadProcesses_Cleanup_ • MessageBox_Message_ManageRefCountLog_... Archive (BizTalkMsgBoxDb) • MessageBox_DeadProcesses_Cleanup_ • MessageBox_Message_ManageRefCountLog_ • MessageBox_Parts_Cleanup_ • MessageBox_UpdateStats_ • Operations_OperateOnInstances_OnMaster_ • PurgeSubscriptionsJob_ • Rules_Database_Cleanup • TrackedMessages_Copy_... UpdateDatabase.vbs script from a 64-bit command prompt As promised, we next cover the disaster recovery procedures for the BizTalk runtime servers Later subsections cover disaster recovery procedures for BAM, BAS, and EDI functionality BizTalk Runtime Server Disaster Recovery Procedures The BizTalk runtime servers in the destination system should have BizTalk Server 2006 as well as any required third-party... CHAPTER 9 s BIZTALK SERVER 2006 OPERATIONS 6 On each BizTalk server, open the BizTalk Server Administration Console, right-click BizTalk Group, and select Remove 7 Right-click BizTalk Server 2006 Administration, select Connect to Existing Group, select the SQL Server database instance and database name that corresponds to the BizTalk Management database for the BizTalk Group, and click OK 8 Restore the... to the procedures for restoring the BizTalk runtime environment BizTalk Runtime Environment If the BizTalk runtime environment is intact, then restoring the BizTalk runtime environment is a matter of verifying connectivity by opening the BizTalk Administration Console and then restarting processing by starting the items stopped in the subsection titled “Stopping and Starting BizTalk Application Processing”... software installed using the same guidelines for the production BizTalk runtime servers There are generally two methods for setting up the BizTalk runtime servers: • Method one: Restore BizTalk Group, and then configure BizTalk servers in BizTalk Group and deploy applications • Method two: Configure disaster recovery BizTalk servers in production BizTalk Group, disable services, keep server up to date,... Microsoft BizTalk Server 2006 may actually be located in the Microsoft BizTalk Server 2004 directory if an in-place upgrade was performed Once verification is completed, perform these steps: 1 Copy the edited SampleUpdateInfo.xml file to the \Program Files\Microsoft BizTalk Server 2006\ Schema\Restore directory on every BizTalk server in the destination system 2 On each BizTalk Server, open a command prompt . cover procedures for backing up the BizTalk Group. BizTalk Group This subsection covers backup procedures for the BizTalk Group, which consists of a set of databases created by BizTalk Server 2006. Agent Job.” The Backup BizTalk Server SQL Agent job backs up the following databases: • BizTalk Configuration (BizTalkMgmtDb) • BizTalk Messagebox (BizTalkMsgBoxDb) • BizTalk Tracking (BizTalkDTADb) •. DataMicrosoft BizTalk Server 2006 EDISubsystem. ■Note Path references to BizTalk Server 2006 may actually be in the BizTalk Server 2004 directory if an in-place upgrade was performed when BizTalk