You may experience one or more of the following problems when you try to back up your Microsoft Exchange 2000 Server Information Store database or your Microsoft SharePoint Portal Server 2001 Information Store database:

• When you try to back up your SharePoint Portal Server Information Store database, the backup is unsuccessful. One or both of the following events are listed in the Application log for Event Viewer:
  
  

  Date:     date        Source:   ESE98
  Time:     time        Category: Logging/Recovery
  Type:     Error       Event ID: 215
  User:     N/A
  Computer: Servername
  
  Description:
  Information Store (2404) The instance SharePoint Portal Server Group 
  has stopped backup because it was halted by the client or the 
  connection with the client failed.

  
  
  

  Date:     date        Source:   ESE98
  Time:     time        Category: Logging/Recovery
  Type:     Error       Event ID: 478
  User:     N/A
  Computer: Servername
  
  Description:
  Information Store (1140) The streaming page read from the file
  "E:\Sharepoint Portal Server\Data\Web Storage System\wss.stm"
  at offset 356417536 (0x00000000153e8000) for 4096 (0x00001000) bytes 
  failed verification due to a page checksum mismatch. 
  The expected checksum was 4272646636 (0xfeab69ec) and the 
  actual checksum was 2532574806 (0x96f40656). 
  The read operation will fail with error -613 (0xfffffd9b). 
  If this condition persists then please restore the database from a previous backup.

• When you try to back up your Exchange 2000 Server Information Store database, the backup is unsuccessful. One or more of the following events are listed in the Application log for Event Viewer:
  
  

  Date:     date        Source:   ESE
  Time:     time        Category: Logging/Recovery
  Type:     Error       Event ID: 215
  User:     N/A
  Computer: Servername
  
  Description:
  Information Store (3732) 23aca049-4dfa-4e45-b2f8-64c5414a947a: 
  The backup has been stopped because it was halted by the client 
  or the connection with the client failed.

  
  
  

  Date:     date        Source:   ESE
  Time:     time        Category: Database Corruption
  Type:     Error       Event ID: 447
  User:     N/A
  Computer: Servername
  
  Description:
  Information Store (3732) 23aca049-4dfa-4e45-b2f8-64c5414a947a: 
  The backup has been stopped because it was halted by the client 
  or the connection with the client failed.

  
  
  

  Date:     date        Source:   ESE
  Time:     time        Category: (3)
  Type:     Error       Event ID: 448
  User:     N/A
  Computer: Servername
  
  Description:
  Information Store (3752) The streaming page read from the file "F:\Program 
  Files\Exchsrvr\mdbdata\Executives.stm" at offset 52408320 (0x00000000031fb000) for 
  4096 (0x00001000) bytes failed verification due to a page checksum mismatch.  The 
  expected checksum was 3750803089 (0xdf90b691) and the actual checksum was 
  2716766160 (0xa1ee8fd0).  The read operation will fail with error -613 
  (0xfffffd9b).  If this condition persists then please restore the database from a 
  previous backup. 

• When you try to back up the information store on an active or on a passive Cluster service by using Veritas Netbackup, the backup is unsuccessful. A status code of 1 is returned. This status code means "partial success." You receive the following error message:

  081701.LOG:08/17/01 11:52:23 PM: [6652]: ERR - XCHG_BackupRead() FS_ReadObj()
  Failed! 0xFFFFFE30:FS_COMM_FAILURE 081701.LOG:08/17/01 11:52:23 PM: [6652]: 
  ERR - failure reading Exchange 2000 object: Microsoft Information 
  Store:\S2-SG1\S2-SG1-MS5-Std (0xFFFFFE30:FS_COMM_FAILURE)

• When you try to back up a remote information store by using Veritas Netbackup, the backup is unsuccessful. There are no events that are listed in the Application log that indicate a problem. However, the Veritas Netbackup log contains error information that is similar to the following:

  Unable to attach to \\Servername\Microsoft Information Store\First Storage
  Group.
  
  The item was not found.
  
  

These problems can occur for one or more of the following reasons:

