Solved: Moving a DTMFAccessID between servers in a Unity cluster

paulw.wilkinson · ‎02-26-2009

Hi,

We have a Unity 5.0(1) cluster with two servers. We are using the stored procedures to perform administration.

We are having a problem where a user gets deleted from one server and then we try and provision a new user on the other server with the same extension as the deleted user.

It seems that the (deleted) extension is still in the DTMFAccessId table on the second server.

What we see is as follows:

The user is created on server 1 using sp_createSubscriber.

The user's assigned DtmfAccessId appears in server 1's DtmfAccessId table straight away and in server 2's table after about 15 minutes.

When we have to delete a user we call sp_modifyScriber to set DtmfAccessId to NULL, request a directory sync, wait until the dirsync ticket completes and then call sp_deleteSubscriber.

We can then see that DtmfAccessId has been removed from the table on Server 1, but it never seems to disappear from Server 2.

This then causes an error if we try to provision a user on server 2 with the same extension.

Has anyone done this sort of admin in a multi-server cluster? Any ideas why we are having problems?

Thanks,

Paul

lindborg · ‎02-26-2009

You shouldn't have to force the DTMFID to null first - I've never done that on any of my tools. I can imagine this would be screwing up the relationship between the subscriber's primary call handler and the DTMFAccessId on the remote server, but that's just a guess.

NULL is an invalid value for a DTMFAccessID I believe even though the stored proc lets you do that - Unity doesn't have strict enforcement of such things.

Out of curiosity is the DTMFAccessID associated with a subscriber/handler object on the 2nd server when it's in that state? Or does it show up as an orphan? So the delete request did synch across but the association with that extension number was lost and so the delete didn't clean it out. Something to check for anyway.

View solution in original post

lindborg · ‎02-26-2009

You shouldn't have to force the DTMFID to null first - I've never done that on any of my tools. I can imagine this would be screwing up the relationship between the subscriber's primary call handler and the DTMFAccessId on the remote server, but that's just a guess.

NULL is an invalid value for a DTMFAccessID I believe even though the stored proc lets you do that - Unity doesn't have strict enforcement of such things.

Out of curiosity is the DTMFAccessID associated with a subscriber/handler object on the 2nd server when it's in that state? Or does it show up as an orphan? So the delete request did synch across but the association with that extension number was lost and so the delete didn't clean it out. Something to check for anyway.

paulw.wilkinson · ‎02-26-2009

Hi,

Thanks for that. We assumed that we needed to remove the dtmfAccessID because it wasn't being cleaned up properly. It turns out that this wasn't the case.

The problem was caused by the AD Sync service running under an account that didn't have correct AD permissions. Once we addressed this the global subscriber and dtmfaccessid on the second sever was cleaned up correctly.

Thanks for your help

Paul