Link to home
Start Free TrialLog in
Avatar of tamaneri
tamaneri

asked on

Restore Deleted Contacts Exchange 2003

Fellas,

I had to wipe my client's blackberry this weekend. I knew all of his Contacts were in Outlook, so I didn't back up the phone. I synced his BB to his desktop this morning. I was requested to write all of the Outlook contacts to his phone, so that's what I did. Well, now all 1800 contacts in Outlook are gone, replaced with the 5 that were on the device (DAMN!).

I have a FULL backup of the entire system. I am using Symantec Backup Exec 11d to TAPE.

When I look to perform a restore from tape, I only see "Mailbox Store"

How can I restore just the individual Contacts for this one user's mailbox?

Thanks guys.
Avatar of 0xSaPx0
0xSaPx0

If you were not using the Exchange Agent to do  brick level backups then you are unable to restore individual folders in individual mailboxes.

0xSaPx0
Ouch, it hurts to find that your backups weren't getting what you thought they were. It is good too find out before you have an actual system crash though. Another option might be deleted items retention. Any chance that you have the running on the exchange server?
I believe the retention is only for email messages.

But go to Tools - Recover Deleted Items to try it.

0xSaPx0
SOLUTION
Avatar of zelron22
zelron22

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of tigermatt
tigermatt
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Of course some caveats: (a) make sure that you redirect the restore to the recovery store!!!  (b) you need as much disk space for the recovery store as you need for your information store, so if you have a 50GB information store you'll need 50GB of free disk space (plus some for slop) for the recovery store.
Tigermat, I trust you were referring to 0xSaPx0 as the "previous poster".
Did you check to see if it moved his contacts to the Recycling bin in outlook we had a user sync his treo but it moved all contacts over to the recycling bin.

but check out this article

http://support.microsoft.com/kb/823176

tamaneri, if you haven't been doing brick level backups of your Exchange mailboxes, you can still restore the user's contacts, although it's a much longer road to get there.  You would have to restore the entire mailbox database to a recovery storage group in Exchange. Once the mailbox store is restored to your recovery group, you can export (using Exmerge) the user's contacts to a PST and then re-import them into his/her active mailbox.  Here's an article about how to do this with Backup Exec:
http://seer.entsupport.symantec.com/docs/264815.htm
PS - this is assuming you are using Exchange 2003. You didn't specify your Exchange version.
Here's how you can use RSG's w/BE
http://seer.entsupport.symantec.com/docs/264815.htm

The brick level backups would have saved you tons of time, just drill down, check the contact folder, click restore. 10 minutes.

Might just be me, but I'll take that old/slow backup method any day to the tomdodgery that is Recovery Storage Groups...

0xSaPx0

Brick Level backups are old and for large mail stores, very, very slow. Talk to any Exchange consultant, and you will quickly find the majority disapprove of Brick Level backups. The features available in RSGs, and the speed at which such backups can complete, make them much more suitable.

-Matt
@hypercat

>> You didn't specify your Exchange version.

See the question title. :-)

M
If this has only just happened then I presume Recover Deleted Items has been checked?

You may have to turn it on for other folders first or use OWA.
http://www.amset.info/outlook/recoverdeleteditems.asp

-M
@Matt - Ok, so I don't reed so gud sumtymz ;-P
Deb
Avatar of tamaneri

ASKER

Well fellas,

