config running exchange 2k3 sp2 on server 2003 r2 standard edition sp2 exchange program files installed to the default location on c: information stores installed to: d:\exchsrvr\mdbdata\ background Ive run eseutil in the past and havent had problems, although I cant remember the last time I did so (probably 2 years). I run it mainly after large amounts of data have been removed. such is the case this time. the current size of the private information store is about 60GB, but I know weve removed at least 10GB, so Id like to run a defrag. issues the public store (which is very small, only about 33MB) finishes quickly and without issue. its the private store that fails. the problem is that I get the following error about 20% of the way through the process: unable to find the callback library jcb.dll (or one of its dependencies). copy in the file and hit OK to retry, or hit Cancel to abort. and then once Ive cancelled: Operation terminated with error -2102 (JET_errCallbackNotResolved, A callback function could not be found) after 2417.63 seconds. running eseutil when running eseutil, Ive gone to c:\program files\exchsrvr\bin and run the following command: eseutil /d d:\exchsrvr\mdbdata\pub1.edb /t d:\tempdfrgpub1.edb eseutil /d d:\exchsrvr\mdbdata\priv1.edb /t d:\tempdfrgpriv1.edb I have plenty of room free on D: (more than 200GB). troubleshooting methods Ive tried Ive faced this callback issue before and was able to resolve it by copying several files from the \bin directory (Eseutil.exe, Ese.dll, jcb.dll, Exosal.dll, and Exchmem.dll )into the database directory (d:\exchsrvr\mdbdata). this no longer does the trick. I could sure use some insight here, thanks. ross

Please ensure the path includes "c:\program files\exchsrvr\bin". Alternatively you can try copying the required files including jcb.dll to c:\Windows\system32 folder.The other option would be to reinstall Exchange SP2.Bhargav Shukla|PFE : Messaging |Exchange Server TechCenter|Microsoft Exchange Team Blog | My Threads|My Blog

just goto the BOOT.INI file on the server you are getting eseutil error and add /3Gb switch as shown below, restart the server and then run the ESEUTIL command as per your requirement. [Boot Loader] Timeout=30 Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [Operating Systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Advanced Server" /fastdetect /3GB Let me know if this fix the issue. :-)Tech Consultant (Ms Exchange 5.5, 2k, 2k3, 2k7)

This worked for me on SBS 2003 R2 Reinstallation and remounting of old Exchange store into new installation environment. Priv1 worked fine but got above error on pub1 and after trying to copy file jcb.dll option (failed) I tried BootINI option and restarted and it work like a charm. http://support.microsoft.com/kb/327156 Thanks FD Smarthost Design Technologies LLC

Good options to check from the others, I have also have seen a corrupt Pagefile do this, as well as a pagefile located on SAN storage. so you might ensure its on a local disk, that has plenty of room and if that's already the case, re-create it to see if that solves the issueTroy Werelius www.Lucid8.com Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope

I have copied the jcb.dll from a working server with the same service pack level to c:\program files\exchsrv\bin, pressed ok a couple of times, and it continued to defrag the database. update: eseutil finished the defragmentation process just a few minutes ago. jbc.dll file was corrupted. the .edb file was 107GB and now is 67GB, .stm file was 17GB and now is 7GB. see http://support.microsoft.com/kb/273087 it states that jcb.dll is corrupted, renamed or missing.

Ross, here is my take on this, I am not very clear why you want to take production database due to 10GIG white space. As you know whitespace in the database will be re-use by Exchange server, shrinking it only give you advantage of doing smaller backup in Exchange 2003 world, which again taking production server down for 10 GIG does not seem to be good practice. I am assuming you are running standard version of Exchange 2003, if you are not then it would be waste of time what you are doing, the best way would be creating new (fresh) health DB and move mailboxes on it, and nuke the first one once you have successfully moved all your mailboxes. If you could, you should upgrade to E210 and take advantage of I/O improvements and if I am not mistaken the difference more than 100 percent, not to mention standard version you would not stuck with single DB to deal with. Good luck, Ocd Oz Casey, Dedeal MCITP (EMA), MCITP (EA), MCITP (SA) Visit smtp25.blogspot.com Visit Telnet25.wordpress.com This posting is provided AS-IS with no warranties or guarantees and confers no rights.