I have a unity box that has got some interesting problems. It was a recovery from an old unity box that drowned in the hurricane katrina mess.
Now, the rebuilt box (not sure who did the restore, so I don't have history on it) has some strange characteristics:
- in sa, search for users will not find all users that exist. some users can only be found if you check "search all cisco unity server", even though there is only one server.
- in global subscriber manager, the tree shows Global -> unity -> unity -> default(primary)
- most users show up under unity (the second one), but a set of users show up under default(primary) and these users are the ones that you can't find under normal searches
- any user that is listed under this default(primary) can be found with the all unity box search, but when you click the link in sa to edit, all links in the left frame are greyed out and the page shows "The page cannot be displayed" and nothing else.
- any user accounts that have the same extension as the "ghost" users located in default(primary) cannot be dialed from within unity.
- the users in default(primary) cannot be deleted in global subscriber manager (which would obviously be the best way to deal with this)
- there are users in both locations that have duplicate extension numbers
Does anyone know what could be happening here? The only issues I see in the event logs are that the unity server cannot contact the licensing service. Nothing that shows a directory problem or database problem on the Unity box...
Right off hand it sounds like some of the users in your directory are still bound to an old location object - every Unity install has a primary location object and, optionally, additional non-primary locations that define remote systems you can message with etc...
I'm guessing that during the restore (it'd hard to speculate here not having any details on how this was done) that DiRT was not used and the users that were in the directory already were left "orphaned" pointing to a location that no longer existed. Since each install of Unity gets unique IDs for all objects (including locations), depending on how they did the restore it would create duplicate users in the directory as you describe. That's just a guess based on the thin info I have to work with here.
If the backup had been done with DiRT, the restore process would have made sure the directory binding resulted in existing users "repointing" to the new Unity installation such that this would not happen - I'm guessing that was not the case and someone just put a manually restored system back on the directory and it synched into AD causing the mess you have now.
Unfortunately there's not a lot of clean solutions I can suggest here without knowing a bit more about what state the DB and directory are actually in.
I'd try using the Remove Subscriber Properties (aka Bunny Killer) on one of the users that's orphaned and seeing if you can import them again - you can find the latest version of the tool here:
Thanks, but I figured most wise decision there would be to call TAC and get it figured out. The origin of the problem is something that no one can really pinpoin (hear customer tension rise there), but the "ghost" users were actually in the global subscribers db table and not in the local subscribers table. We wiped the items in the global subscribers table that were not in the local table, then went and found the users and killed the bunny. After that, it seemed to be working fine.
Question for you: before fixed, we went into the global subscriber manager tool and saw only the "ghost" users in that container named "Default (Primary)".
What is that? In the GSM, if you checked "normal" view, you would see this, if you checked "department" view, you wouldn't. Can you explain what that container is and what should be there?
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
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...