The Delete Subscriber example application shows how to go about properly deleting a subscriber in Unity without causing potential “broken links” in the database as removing users in the SA is prone to do. It also demonstrates how you can use a stored procedure flag to actually remove the directory and mail accounts attached for the subscriber in addition to the subscriber information in Unity. This option is not available via the SA for obvious security issues but for folks that want to do their own provisioning applications this is open to you.
This tool must be run on the local Unity server – there is another programming sample on www.CiscoUnityTools.com that shows you how to find and connect to remote Unity servers. The interface in this example is very basic. I didn’t spend any time getting fancy with table outputs that look nice or the like, this is a stripped down UI that’s simply a vehicle to show you how to do this type of thing in your own applications.
When you first fire up the tool it just dumps the aliases of all the subscribers on the local Unity server, nothing fancy. For a production application you’d probably want a slick grid control here showing first, last, display names, extensions, alias etc… but for portability and simplicity I’m keeping it real basic here.
When you select the alias of a user you want to delete and hit the “Delete” button the following rather ungainly form pops up.
The information at the top is more complete identification of the user you’ve selected to delete. Everything under that is telling us what to do with links to this subscriber you’re about to remove. I’ve provided a very limited set of choices here. In a production application you’d probably want to implement a wizard (as the Global Subscriber Manager tool uses for this very purpose) or have a set of predefined settings here that are simply applied when you delete subscribers without having to hassle the user about it.
You need to select a subscriber as the recipient/owner replacement and a call handler for both the after message action and as the exit destination for subscribers or name lookup handlers should they have been pointing to our soon-to-be-deleted subscriber. A user input key will be set to “ignore” if it’s pointing to this subscriber, I don’t allow a choice there. Similarly the after greeting action is forced to “Take a message” if it happened to have been set to go to this subscriber.
There are, of course, a number of other options you can provide for all of the items here and for a production application that’d probably be a pretty good idea. The main story here is that by getting this information and using the proper stored procedures you’ll keep your database clean when deleting subscribers and other objects in the database.
NOTE: There is the nifty little “Remove mailbox and directory account tied to this subscriber” at the bottom. Use this with extreme caution as it will remove the objects in the mailstore and directory associated with this subscriber and you cannot get them back. The Unity SA does not offer this option for a reason – it’s extremely dangerous stuff. However, since I get the request often I’ve included it in this example.
This example application doesn’t generate a report showing all the objects that were updated with the deletion – if you read through the source code, however, the comments will show you where you can do this if you want to pursue that.
This tool need to be run on the local Unity server
This example is coded and tested against Exchange 2000, however it should also work for Exchange 5.5. It will not, however, work properly with a Domino back end.
Upgrade to 4.0(2) or later. There are several parts of this test application that will not work properly with the 4.0(1) version.
You can get updates to this code example and all other samples and tools at www.CiscoUnityTools.com
Updated with release of 4.0(3)
Updated with release of 4.0(2)
First ship of example code
© 2003 Cisco Systems, Inc. -- Company Confidential