Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2901
  • Last Modified:

IS terminates with service specific error 4294966746 EID 7024

Ladies and Gentlemen,
I ran a restore from tape and tried to start the IS with this error:
The Microsoft Information Store service terminated with service-specific error 4294966746
Event ID: 7024
Source: Service Control Manager
Type: Error
Category: None

I run restores all the time for people who "misplace" emails.  We recently installed sp4 for exchange 5.5 as a fix for an oversight.  Oversight being: When sp4 was installed on exchange servers, it wasn't installed on our recovery server.

Before I got the error listed above, I got the error 3355445011 indicating the RestoreInProgress registry key.  I deleted the key and tried to start IS.  Now here I am...
  • 2
1 Solution
Here are my notes on the error you are receiving in 5.5. Keep in mind that if this is a recovery server as you stated, it is reasonably easy to completely uninstall exchange, reboot, and start all over again, provided that the server is not directly tied into the exchange organization. If it is not a recovery server, be very careful as any steps you take can cause the loss of email or even the database itself. Also note that of course, as you pointed out, all exchange servers in an organization, even unassociated recovery servers, must be running the same service pack level for Exchange, and same OS & SP if possible.

5.5 Recovery Server proceedures:
Attempt to restart the information store.

If it fails with error codes 4294966xxx or 335544xxxx, you must repair the database (typical error codes include 4294966-746/766 and 335544-3730/3752/5011).

Run “eseutil /p C:\exchsrvr\mdbdata\priv.edb”  from the C:\Exchsrvr\bin directory. If the mdbdata folder is on another drive, change the drive letter(s)

The process will take approximately 2-3 hours to complete on a 16GB store.

In regedit, HKLM\System\CurrentControlSet\Services\MSExchange IS\ delete the “Restore in Progress” subtree.

Open the Mdbdata folder and delete (or relocate) all *.log, *.chk and *.pat files from the directory.

Attempt to restart the Information Store. Error 1011 should appear indicating that isinteg –patch needs to be run. This is also done from the command line in the exchsrvr\bin directory. Restart the store after running isinteg.

Once running, open Exchange Administrator. Navigate to Configuration/Servers/<servername>. Select the server name and invoke the properties page for the object. On the “Advanced” tab, press the Consistency Adjuster button.

Check the box under the Private Information Store header marked “Synchronize with the Directory…”

Select the radio button under Filter marked “All Inconsistencies”. Hit OK twice.

Once completed, the Exchange Server is ready for ExMerging or other operations.

Ed Muller
Advantage Technologies, Inc
"If it fails with error codes 4294966xxx or 335544xxxx, you must repair the database (typical error codes include 4294966-746/766 and 335544-3730/3752/5011)."

This statement is a bit misleading.  While there are situations in which you will need to repair, they are certainly not the rule when getting these errors.  Many of the problems that people run into when doing online restores are related to files being mismatched (usually log files).  Most of these can be fixed simply by rectifying the root cause.  In your case, I would suggest that if you're restoring from backup and not attempting to roll forward existing logs, just clear all mdbdata folders and restore again.  Do not run any utilities, just start the Information Store.  If you are attempting to roll forward existing logs, ensure that there is no gap in the sequence between whats on disk and what comes off tape, and ensure that your last log is called edb.log.  Also make sure there is no edb.chk file present.

The 335544xxxx error means that Exchange is not expecting a Restore in Progress key but is finding one anyway.  If you get this error you can recover without a repair if your priv.pat and pub.pat files are 8k (any larger than that will require another restore or a repair).  If this is the case, simply delete the RIP key, rename the last log file you have to edb.log, delete the .pat files, and start the Information Store.

If you end up having to run a repair, you will need to follow it up with the following 2 commands:

isinteg -fix -pri -test alltests   (run this until the report says all 0's for warnings, errors, and fixes)
eseutil /d priv.edb    (this will do an offline defrag.  Ensure that you have 110% of your DB size free)

MS's official word on supporting repaired DB's in production is that you either have to isinteg/defrag afterwards or you have to exmerge the contents out and into a new store.
Keep in mind he is running 5.5, which only allows him the -patch option. While you can certainly delete the pat logs and try again with such error messages, I have found that once this is done, further repair is often not possible. And then the entire process must be started over including uninstalling exchange and performing the restore again (recovery servers only). When it came to overall time management, knowing that a certain process will 99% yield a positive result, I go with it. Rather than risking having to start over again. It's a personal route, not meant to deceive anyone.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now