I have a weird issue. I am using Cico Unity 3.1.5, Win 2k SP2 and Exchange 2000. The process for creating the distribution list was pretty straightforward. In order to save myself some work, I tried to reuse the default Allsubscribers list instead of creating a new one. I assigned it an extension so that it could be easily accessible over the phone. However, for some odd reason, no matter how hard I tried, I just could not add some additional users to the list. This was a problem I had previously with 3.1.3 ( there is an existing post for this problem where Unity generates an error) but this disappeared after the upgrade to 3.1.5.
I have now decided to import the All Subscribers list from exchange. The problem I have now is that I cannot remove the extension I used for the default list. I need to use this extension for the new list. I am aware that I can not delete this default list but is there a reason why it can not be modified?
Thanks in advance.
What happens when you try to modify that list? Is there an error message, or does the change just not take place?
As you have suspected, there's no good reason why Unity would disable the ability to change that field. There's a couple of routes that we can take here:
1. Change the ciscoEcsbuDtmfId on that DL in Active Directory and let that change replicate over to the Unity server. This approach would need a low-level directory editor like ADSIEdit. The drawback to this is that we still don't know why the SA change doesn't work.
2. Gather some traces to figure out what's going on. Since I'm not sure where this is breaking, we'll need to gather several traces and post them here. This is a little more work, but we can get to the real cause as to why this is happening (or, not happening) Those traces would be:
1. AlCommon 10
2. AvRdbSvr 10
3. Daldb 10
4. Doh 10
5. AvDSAD (everything)
If you can reproduce the problem and post the AvCsMgr and AvDSAD traces, I'll take a peek. And out of curiosity, is the Unity sever in a multi-Domain environment?
It is in a single domain environment. Recreating the problem is not a big deal; I can not do anything on the list. I will get those traces and post them here tomorrow. I am currently out of the office.
Thanks for your help.
This is really weird. I went into the SQL database using Enterprise Manager and was able to make the change manually. This is what the SA is supposed to do albeit in a more refined way.
I will get the traces as soon as I can.
That's not weird at all. When changing that field from the SA, two things need to happen: 1) the change is made on the object in the directory and 2) the same change is made in SQL. So when the SA tries to change the DTMF ID, it's not just simply changing stuff in SQL, there's more to it.
By not getting the change on that object in the directory (which will not happen by simply changing the field in SQL), I'd suspect that when the Directory Monitor recognizes a directory change on that DL has happened (some one was added to the DL), the DTMF ID that resides on the object in the directory will over-write the change you made in SQL.
Simply put, the directory attribute and the SQL field need to match.
Thanks for explaining that to me. However, the change in SQL seems to be working fine.... I made this change about eight hours ago and it is yet to be overwritten by Directory Monitor. Once I made the change in SQL, it was reflected in the SA and it has remained so ever since. From your explanation, it seems I only need to be concerned if I make a change to this particular list through the SA (which will cause an overwrite in SQL). Well, the major problem I had was that I was not able to make any changes to the list anyway. I have decided to use the distribution list created by Exchange in AD for this purpose.
Is this indicative of an anomaly in the system?
Thanks for your help.
"From your explanation, it seems I only need to be concerned if I make a change to this particular list through the SA (which will cause an overwrite in SQL). "
No, my concern arises from when something changes on the DL in the directory (adding a user in the SA make Unity go physically out to that DL and adds a user, that'll make a change on that DL). If you change something on that DL manually, say from AD Users and Computers, I'm kinda expecting that "old" DTMF Id to come back.
Additionally, if you can't make changes to the DL in the SA (which will boil down to the AvDSAD service writing to that object in the directory), I'm not really expecting Unity to be able to add them to DL in the directory either (which also boils down to the AvDSAD service writing to that object in the directory) .
So, if I understand correctly, as long as I leave this DL as is, the changes I made in SQL should be fine?
That is correct. Bear in mind that there are things that can change that DL that might not seem like it. For instace, deleting an AD account that's on that DL will do it. Unity will recognize that change and sync back in the "old" DTMF ID.
I forgot if I asked this: If you add a subscriber to the SA and that subscriber's template calls for them to be added to this DL, do they actually make onto the DL in SQL and the directory?
Prior to upgrading to 3.1.5, I had this problem with the users not being added automatically to the distribution list. It always came up with an error message saying "Subscriber created but not added to the distribution list." However, I could add them manually. The error disappeared after the upgrade. Now it seems that when I try to add missing users manually, it just does not work.
Yeah, that's why I had suggested setting some traces earlier. There's something that's just not right going on. Without those traces, I can't really tell you why it's not working as expected.
So, to clarify about manually adding the users to the DL, do you mean through the SA, or through AD Users and Computers?