Ah I love this problem... Crappy apps can't do the right thing so the AD folks have to figure out a solution. I have been in this conversation so many times it isn't funny. I have seen it go several ways.
1. The AD Admins cave in and do whatever to help the apps. 2. The AD Admins tell the app folks they better get the app fixed or find another way. 3. Spin up another directory and sync the info into it for the apps that is more tailored for how the app wants to work. 1 and 3 both suck to me. But then so does 2 if the find another way is used. The best solution is to beat the vendor until they do it correctly. So the problem with #1 is that in large orgs, it usually won't stop with a single cname. You will end up spinning up cnames for all sorts of different occasions. DCs that are in a special site, DCs of a specific domain, DCs of a specific domain in a specific site, DCs that support LDAPS, DCSs that support LDAPS in a specific domain in a specific site, GCs, GCs in a specific domain in a specific site, GCs in another domain or other site, etc etc etc etc. This list is endless... This is why applications should do it properly. When I ran a large directory, people constantly came to us and told us we had to do this and we always said no. One UNIX application group actually sat down and wrote a tool that did the proper site based SRV record lookups. Had we crutched them, they never would have had impetus to find a good solution. When someone says do this for a short time and we will find a better answer, they won't. Barring that, I would rather see application integrators front ending their crappy apps with perl or other tools that do the lookups on behalf of the apps and populate the configurations of the apps. This can be done daily, hourly, weekly, whatever the app folks feel is necessary and they should be doing it in such a way that there is fault tolerance in case something changes in the time between the updates. AD Admins should not have to be worrying about this kind of crap. When a DC is down and having a problem the last thing they should have to be worrying about is manually updating DNS entries to protect crap apps. This can add to the support costs and downtime because in the global scheme of things, AD Admins should not be thinking about all of the various apps, they should be thinking about maintaining the service as a whole. It is funny because app groups can't be bothered to learn AD to figure out how to use it properly but expect the DAs to learn everything about their app and how it works with AD to make sure their app runs well. That is backwards... joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 12:09 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] LAG and LDAP queries I have a group of applications (ie. Sibel etc) running from Unix boxes using AD for LDAP. I'm wanting to put in a Lag Infrastructure. The queries from these APPs basically look at mydomain.mycomapny.com 389. That's about as smart as they get. So, I know this isn't a AD problem but if I want my lag I have to figure this out for them. I don't want one of the lag servers to return there query (stale info). I have read thew a couple of LAG threads here and not really found anything referring to my exact problem. I know I can kill all the SRV records and keep the windows boxes out but I have to keep the cname to let this replicate on schedule. Anyone tried something like putting in a DNS record with just the DC's they want to return queries? LDAPSERVERS.mydomain.mycompany.com Am I way off base(DN) sorry bad j/k List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
