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?
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.
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?
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...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.