Directory Handler PDL Search Scopes

[bbenner]

Unity 4.0(4)SR1 w/ failover, unified.

What are the dependencies Unity requires to be able to search the members of a PDL from a DH? I've got 4 DHs with 4 different PDLs as the search scopes, and the behavior is as expected. I've got 4 other DH's with 4 different PDLs that searching does not find any of the members - there are no matches. I can place the members of a successful DH/PDL combo and use the PDL as the search scope for a failing DH with success. The problem follows the PDL.

What traces would be useful in finding the deficiency in the searching method? Could this in any way be a Unity born config issue, or is this most certainly an Exchange and/or AD dependency?

Thanks

[lindborg]

Well, it can take Unity some time before it "flattens" a scope DL (what we call public dls that are assigned as a scope limiter on name lookup handlers). Since we have to walk through all members and sub members (for included DLs) and such, this is done in the background and can take some time (hours) before it updates the directory with the info. If you were assigning a DL and then calling in after a couple minutes it's very likely this had not yet completed. It's much too directory/CPU intensive to be kept up to date all the time on the fly.

So if you're putting DLs into a name lookup handler, taking them out, testing etc... it's highly likely you never let this process complete. If you've assigned a Public DL to a name lookup handler and let it go, say, over night and it's still not flying right, then something is going wrong with the "flattening" process. There were some bugs in and around this area back in 4.0(5) and earlier so it's possible you're seeing something along these lines. You'd see errors in the event log relating to directory recursing stopping/failing or the like - so if it's not working after giving it time to flatten the list, check your application event log for errors.

[bbenner]

I've been troubleshooting this for about a week now, and have seen the same behavior out of DLs I've let replicate for 2 days after making adjustments. So I feel confident that I've waited enough to eliminate the flattening process.

I don't see any event logs regarding the directory recursing stopping/failing during the testing of the failed queries.

Using ADSIEdit, what attributes should I check to be sure the DLs are provisioned correctly to allow Unity to search? I've compared a working DL to a broken DL, and found that all of the ciscoECSBU attributes matched. I don't know what other attributes to compare that would affect the DL search scope. My Exchange admins haven't been able to come up with any traces or captures that could give us any insight, and they 'swear' they haven't made any changes that could have affected this behavior.

I can't get a DL to break once it works.

I can't get a DL to work once it is broken.

DLs either work or don't upon creation.

All DLs I've created since some date have all been broken, all DLs before this date have all worked.

You mentioned a bug with 4.0(5) and earlier - is the bug fixed in 4.0(5)? If not, when is the bug fixed?

Thanks Jeff.

[lindborg]

First, nothing in the directory is going to be the problem. Unity only "tags" objects in the directory like branding cattle for DLs - it just identifies which server imported that DL is all - all Unity servers can see it.

The directory syncher process is the culprit here - it should pick up that DL and process it's members and dump them in the ADMonitorxxx tables in SQL for UnityDB. That's obviously not happening for some reason. DirSync diags may clue you in but off hand I'm not sure which ones you want to turn on without looking into it a bit more than I have time to do right at the moment.

If I remember correctly the bug I'm thinking of involved the directory syncher tripping up on distribution lists with certain characters in their names ( "\" perhaps?) - so all DLs that came after that in the list would not get touched and all those before that first list is choked on would be processed. This may explain the behavior you're seeing, but I'm not at all sure this is what you're running into. You'll have to search around in CDETs I think. I don't recall where it was fixed or if there was an ES for it or what...

Sorry I can't be more help here - little pressed for time today. You should probably open a TAC case for this one if you haven't already anyway...

[Christopher McAlpin]

You may be running in to the following:

Scope DLs with over 1000 members fail to sync

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsb26256&Submit=Search

Members are dropped from Scoped DL Members table on directory synch

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsb56874&Submit=Search

The fix for these two issues is included in 4.0(5)ES60, and 4.1(1)ES23,

[bbenner]

Thanks Jeff and Chris. I'll be upgrading to 4.0(5) or perhaps 4.1(1) sooner than later.