Considering the items were overwritten with other blackberry data, they did not go through Deleted Items :(. No go on the recover deleted items.

Sounds like my ONLY option is to recover everything through an RSG. I will report back when I have accomplished this!
Ugh. Just noticed my MDBDATA folder is 58GB

Only have 48GB of free space on the drive :(
So, let's just say I don't have the necessary space to configure an RSG.

What about restoring the entire mail store over itself later tonight? Will I lose e-mails from today? Other issues I could face?

Restoring the whole mail store over the top of itself will cause you to lose anything added to the stores today.

Having a 58GB MDBDATA folder doesn't necessarily mean you have 58GB worth of mail store. It could be significantly less, once issues like white space in the databases and transaction logs (if they are stored in their default location) are taken into account. How large is the Mailbox Store reported as being in the backup?

-Matt
Have you been doing full backups?  If not, then depending on how your server is set up some of that space could also be taken up by log files.  Ideally the log files should be on separate PHYSICAL disks, otherwise the drives are doing double duty writing logs as they write to the db.
IF you can we had an issue where we ran out of space we bough an external hard drive and put the recovery store on to the external cause onces it done with you wont need it again.

mind you we did this for a 300 GB store with yours only being 56 I would suggest it to you as well though microsoft will say they dont recommend it

A Recovery Storage Group  will exist on the server for the sum total of about 15 minutes - the time taken to extract the data from the RSG. An external USB drive would be perfect for restoring to if the hard disk space on the server is a major issue. You can easily delete the RSG and blow away the files on the USB disk once the data is recovered.

-Matt
Fellas,

I've created the RSG. I've followed the steps from this article: http://seer.entsupport.symantec.com/docs/264815.htm

But I get this message:


wtf.JPG
Take out the 'No Loss Restore' option and then try again. You probably won't need the Transaction Logs to be replayed in this case, so 'No Loss Restore' has no effect.

Also, be 200% sure you are restoring to the RSG before you hit the button!

-Matt
How do I know FOR SURE I am restoring to the RSG ? Hhaha.

Here's a better pic as to why I'm frustrated with the "no loss restore" BS.... it's already deselected!!!!



wtf2.JPG
And also....

Do I need to populate these fields?


RSG.JPG

The easiest way to ensure you don't overwrite your main databases is to edit their Properties, and uncheck "This database can be overwritten by a restore" on the Database tab. That way, no restore job can go through the main databases. However, obviously leave that option enabled on the RSG so the restore will work correctly.

In Backup Exec, I believe the option for restoring to the RSG which you are after is under Exchange Redirection in the Restore job.

The No loss restore option is under the 'Log recovery options when restoring the Information Store' in that previous graphic you sent. To be honest, prior to fiddling with those settings, I'd try the restore and see if the restored RSG mounts. If it does, great; if not, you can go back and choose the second option there, and try again.

-Matt

Here you go: http://seer.entsupport.symantec.com/docs/264815.htm. Instructions direct from Symantec. It doesn't exactly match your version of the software, but it will answer all your questions on the procedure.

-Matt
Thanks Matt,

Those are the steps I followed. Just stuck at the "no loss restore" feature, which I've already deselected. Keeps bringing up that error message no matter what I choose :(
And it won't let the backup job proceed if you do try to continue?
Correct... will not go past this box ..... error just keeps popping up. I got out of the restore, went to the backup options themselves (before the restore job) and deselected the option.

Same shit. ugh!
Anyone want to connect up to the mofo and take a look? lol.
Wait a tick... I may have gotten past it.... It looks like it's attempting to restore now. ERROR 99 FTW.
Okay... So maybe I didn't restore it to the right spot... I guess I'm missing a step?

Restore- \\APPLAUSEAD01\Microsoft Information Store\First Storage Group Unable to restore the selected Microsoft Exchange databases because one or more of the storage group's databases are mounted.  Use the Exchange System Manager to dismount all the databases for the storage group 'First Storage Group', and then retry the job.
V-79-57344-65217 - A failure occurred performing the post-restore operation.
V-79-57344-65217 - An error occurred while completing the operation on \\APPLAUSEAD01\Microsoft Information Store\First Storage Group
A failure occurred performing the post-restore operation.

I don't see anywhere in the restore tab to even choose the RSG???
Content does not have to go through Deleted Items to be in Recover Deleted Items. That is why the registry change is there.

-M
Mestha,

Just applied the registry change. Just have a blank box when I open the "Recover Deleted Items"

Perhaps it's just taking awhile to load? I'll check back in an hour or so.
Okay guys.

I guess I'm not understanding how Symantec knows to restore to the RSG that's been created. I don't see where in the Restore job this is specified? I ran the restore based on this http://seer.entsupport.symantec.com/docs/264815.htm and it seems like it's trying to restore over my Mailbox Store and not to the RSG

Any advice?
Alright. I restored the database to the RSG. It now shows the "Mailboxes" and Logons" folder, but nothing in them!?
What folder location did you direct the RSG to use for the mailbox store?  Check that location to make sure there is a private info store database (.edb) in that location. Also, is there a red mark on the info store indicating that it's not mounted?  You may have to mount it manually, I don't remember since it's been awhile since I had to do a RSG restore.
I played with it all night last night. I am restoring the files again, this time to D:\Program Files\Exchsrvr\Recovery Storage Group\

I am able to mount the database, but it mentions it is missing .LOG files and then it recreates new edb and stm files :(

I'll try to get screen shots of the error messages.
Looking back over the previous posts, which I missed while off-line, it sounds to me like maybe the backup you are restoring is not a full backup. Is it possible that you're restoring from an incremental backup instead of a full one? I'm not sure if Backup Exec 11d even allows you to do differential or incremental database backups, but I thought I would ask given the content of those posts. If so, you would need to go back and restore your last full backup first, and then restore the incremental(s) or differential(s) inbetween to get up to your most current database status.  
Most definitely a full backup. Full backup every night. I will let you know which files I have once the restore is completed so you guys can have a better idea of my status!
Okay, restore just finished. Here is what I have:

Am I missing anything here? :\
databases.JPG
logs.JPG
And this error when I try to mount:


mounterror1.JPG
There are two steps that MS recommends after restoring the database.  I would recommend doing the first, and the second may be the step you're missing that will prevent that error from coming up:
1. Verify that the database that you want to restore is consistent and that it is in a "clean shutdown" state. To do so, open a command prompt, switch to the ExchSrvr\Bin folder, type the following line, and then press ENTER: Eseutil /mh YourDatabaseName.edbIn the output that appears in the Command Prompt window, note whether the State line shows as State: Clean Shutdown or State: Dirty Shutdown.
2. Start Exchange System Manager, and then view the properties of the database that you restored. On the Database tab of the Mailbox Store Properties dialog box, verify that the This database can be overwritten by a restore check box is selected.

 
Hypercat,

I use these steps even if the restored databases are attempting to be restored to an RSG?
Just to answer for hypercat - yep, use them even on an RSG EDB file.

-Matt
I feel so dumb right now lol... never done this before

Okay so I opened a CMD prompt and put in:

cmd.JPG
The restored database (edb) is obviously in a different location than the REAL one... either way the name is the same... "priv1.edb"....
Use the command (on the Exchsrvr\bin folder)

Eseutil /mh "D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\Mailbox Store (APPLAUSEAD01)\priv1.edb"
Your screen capture shows a typo on the name of the database - "priv1.edbln" - should be just "priv1.edb". I think it's my fault - my instructions were missing a "." and space between the command and the next sentence.  The command should be:
eseutil /mh  priv1.edb
Assuming, of course, that your database name is the default of priv1.edb. Sorry...
And as Matt posted - you want to run the command on your RSG, not the live database.  His path would be correct,  as far as I can tell from what you've posted.
You guys are ridiculously helpful. I love you all. Here are the results. Shall I proceed to Step 2?


result1.JPG
result2.JPG
She's dirty :)
Oh that dirty girl!  ;-)  Looks like you have to do a hard recovery:
eseutil /cc [Path to restore.env file]
The path would be the location of your transaction logs for your RSG. That would be the D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\Logs folder.  Here's an article for further explanation:
http://support.microsoft.com/kb/232938 
Okay, just plugged in:

eseutil /cc d:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\Logs

Doesn't like spaces in the path??




repair.JPG
Put quotation marks around the path, e.g. eseutil /cc "d:\program files\exchsrvr\..."

-Matt
That might be the case.  Also, I've never done this exact command, but I think maybe the path should be just:
d:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group
I'm not sure you need the "Logs" portion of the path at all.
I'm going to try looking this up to see if I can find an exact path example.
Thanks Matt, that worked. On to the next! Haha. I'm trying to feed you guys as quickly as possible so you can feed me :)

This one looks....not so fun.

error.JPG
Let me try that hypercat..... seems to make since given the error right here...
Damn, tried it with just "First Storage Group" leaving out the "Logs" but same error haha
Well, the file location specified, according to the articles I'm finding should be the location that you specified during the restore for "Temporary location for log and patch files."
Also, the articles are describing an option that can be checked during the restore that will cause an automatic hard recovery to run.  The option is "Last Backup Set."  Did you see and check such an option in Backup Exec?  I'm sure these articles, being MS articles, are referring to ntbackup, not Backup Exec, but there should be a similar option.
I am looking in the "Logs" folder, I do not see a "restore.env" file... or any .env file for that matter..... problem?
I don't mind having to restore the database again....

All of the options regarding the restoration of the database can be found in POST #25...

I wasn't entirely sure what each did so I basically left to defaults..... see anything there?
The path for the temporary location for log and patch files on your screen capture was C:\Temp.  Did you change this path when you did the actual restore operation? This is the path it's looking for when doing the hard recovery.
Apparently, the "Commit after restore completes" option in BE is supposed to be the equivalent of the "Last Backup Set' option. Did you leave this checked when you ran the restore? If so, at least theoretically we shouldn't have to do the hard restore.
I forgot to say specifically that if the restore.env file isn't there - whatever that temp path was - then it indicates that a hard recovery was done and completed successfully already.
Hmm, just checked C:\Temp... no restore file there.....


You know what... on THIS particular restore, I did select "commit after restore completes"

So technically we can skip this step.... ?
Yes, I hate to admit it now after all this, but it appears that we should be able to skip it....
Okay so am I back to.... here?

2. Start Exchange System Manager, and then view the properties of the database that you restored. On the Database tab of the Mailbox Store Properties dialog box, verify that the This database can be overwritten by a restore check box is selected.
Yes, you are back to #2, and after that try to see if you can mount the database. Then if you still can't mount the database without errors, we'll have to see if we can figure out what's still wrong.
Hypercat you're the man for hanging in here with me!

Okay, just tried to mount.... back to this message:


mounterror1.jpg
Ok - let's do this just to be cautious.  Make a flat file backup copy of the .edb and .stm files that you just restored, and also of the transaction logs files that were restored with them.  Then you can go ahead and click "Yes" on this message and let's see if the databases will mount after that and what you get. Unless you already tried this before?
I'm still around and listening... *smile*
If I'm NOT mistaken, hitting yes to this message.... brings up a second box stating that there are no compatible stm and edb files available and that it will create new ones.... something along those lines

Unfortunately I don't have enough disk space anywhere to make a flat backup of these files hahaha.... so if I try it... I can just restore the files again? lol
Hi Tigermatt! :)

Glad to hear it. You guys are the best! Keep kickin, you've both earned points regardless in my mind.
Yeah. The files came from a restored backup, so if you really needed to (and assuming that backup wasn't overwritten last night) you could restore it and start the process again.
Yes.  And if it creates new blank files, you can leave them there. Just dismount the blank databases before you start the restore, and delete any .chk or .log files if they got created.
Okay... Just hit YES to that message and this is the prompt i get.... should I just hit yes again?


missingfiles.JPG
Not sure if this well help any.....


properties.JPG
That all looks normal. Since neither Matt nor I was around to answer that last post yesterday evening, what did you do and what results did you get?
I left it right where it was! :)

From doing this a few days ago, I know it's going to create a new .edb and .stm file.... it will then mount, but it'll mount with no information in the mailboxes folder (since it creates a new .edb if i YES"
OK.  I think what is happening is what is described in this article:
http://support.microsoft.com/kb/843092
To avoid that, what you need to do is to leave the blank databases in place, but check the box to allow them to be overwritten by a restore. Then do the restore again. I'm pretty sure this will work. Like I said before, I've only done this a couple of times, and it's been a few years.  We're learning a lot here, right? :-)
hypercat i think you may be right. I'm going to try that right now!! prob going to take an hour and half or so to restore... and i need to be somewhere at 12. I will report back as soon as I can!
Piss..... backup overwrote this tape last night hahaha... I have 2 week rotations with tapes ... having my client throw in a different tape :)