• There is a problem with the hard disk or with the hard disk controller.
• There is a problem or an incompatibility with the back-up program.
• There is a problem or an incompatibility with an installed third-party event sink.
• The information store database is damaged or corrupted.
  
  In certain database operations, including, but not limited to online backup, the back-up routine makes a call to the operating system. This call is made to read a 4 kilobyte (KB) page of data from the database on the disk and then write the data to tape. Before the online backup process writes the data that is returned from the operating system call to tape, the online backup process reads the checksum value in the page header. The checksum value in the page header is recorded when this page is written to disk. The online backup process compares the checksum value in the page header to the value that is returned from the READ call. If the checksum values do not match, the Microsoft Jet Database Engine returns error -613.
  
  The checksum error occurs in an SLV file during backup. SLV means a streaming file or an .stm file. Error "-613, JET_errSLVReadVerifyFailure" is similar to error "-1018, JET_errReadVerifyFailure." Exchange Server 2000 logs error "-613" for checksum errors on the .stm database file. Exchange Server 2000 logs error "-1018" for checksum errors on the .edb database file.
  
  For additional information about the underlying cause of these errors, click the following article number to view the article in the Microsoft Knowledge Base:
  314917  (http://kbalertz.com/Feedback.aspx?kbNumber=314917/ ) Understanding and analyzing -1018, -1019, and -1022 Exchange database errors

To resolve this problem, follow these steps:

Troubleshoot hardware problems

1. View the System log to determine whether disk I/O errors are listed.
2. Obtain available firmware updates or driver updates for your hard disk drive controllers.
3. Run the Chkdsk utility to determine whether a problem exists with the hard disk drives.

Troubleshoot your back-up program

1. Try to back up the information store by using the Microsoft Windows NTBackup program that is included with Microsoft Windows 2000.
   
   If you can successfully back up the information store by using the Windows NTBackup program, this may indicate that a problem exists with your back-up program.
2. Contact the manufacturer of your back-up program to obtain updates or patches that may help resolve this problem.
   
   For information about how to contact your computer manufacturer, visit the following Web site:
   http://support.microsoft.com/gp/vendors/en-us (http://support.microsoft.com/gp/vendors/en-us)

Uninstall third-party event sinks

1. Uninstall any third-party event sinks.
2. If you can, move the mailboxes to new blank databases.
3. Try to back up the databases by using the Windows NTBackup program.
4. If you are successful using the Windows NTBackup program, try to use your third-party back-up program.

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

To do additional troubleshooting, follow these steps:

Determine the RestrictAnonymous registry value

If you cannot do a successful remote backup, determine whether the RestrictAnonymous registry value is set to 1 or to 0. The RestrictAnonymous registry value must be set to 0 to permit an anonymous Lightweight Directory Access Protocol (LDAP) query against the information store.

For additional information about how to use the RestrictAnonymous registry value, click the following article number to view the article in the Microsoft Knowledge Base:

Defragment and repair the information store database

1. Troubleshoot any hardware problems that may cause an information store database problem.
2. Dismount the mailbox store.
3. Perform an off-line backup of the .edb Information Store database and of the .stm Information Store database.
   
   For additional information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
   296788  (http://kbalertz.com/Feedback.aspx?kbNumber=296788/ ) Offline backup and restoration procedures for Exchange
   You can back up the .edb database files and the .stm database files to tape or to another location. Alternatively, you can copy the databases to another folder or to another volume by using the Esefile utility. The Esefile utility is available on the Exchange 2000 Server CD-ROM in the Support\Utils\i386 folder.
   
   For additional information about how to use the Esefile utility, click the following article number to view the article in the Microsoft Knowledge Base:
   248406  (http://kbalertz.com/Feedback.aspx?kbNumber=248406/ ) Esefile support utility for Exchange Server 5.5 and Exchange 2000 Server
4. Perform an off-line defragmentation of the database.
   
   You want to do this to recover the database from checksum errors. To do an off-line defragmentation of a database that is 4 gigabytes (GB) to 6 GB takes about an hour. You also have to have about 110 percent of the size of the database available as free hard disk space to perform the off-line defragmentation of the database.
   
   For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
   192185  (http://kbalertz.com/Feedback.aspx?kbNumber=192185/ ) How to defragment with the Eseutil utility (Eseutil.exe)
5. Run the Esefile utility against the defragmented .edb database and the defragmented .stm database to perform the checksum error verification.
6. If no checksum errors occur, mount the database. Try to perform an online backup of the database.
7. Do a "hard" repair of the database if any one of the following problems occur:
   • You cannot do an online backup.
   • You cannot do an off-line defragmentation.
   • You have checksum errors in your database.
   The "hard" repair of a 4 GB to 6 GB database takes about an hour.
   
   Note This procedure causes some mailbox data loss. This is because the 4 KB pages that fail checksum error verification are deleted. For more information about how to perform a "hard" repair of a database, click the following article number to view the article in the Microsoft Knowledge Base:
   259851  (http://kbalertz.com/Feedback.aspx?kbNumber=259851/ ) Ramifications of running the eseutil /p or edbutil /d /r command in Exchange
8. After the "hard" repair of the database operation is successfully completed, repeat steps 4 and 5 to perform an offline defragmentation of the database.
   
   Note A repaired database must not be left in production. While the /d switch is used with the Eseutil utility to defragment a database, what the Eseutil utility actually does is create a new database that stores the defragmented information. Then, the Eseutil utility replaces the existing database with the new copy. This is a good idea in case the existing database structure is corrupted.
9. After the defragmentation of the database is successfully completed, run the Isinteg utility against the repaired database to detect and to fix logical errors in the information store. These logical errors may be the result of the "hard" repair of the database operation. The Isinteg utility can process about 4 GB to 6 GB of data per hour.
   
   By default, the Isinteg utility is located in the Program Files\Exchsrvr\Bin folder on the drive where Exchange 2000 Server is installed.
   
   The following command shows the syntax that is used to run the Isinteg utility:
   
   isinteg -s servername -verbose -fix -test alltests -l the path and the filename for the log
   
   For example, type the following command where servername is the name of your Exchange 2000 Server:
   
   isinteg -s servername -fix -test alltests -verbose -l c:\isinteg1.log
10. Type the number of the unmounted information store that you want, and then press ENTER.
11. Examine the log file that is produced by the Isinteg utility. Continue to run the Isinteg utility until the number of fixes and the number of errors in the log file equals 0 (zero) or until the number of errors and the number of fixes do not change.
    
    Note Specify a different name for the log file every time that you run the Isinteg utility.
12. Repeat step 4 and step 5 to perform an off-line defragmentation of the database.
    
    Note A repaired database must not be left in production. While the /d switch is used with the Eseutil utility to defragment a database, what the Eseutil utility actually does is create a new database that stores the defragmented information. Then, the Eseutil utility replaces the existing database with this new copy. This is a good idea in case the existing database structure is corrupted.

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base: The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.