Does any one have any tips on how to migrate about 70 3.13 users to a totally different established 4.0 server? Im not sure DIRT would be an option because I dont want to change any settings on the 4.0 server. I would like to maintain the user's recorded voice prompts and unity pins if possible. As a side benefit It would be nice to keep the ADpasswords. An LDIF export and import might do that trick...
No, DiRT isn't an option here for a couple reasons... first you can only import into the same exact version you exported from - you can't migrate versions AND import system info all in one shot... I know this sounds like a cool idea but the thought of actually doing this work makes my skin crawl... not cool.
Also, it gets the entire system info, not just user data which sounds like what you want.
We're about to release a version of Global Subscriber Manager that lets you move users around between Unity servers in their entirety - however this only works for 4.0(1) systems and later - you can't move between 3.x and 4.x systems because of SQL differences and a number of off box support issues.
Short story - you'll have to uninstall those users and reimport them on the 4.x system. An LDIF dump isn't going to do it for you here - phone passwords aren't carted around in the directory, they're stored as a one way hash in SQL. you can save off their greetings and voice names, of course, and paste them back in on the imported users on the 4.x system... that's probably about as close as you can get to a "migrate" between systems at the moment. This will be much nicer for 4.x systems and later moving forward.
What about the use of the new Bulk Admin tool? I have a 3.1.4 server with on-box Exchange, and the new 4.0 server, VM-only and Ex2k on-box, is in the same AD. I can certainly perform this manually, I'm looking at about 130 users, but it woul be nice to, say, use Exchange to change their Message Store to the new server, then use the Bulk Import tool to import them into Unity. Dunno if this would have a problem with the SQL issue you mentioned above, just checking to see if there is a faster method available than manual. Thanks!
The Bulk Import (there is no bulk Admin tool - I assume this is what you mean) will let you pull in lots of folks from the directory in one shot but, of course, you lose their greetings and voice names in the process - and it requires you remove them as subscribers on the other box first - there's a bulk subscriber delete on CiscoUnityTools.com that can help here.
However if you were trying to save greetings and voice names there's really no alternative for this scenario than moving folks by hand or manually copying the \streamfiles directory off somewhere and manually pasting those WAV files into the newly created users on the 4.x system.
This is why me and my team have been working on the "move user" function in the GSM for 4.x - for load balancing and the like it'd be real nice to point and click and have everything moved for you in one shot.
yup Bulk Import ... it's manic here ... here's the rub ... since they aer already using Exchange as an e-mail system, I cannot import them as usual users, since the import would bring along the e-mail message store as well ... the solution we've used was to make the users New Subscribers in the 3.1.4 system and tag their NT Alias with "vm-", so really the users have two aliases, one for e-mail and one only for VM ... I will move the users manually as the scheme seems to be solid, if not quick ... I hope you have quick and solid success with the "move user" construct in the GSM! keep up the great work, and thanks!
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.