P.S. I'm learning tons!
Something to note: When I do a restore, it restores all of the data to:
D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\

When I mount the database, the 2 new edb and stm file are created in D:\Program Files\Exchsrvr\Recovery Storage Group

Is there anyway during the restore I can ensure it's writing to the Recovery Storage Group folder?

I did folder redirection to D:\Program Files\Exchsrvr\Recovery Storage Group, but the restore seems to automatically create: \Exchange Server\First Storage Group\

I guess what I'm trying to get at...

is I don't want to restore the files again if they're just gonna but put in D:\Program Files\Exchsrvr\Recovery Storage Group, but the restore seems to automatically create: \Exchange Server\First Storage Group\...

because technically even if I restore... it won't overwrite what is in Recovery Storage Group if it's writing it to a different directory
OH - I just looked at your database paths again, and that is where they are pointing - D:\Program Files\Exchsrvr\Recovery Storage Group.  You need to change the database paths to point to the correct folders.  If your path is pointing to the correct location, the databases just might mount, since it's different from the location you actually have in the database properties dialog box.  Sorry - I missed that and I'm glad you pointed it out...Looking back at the previous posts, it looks like the path should be:
D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\Mailbox Store (servername)
If that's the actual folder where the .edb and .stm files are located.  Also the same for the logs, except the folder is [path]\Logs.
I actually deleted the edb and stm files it created and brought over to the Recovery Storage Group my actualy stm and edb files.... tried to mount, same error hehe

