The first error is serious and there's no "standard fix" for it - if a subscriber is missing their link to their primary call handler you'll typically end up having to blow them away and recreate them from scratch - that's not something you see too often.
The 2nd error could be benign - on an Exchange 5.5 system you can have a message store account but no SMTP address advertised - with Exchange 2000/20003, however, that usually indicates a problem with the RUS service not completing it's message store creation work in a timely fashion - are you still connected to 5.5 or did you change over to 2000 in the process of upgrading to 4.0(3)?
Also, be sure to fetch the latest dbWalker - I believe the first error in the latest version will include text telling you to remove the user and reimport/recreate them from scratch. You can get the latest off www.CiscoUnityTools.com
The site is in the process of migrating from Exchange 5.5 to 2000, and does have people homed on both machines at the moment. I believe the three offending subscribers are still on the 5.5 server.
As for blowing the subscribers away and recreating them, it would be a good solution (and we wouldn't even have to recreate them, as they're not used). However, the Unity Administrator won't let you do it -- it shows an IIS error when I try -- and dohPropTest doesn't work, either. It appears to delete the subscribers, but then when you go and search, they're there again immediately.
well, first see if any of those three users are being referenced elsewhere - for instance as message recipients, owners of handlers or as sole members of distribution lists like the Unaddressed Messages (i.e. if one of these accounts in the example admin you'll want to take care in replacing references to it that will be broken with its removal).
If you're comfortable with that you can just delete them in SQL directly - go to the Subscriber table in the Enterprise admin under the UnityDB database, find the user in the table and delete it - all the referencing tables (i.e. notification devices/rules, MWIs etc...) will be removed automatically.
You can do this via the MS Query Builder or using CUDLE's Query View by using a command like this:
That means there's a stranded row in the DTMFAccessID table in the UnityDB database - it's not critical (i.e. if the ID in that row had conflicted with any other objects it would have been reported seperately).
The new version of dbWalker that QA is testing includes an option to automatically remove such stranded rows - these can happen as a result of objects that weren't removed cleanly for one reason or another.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...