FIX:BizTalk Server Log Shipping fails when the "DaysToKeep" parameter is set to 1 on a BizTalk Server 2006 R2

Consider the following scenario:

• You use BizTalk Server 2006 R2 on a computer that is configured in the "GMT+" time zone. For example, the computer is in GMT+3 time zone.
• You configure BizTalk Server to do BizTalk log shipping by using a destination system.
  
  Note For detail instructions about how to do BizTalk log shipping, refer to the �More Information� section.
• You set the DaysToKeep parameter to 1 in the Clear Backup History step of "Backup BizTalk Server (BizTalkMgmtDb)" SQL Server agent job.

In this scenario, BizTalk log shipping may fail. Additionally, an event message that resembles the following is logged in the Application log on the destination system: When you view the job history for "BTS Server Log Shipping Restore Databases" SQL Server agent job on the destination system, you receive an error message that resembles the following: Note This issue typically occurs when there is a slow network connection. Therefore, the backup operation takes longer to transfer to the destination system.

This issue occurs because the backup history is deleted after 1 day. This happens when the DaysToKeep parameter is set to 1. Therefore, the destination system cannot find logs to restore when the full backup is running at midnight.

The hotfix that resolves this problem is included in cumulative update package 2 (CU2) for BizTalk Server 2006 R2 SP1.

For more information about how to obtain the cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base: For more information about BizTalk Server 2006 R2 SP1 hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:For more information about BizTalk Server hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:

To work around this issue, reset the DaysToKeep parameter value to 2 or more. We recommend that you to keep the default value of 14 because this value is not related to disk space. This value only influences table rows in a history table that may be needed during a longer disaster recovery.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

Important After you apply the CU2, the following changes are made to BizTalk Server.

1. A UseLocalTime parameter is added as an optional parameter in all three steps of the �Backup BizTalk Server (BizTalkMgmtDb)" SQL Server agent job. This parameter should be consistent across all three steps. Valid values are (1,1,1), (0,0,0). The default value on all steps is 0.
   • If UseLocalTime is set to 0, UTC timestamps is used in history and full backup is taken at 12:00AM UTC if backup hour is not specified.
   • If UseLocalTime is set to 1, local timestamps is used in history and full backup is taken at 12:00AM local time if backup hour is not specified.
   • If Backup hour (0 to 23) is specified in first step, full backup is in that particular hour (local time) irrespective of the UseLocalTime setting.
2. When the job is run for the first time, the full backup is taken despite all other settings. The timestamp is local time if UseLocalTime is set to 1 and is UTC if�UseLocalTime is set to 0.
3. History table will contain at least one full backup history and subsequent history log backups irrespective of the�DaysToKeep parameter setting. They will not be deleted until another full backup is taken.

For more information about BizTalk Server log shipping, visit the following Microsoft Developer Network (MSDN) website: For more information about how to configure the backup BizTalk Server job, visit the following MSDN website: For more information about how to configure the destination system for log shipping, visit the following MSDN website: