2.4.6 upgrade to 4.0(3) DBimport failing

[colin.mcnamara]

I am using the new fulldbimport utility for 4.0(3) to migrate from an old 2.4.6 system.

My issue is that when I run the db import utility, it chugs along importing, until it hangs on one record -

(error) in import distribution lists first pass. Number=-2147217887, Description=Could not update; currently locked., Source=Microsoft JET Database Engine

Updated DTMFAccessID=99991

(error) in import distribution lists first pass. Number=-2147217887, Description=Could not update; currently locked., Source=Microsoft JET Database Engine

(error) in import distribution lists first pass. Number=380, Description=Invalid property value, Source=ProgCtrl

Alias:allsubscribers

Name:All Subscribers

Existing DL found in SQL

retrieving voice name

Finished.

Updating SQL

Updating local MDB file with new ObjectID={D8B3B91E-40C8-4D10-A171-F7C0116FFA8B}

This happens over and over again until the db import script terminates after 10,000 errors.

I used these same tools in the lab enviornment and was successfull.. I opened up a TAC case and ended up explaining the function of these tools to the rep I was assigned. Needless to say, I am turning to the collective wisdom of this forum for help.

Anyone have any ideas ? I am stumped.

Colin McNamara

[lindborg]

The most common cause of errors along those lines are a problem with one of the (many) MDAC files used for Access DB stuff - in the help file I have a link to the MS web site where you can get the latest - I have tested with 2.6 and 2.7 extensively but the latest full version of MDAC should be fine. I'd reccomend downloading that, installing, restarting and trying the import again.

[colin.mcnamara]

I checked the mdac version it was at 2.71

Definately scratching my head on this one.

I am currently reloading the server from scratch, going with a 4.0(2) import and then upgrading to 4.0(3)sr1.

The method I used to verify mdac version was both by pulling up the server properties in enterprise manager and verifying sql server sp3 and also checking the version listed in the registry

local-machine>>software>>microsoft>>dataaccess

I must say though, its really a great thing from a customer side to see you so active in the forums, and the whole answermonkey thing.. Thanks a bunch :)

[lindborg]

I wasn't worried about the version of MDAC - I've solved _many_ similar problems by simply reinstalling the latest version of MDAC. It's worth doing that before waxing the system...

[colin.mcnamara]

I guess that would have been prudent, shame on me for not doing that, however the "wax" has already been applied so to speak..

[lindborg]

OK.

Well, if you continue to have trouble after you rebuild, you can shoot me the MDB file created by the backup of the 2.x system and I can walk it on a 4.0(3) restore here.

Just for the edification of anyone coming across this later - the basic logic between the 4.0(2) and earlier version of dbImport and the 4.0(3) and later are the same, it's just using different mechanisms to populate the UnityDB SQL database (i.e. different stored procedures) before calling the synch to the directory. The updates to the MDB file itself remains all unchanged and since that's where the error was cropping up there shouldn't be any difference between the two versions there...

[colin.mcnamara]

Thanks for clarifying that,

I went ahead with the install, and applied the latest mdac version (2.8), and ended up with 140 errors ...

Guess its time to go over everything with a fine tooth comb, I am obviously missing something ...

[lindborg]

What kind of errors? Many of the errors the import will note are simple DB inconsistencies that are common (i.e. owners for call handlers that are missing, links for one key mappings that are not valid due to deleted items etc...) - 140 is a little high but not out of the ballpark.

[colin.mcnamara]

I ended up rolling back to the 2.4.6 integration with our current phone system, and I think I know what happened.

1. when I ran the script for the first time it hung about halfway through.

2. Because I couldnt get access to voicemail, I was sure that the script had errored out.

3. I uninstalled unity, reinstalled unity, and ran the script. It hung right before finishing.

4. I said screw it, blew the entire installation away, reinstalled from scratch, ran the script, everything worked fine.. however I only ended up with 66 users migrated over, (with 150 subscribers showing showing up in the sa).

5. I reloaded, changed the name of the exchange server (I am working on a VM only, local exchange) and got 150 errors.

I spent 2 days on flights to get back from boston, and had a chance to look over logs and think.

Why did it error out in the first place ?

I found out later that one of DNS servers at corporate was having issues, down up, rebuilding ..

When I ran it a second time, it imported those 66 users that it hadn't gotten too, that makes sense now too.

When reloaded the server completely, and ran the script, I believe it was seeing in AD that the accounts were created, supposedly had a mailbox (showed up in AD even though that server / storage group was gone). Showed up with 150 errors (total objects). I am guessing that this makes total sense.

I have the old voicemail up running, and integrated

I have the new voicemail up running, and integrated on another pilot point, waiting for the script to be run,

I need to clean up AD, take out the references to mailboxes that don't exist. and run the scripts again.

My questions,

1. If I run the DB import on the 4.0(3) while its on the new pilot point, will it break the import?

2. Can I patch 4.0(3) with sr1 prior to running the DBimport?

3. What are the operations that the dbimport script performs?

4. In the script you mention that a user is "Stamped" as a unity subscriber.. where is this "stamp located"

5. Is it better to migrate the exchange mailboxes to the new store first ? (using the migration tool in sp2) or to let the migration script create them?