I want to just restore over the new ones it created... but if I restore it's just going to restore them to D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\

Which technically will not overwrite what is in \Exchsrvr\Recovery Storage Group.... catch my drift?
Just to clarify, if the restored .edb and .stm files are still there, in a different folder from the blank ones, then just change the database and log file paths and see if the restored database will mount.
Let me play with a sec... I'll report back :)
Not to beat a dead horse, but I've been kind of keeping tabs on this thread.

Granted, once you get this process ironed out, it may be easier next time.  However, be aware that starting with Symantec Backup Exec 11d they have what they call Granular Recovery Technology (GRT).  If you configure that for your backups (it's part of the Information Store backup, not a separate brick-level backup) you would have been able to restore the missing contacts directly from the backup without creating a recovery store.  Previous to GRT if you wanted to do brick-level backups, you also had to backup the entire store as well (for DR purposes) so you were backing up more than twice the data (the brick level backups are less efficient) and taking a lot of time.

I would at least test it before discounting it out of hand.  I think it may take longer than a standard Information Store backup but less time than an IS and separate brick-level, and it could save you time down the road, and eliminate the steps required (using exmerge, etc.) once you do complete the recovery group restore.

You mentioned you're learning a lot, and that may make this process worth it (this time, anyway).

Good luck!

Do you still have the recovered .edb and .stm files in the \Exchsrvr\Recovery Storage Group folder? I'm thinking maybe at this point the problem is the log file location.  Look at the properties of the storage group and see where the transaction log file location is pointing.  That might be wrong also - It has to point to the folder where your restored logs are located.
BTW, zelron22 is correct, and that is a discussion I was saving for after we get through this fracking process successfully!
I'm in your boat Zelron, I much prefer to do it the way you have suggested (which I've done for most of my clients.... i didn't configure this server though!)

Okay... I just tried to move the database location... i clicked "open" on \exchsrvr\first storage group\ but it just moved the newly created edb file to the \\exchsrvr\first storage group location.

I am so confused! lol
Okay I moved the "newly" created databases to D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group -- which is right where the restored files are being placed when I do a restore.

The "newly" created database names are "Mailbox Store (APPLAUSEAD01).stm/.ed"

When I restore, I'm pretty sure it'll restore as "priv1.stm/edb"

Will this be a problem when trying to restore over the current db?
That's what happens when you change the database location that way - it moves the current .edb and .stm files to the new location you specify.  At this point, assuming that you don't have the other restored .edb and .stm files somewhere, then you can run the restore again.  But BE SURE that you:
1. Change the transaction log file location also, so that it points to the location where the transaction logs files get restored.
2. DELETE any existing transaction log files (.chk or .log) that are in that folder.
That's OK, just make sure that after the restore, you go in and change the properties of the mailbox store so that it's pointing to the restored files, not the blank ones. If you want to make double-sure this will work, you can change the existing (blank) database names to match the ones you are restoring:
1.  Open the properties of the mailbox store, go to the Database tab.
2.  Click the browse button on each database location field (like you were moving them), and in the file name field, change the name to "priv1.edb" and "priv1.stm".
You'll get the same confirmation messages you did before; check "yes" on each, and you'll get a message that the databases have been "moved." If you check the location, what you'll see is that actually the database file names have been changed.
 
Ahh, good point hypercat! I will change those names to match.

Trying to move the Logs file right now. I just dismounted the store, but "Browse" is grayed out when trying to move the Log Files..... interesting eh?

Renaming the database files now.
Okay database files renamed. Before I start the restore I want to move the Log location... obviously.

Right clicking on Recovery Storage Group in ESM, unable to click "Browse".... any ideas?
Weird - I just checked on my own server, where I have an RSG mounted as a test.  On the active storage group, I can move the transaction log files, but not on the RSG. I guess the point is that all of the transaction logs are supposed to be replayed already (by the restore/hard recovery process), so theoretically there wouldn't be any excess log files created. The restored log files go into the Temp location you specify at the time of the restore and then are replayed and supposedly committed to the database during the hard recovery.  I would just check whatever location is listed and make sure there's nothing in it before you do the restore.
Hi Hypercat,

Sorry been out of the office most of the day..

Okay, the Log location is \Exchsrvr\Recovery Storage Group\  with a logfile prefix of R00.

My logs (from the database I plan to restore shortly) is E00. Will that be a problem?

So Log location: D:\Program Files\Exchsrvr\Recovery Storage Group\
Database location: D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group

I have emptied this location: D:\Program Files\Exchsrvr\Recovery Storage Group\ as far as logs are concerned.

D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group
In that location, I have just the newly created priv1.edb and priv1.stm

So how am I looking for the restore before I hit the button?
That all sounds good to me.  The log file names shouldn't be a problem since, as I said, they should end up being replayed and committed even before you open the database.  Just remember to be sure that:
1.  On the RSG database properties, the "This database can be overwritten by a restore" is checked; and
2.  On the restore options in BE, the "Commit after restore" box is checked.
And then keep all of your fingers, toes, and anything else that won't perpetrate bodily harm on you crossed!
(And I sure hope your client is paying you for all this time you're devoting to recover his contacts folder...)
Nope... no money for this one haha... I guess technically it's my fault........ but at the end of the day he's a support client :(
Let's hope he's the kind of client who appreciates tenacity!
I'm restoring the file right now.... However, I do see that it auto-created a folder called "Mailbox Store (APPLAUSEAD01)"

so the path for the restoration is: D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group\Mailbox Store (APPLAUSEAD01)\

Which sucks because the databases are in D:\Program Files\Exchsrvr\Recovery Storage Group\Exchange Server\First Storage Group

I might have to move the databases again and restore... .yet again?
Alright my friends. I could kiss all of you! ;) wink wink

I ran  eseutil /p "drive:\Program Files\Exchsrvr\MDBDATA\priv1.edb", (obviously with my info).

It repaired the database.

I restored the databases. .... not to the right spot. BUT i replaced the newly created db's with my restored db's..... then i also replaced the LOGS with my restored logs. (renamed the files as necessary).

I mounted the DB and wallabangwallaboom! I see the mailboxes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I feel so happy! i love you guys!

Next step would be exmerge correct? Have any articles on that bad boy?

It repaired the database.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Exmerge was straight forward and easy to use. I've already got his contacts imported back into his original mailbox :)

Waiting to contact him at 2:30 and install them back on his phone!

Thank you everyone for your help! I love you all!!!!
Thank you everyone for your knowledable insight and dedication! I have resolved the issue and I am extremely happy!
You deserve credit and congratulations, too, for your patience and persistence on behalf of your client in getting this resolved.  Too bad you can't award yourself some points!
Oh, and maybe now you can get on that client's server and set it to backup Exchange using GRT from now on.
Cheers,
Deb
Glad you got it working in the end. Apologies I haven't been around to work through this with you guys toward the end of the work!