I am getting ready to do a Unity 7.x to Connection 8.x Migration and I had a few questions. I know COBRAS does a good job of getting most of the data out of Unity 7.x and into the new system. Since we are moving to away from Exchange so I will need to export the messages from the mail store using COBRAS and the UnityMsgStoreSvc account.
How does the correlation work if you want LDAP integration for Unity Connection with AD? Meaning, do I need to configure LDAP synch first then do the COBRAS import or vice versa?
Unlike a Unity 5.x to Unity 8.x (windows version) migration, can you have both Unity Connection and Unity runing at the same time without causing any extension overlap issues?
Is there a good white paper on this process?
Check out these couple posts by Jeff Lindborg addressing your LDAP/COBRAS import question:
Not sure what you mean by extension overlapping in your second question. Unity and UC don't share a common directory (in your case. Now Unity 8.x and UC 8.x can be digitally networked, fyi) like you already pointed out, so any dial plans would be enforced by your phone system. Just be careful if you've got users existing in 2 places, MWI inconsistency is often a result of the old Unity server doing MWI resyncs for past messages, thus confusing the user if they have no messages in their new UC mailbox.
Hope that helps,
Thanks for responding!!
I am reviewing the training material on the Unity Tools Website. I am still unclear on the exact process.
1) Install 8.0 of Unity Connection, configure Call Manager intergration, Templates, COS, etc.
2) Configure LDAP sync and authentication as described in the docs. No data is being transferred yet.
3) Perform a full LDAP sync. This LDAP sync is just bringing data from the LDAP directory into a CallManager database on the Connection server. (There is a CallManager database on every Connection server, not just a co-res server.)
4) From BAT, export "Users from LDAP directory." This export is exporting LDAP user data from the CallManager database on the Connection server and setting an LDAP flag in the CSV file to "yes."
5) Edit the csv file to remove any users that dont need to be migrated to LDAP sync/authentication. If you want every user in the LDAP directory to be a Connection user, you skip this step.
6) Run BAT in "Update" mode and feed in the CSV file. The import associates Connection users with LDAP users and sets the LDAP flag in the Connection database to "yes." In effect, you're just using this import to update the LDAP flag.
7) Run COBRAS Import??
So, how do you make a LDAP User map to the Subscriber Data being imported by COBRAS! Am I missing something?
I see where the confusion may be coming in, I believe.
Here is the documentation that explains the ways to import LDAP users; either via "Import Users" method, or using BAT.
The process which you were outlining lines up with updating/converting existing local Connection users with LDAP contained in the document above under the section "Integrating Existing Cisco Unity Connection 8.x User Accounts with LDAP User Accounts".
You've got a fresh installation, so you don't currently have any local Connection users yet, so using BAT to update users doesn't fit your scenario. Jeff suggests having the user-base in place first and already LDAP integrated (following "Creating Cisco Unity Connection 8.x Users from LDAP Data by Using the Import Users Tool" or "Creating Cisco Unity Connection 8.x Users from LDAP Data by Using the Bulk Administration Tool").
Have a look at the blurb here about what fields COBRAS will match to overwrite the newly imported LDAP users and update their data:
One thing I'm not 100% clear on, maybe Jeff can comment is the sentence:
"The LDAP integration feature (for instance to Active Directory) with Connection 7.0 and later requires that you import users into Connection from the LDAP connection you create FIRST before creating local users. This is not specific to COBRAS – if you create local users via the SA or BAT or any other process or tool you cannot then make them LDAP integrated later."
From documentation provided above, there is the section I mentioned "Integrating Existing Cisco Unity Connection 8.x User Accounts with LDAP User Accounts" which allows Connection users to be converted to LDAP integrated users.
Hope that helps,
OK..I think I got it now after reading some of the links you sent and thing about it last night. Here are some key points:
I would assume since I am doing an COBRAS Export from a Unity Server that has off box Exchange the users information should be roughly the same when I Import them back in Connection. Meaning, after I do the LDAP synch, make sure all the users are there, import them into Connection to create the local accounts that are LDAP integrated and then do my COBRAS Import they should match up! I will have to watch this very closely.
Any final thoughts? Does this seem I am on track?? Thanks for the help on this!!
One last question. During the Import to Connection, should you restore the following items since they already exist:
Would this affect any of the Call Handlers since they are on conflict when you try and restore them? Thanks!
Not choosing to import those shouldn't be a problem since they're default on UC as well. Having 2 of each (one from Unity and one from UC) isn't necessary.
In most cases you can leave them off but I do want to clarify here since a lot of folks seem to stumble on this concept...
you can go ahead and import those WITHOUT creating additional ones - that's actually the preferred method since it makes sure any greetings you have for system objects (i.e. the opening greeting call handler) match what was on the system you backed up (assuming that's what you want).
During the conflict resolution page you have the option to create as new, overwrite an existing handler or they'll be listed in conflict - you can choose to overwrite any handler you want - for the opening greeting for instance COBRAS will default to overwriting the existing opening greeting call handler unless you've modified the extension so it doesn't match or the like.
you'll do no harm to the handler if you do this - it'll just update the voice name and/or greeting and transfer rules etc...
Or you can choose not to import them (on the link resolution page you'll be asked to provide replacements - it'll default to the existing objects that have matching names).
either way works but I think overwriting the existing ones with what's in the backup is better style unless you have a specific reason not to.
Brad & Jeff,
Thanks for all your input. I am migrating my client tomorrow morning! Jeff, the UC Training videos were awesome! They helped tremendously!
Brad & Jeff,
On a high level can you explain the process that COBRAS Export uses to grab the voice messages from Exchange. How does it take the messages and import them in the MS Access DB?
We did our COBRAS Export last night and didnt realize that so many end users kept their voice mail messages for more than 60 days. We had one user that had 4500 voice mail messages. I just want to confirm on the dialog output on the COBRAS Export, if you see the user and the inbox says 4500 messages, I am assuming this is voice mail only messages. We checked the same user account on Exchange and it showed 13,000 items. I just want to make sure this correlation is correct? Thanks!
Ah, the joys of wide open message retention policies! I see this a lot in the field, trust me. I’ve run across 10 year old voice mails – I kid you not – some folks simply will never delete messages.
The COBRAS Export for Unity has a special provision for just this type of thing – you have the option of limiting the message backup to only messages created in the last X days (60 being the default but you can set it from 1 to 999 days). I put that in there specifically for this scenario.
You can’t rely on the inbox count reported by any client – it may or may not be accurate. COBRAS opens the message store going through the Unity MAL (Message Access Library) which is the same input the phone conversation uses to get at your messages. It then walks the entire message box (read and unread alike – no deleted items are walked) and if a message is a voice mail (emails, receipts, faxes etc… are skipped) the message is bundled up and packaged into the MDB file.
Unfortunately date/age filters are not reliable across different versions of Exchange and Domino so COBRAS has to trudge across the entire mailbox regardless of if you have the age limit applied or not – when the age limit is applied it fetches the message, checks the created time and if it’s older than the days set, it skips it and move on.
Anyway – that’s the idea – but you should seriously consider 1. Leaving messages in the Exchange mailstore for users and having them access them via another number after migration and/or 2. Only moving messages that were created in the last 30 or 60 days. With a monster mailstore like that you will simply not be able to move them all into Connection – there won’t be nearly enough room.
Yes, I saw those options but the client preferred to "grab" all the messages so we gave it a shot. We were only at 45% completed at 2:00 AM when we kicked it off at 10:00 PM. LOL
Anyway, if you set the COBRAS Export Option to the last 30 or 60 days will the backup time significantly improve even though you still have to walk the entire message box? I know it should take less time bundling the actual messages since you should have less. Does this also include any "Folders" the user has created under the Inbox?
It'll be faster for sure but I can't say how much - it does end up having to "touch" every message but the time it takes to actually extract the message parts and bundle it up into the MDB file is rather huge compared to the time it takes to just pull the header properties and check the created date.
No, the MAL does not allow access to anything other than the inbox and the deleted items folder - no folder access other than that is possible. COBRAS only walks the inbox (it does not look at deleted items).
If you create local users via the SA or BAT or any other process or tool you CANNOT then make them LDAP integrated later
I keep seeing this. I've attempted to upgrade a local user to an ldap integrated user without any problem - not sure what does the above line refer to?
I think that's a hold over from the older versions of Connection - it used to involve some unsupported DB operations to convert a standing user in Connection's database to an LDAP integrated user (user in Call Manager's DB which is running in a seperate instance in a Connection install and is imported into Connection's DB from there - all LDAP/AXL integrated users look like this). In later versions of Connection this got cleaned up so it's a supported operation now so these statements are no longer true.
that said, it's still much better style to create users first and import their data over them when using COBRAS for instance - while it's possible to import them first and THEN move them to LDAP integrated, it's smoother to go the other way around as a rule.