Not picking on you Al. However, Exchange people in general are GUI junkies. That is how they were born and bred by MS, it is not entirely the fault of the admin. And if they were command line junkies in a life prior to Exchange, MS thoroughly beat it out of them with the dearth of any serious command line tools for Exchange. Heck the more I deal with Exchange the more I find myself in LDP wandering around versus command line because of the horrible layout in the config container. I will probably end up writing a GUI version of adfind just because of Exchange and my level of irkedness[1].
Anyway, I will let you answer if you are a GUI junkie or not, I have never seen you work so I don't know if the command prompt windows out-number your GUI windows or if you have a problem with a user if you first go to aduc or the command line. Not trying to insult you or anyone else, if someone likes the GUI, they like the GUI. I don't think admin work is generally as efficient if always done with the GUI but that is for each admin to figure out on their own. If you have two admins side by side who are both just as good at solving problems but admin 2 takes 30 seconds to add some 50 new OUs and admin 1 spends more time trying to get ADUC open to the right location you can see where that is going to go long term. I am glad that Microsoft as a whole realized prior to Windows Server 2003 that the command line was important. It seems the Exchange team has made that discovery now for E12 though I still question some of what I have been seeing as they still seem to be dragging the GUI fat for info retrieval with them with some of the MONAD stuff, only there is no GUI to require it. As for there being a good reason for having funky characters and spaces in RDNs I would always question the reason it was said it was needed. I haven't seen a good reason yet for a comma or a space in an RDN other than to make it pretty. Again, these are admin level constructs, they don't need to be pretty. That is why you have a displayName attribute in the first place. Your uniqueness argument confuses me. If you have multiple jsmith IDs around the world, you already have a uniqueness issue. The solution is to not have multiple jsmith IDs. You have jsmith, jsmith1, jsmith2 or some other mechanism for creating unique IDs. Are you suggesting we use special characters instead? Obviously I have some level of Enterprise experience, using display names as the CN doesn't get you uniqueness, heck when I was at MSU there were two of us on campus with EXACTLY the same first, middle, and last names. Heck of a coincidence. The only people who had an issue with it was the postal folks since the primary uniqueness key outside of address was display name. So something addressed to my name at MSU actually had two possible delivery locations. It had to have more info like building or room and building to definitely get a unique hit (and even then they often screwed up the delivery). I think having Display Names and the CNs the same are a generally bad idea due to the space and special character issues as well as uniqueness issues. The display name was never thought of to be unique, it was simply a nice name for display in applications where normal users would be seeing people's/group's names. The primary Enterprise mechanisms I have seen for cn naming of users has been to either use the sAMAccountName which is based off of some centralized naming process, using the UPN/primary Email address as the cn, or a numeric value that is assigned to each user as a "primary key" for the directory. I fully agree that programmers should take it into account. But the issue isn't generally programmers, it is what I call "coders" which way outnumber real programmers. Coders, by my definition, are people that don't have a real understanding of programming concepts[2], they just figured out how to use a compiler or a scripting tool and often simply slap code snippets that they have found together in hopes that whomever they got the snippets from knew what they were doing and would catch issues that the coder isn't aware of. The newsgroups are full of issues where the person scripting/coding had no real clue what they were doing but could have been avoided the issues they hit had the naming structure been worked out to be more conducive to easier coding. When you start throwing commas into the mix coders have to start being aware of whether they need to escape that comma for the specific thing they are doing. Even still, if you are asking a user for something, is the user smart enough to escape their own commas or are they cutting and pasting from some other tool that is? You as a coder or as a programmer can't just assume it is one way or the other and try to manipulate the input on best guess, you have to use it as it as is. For instance if you see something\a did the person really mean to escape the a as a HEX representation of the binary value 10 or did they forget to escape the slash? I have fought with this in my own tools. Cover for people who have no clue or piss off people who do have a clue and handle the situation themselves? For instance... Is there a problem with this pseudo-code _VldapserverV_=someservername _VbaseV_=some branch in namespace _VscopeV_=subtree _VservernameV_=<get servername from user> _VqueryV_="(&(objectcategory=person)(objectclass=user)(homeDirectory=\\_Vser vernameV_\*))" Submit_Query [_VldapserverV_,_VbaseV_,_VscopeV_,_VqueryV_] Does it work for all name values that could be submitted, say all valid servers are in a dropdown and the user can't type their own names. Given all the possible valid servernames would this code have a possible issue? Yes. If the server name starts with the characters A-F or 0-9 (Hex character set). Correct way to write that filter is (&(objectcategory=person)(objectclass=user)(homeDirectory=\5c\5c_Vservername V_\5c*))[3] I have seen that one in the wild a ton of times. What is the general solution I have seen? Why to forget about the slashes and simply wildcard the first part of the query like (&(objectcategory=person)(objectclass=user)(homeDirectory=*_VservernameV_\*) ) Yeah that is efficient[4]. I would be willing to bet lunch that there is some "professionally" written code somewhere in this world that does exactly that. Why? Because I have seen it multiple times in non-pro code and people like to cut and paste. In many cases the difference in professional code and other code is that you pay for one and not the other. So how do you handle it generically? Was the double slash to escape the second slash or was double slash intended so it should be escaped to \5c\5c? Or was it supposed to be slash and then an escaped hex A through F? Since you know specifically what this field is for above you can add extra logic to protect against bad things, that doesn't work in the generic case though say where someone is constructing the LDAP query or some portion of it. I know, this doesn't apply to DNs... But doesn't it? You can query on DNs and you can query on the various RDN values, they have to be handled in different ways. It can be confusing for people who do understand what is going on let alone those that are simply trying to make someone else's c#, perl, or vbscript code work. Quoting generally isn't too confusing as long as you are aware that if you have special characters at the command line or spaces, you need to quote the params. However, I get at least literally 800-1000 emails a year from people who say one of the tools isn't working and it is simply due to the fact that they have no idea that you need to quote params with spaces or characters such as pipe or ampersand, etc. It especially makes me laugh when they talk about what an expert they are and how they can do anything so there is something obviously wrong with my program because if they can't get it to work, it just must be wrong. ;o) joe [1] It's a word now, deal with it. ;o) [2] I certainly don't believe you have to be formally trained to become a entry level or even great programmer. But someone who has learned on their own is often not in a position to have learned programming fundamentals as that probably wasn't on their goal sheet. If they are really bright and have been doing it for some time they probably will have developed a sense of what those fundamentals are or may be though through trial and error or looking at issues they kept hitting in an objective scientific manner. [3] If anyone just said "huh", go here http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/s earch_filter_syntax.asp [4] http://www.google.com/search?n&q=define%3A+sarcasm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, October 21, 2005 11:20 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Interesting Scripting Task..... I'm sure you're not indicating that you believe I am a GUI junky, but I'll leave that conversation for another time :) I disagree joe. There will always be a reason to use special characters in those fields. While I *can* change that, and often should find something that is unique across all OU's regardless of the immediate need (think about a worldwide deployment that has more than one jsmith; they should have a guaranteed unique logon name at the minimum because you never know when they plan to use UPN or plan to move to another location that breaks your OU structure. I know there are other ways to modify this behavior..but a logon id should be globally unique wherever possible; that would be a best practice in my mind.) I may as well just bite the bullet and realize that I'll often need special characters and that it could show up in my DN. May as well code for that eventuality and be done with it. Worrying about special characters in a DN is well and good, but I don't see that as a best practice or a requirement. Just a "nice to have" if you feel like programmatically handling admin and get to a point where you want to be extra efficient (or lazy) with the number of keystrokes. Should displayname and CN be the same? Depends on the person being asked. It's a LDAP thing. And ldap based directories face the same issue. 5.5 and ADC are things that can be modified. Done that many times. Also had to go back and modify the DN's many times for many customers, but that's not as a best practice. That was because they didn't have international needs and because they had "efficient" programmers. -ajm >From: "joe" <[EMAIL PROTECTED]> >Reply-To: ActiveDir@mail.activedir.org >To: <ActiveDir@mail.activedir.org> >Subject: RE: [ActiveDir] Interesting Scripting Task..... >Date: Fri, 21 Oct 2005 10:06:54 -0400 > >I am against commas and spaces and other special characters in any >attributes that get used for RDNs. It shouldn't require quotes and escaping >to be able to use a DN in my opinion. Since those names are seen by admins, >they don't necessarily have to be nice. > >If you make an application and you build a container/OU structure in your >app. Allow people to specify a different structure that doesn't have >spaces, >commas, and other crap in it <cough Exchange cough>. > >Folks who tend to like that putting that stuff in DNs (and folder and file >names as well) have normally, from what I have seen, spent most if not all >of their time in the GUI. > >I completely agree that displayname is fine and quite normal with commas. I >much prefer see names in the GAL as last, first than first last. > > >The 5.5 issue is with the ADC. You can disable the ADC from changing the >CNs >like that. > > > joe > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick >Sent: Friday, October 21, 2005 9:40 AM >To: ActiveDir@mail.activedir.org >Subject: RE: [ActiveDir] Interesting Scripting Task..... > >Last I checked, it's not a bad practice to use commas. It's a bit more >work >to use the names if you have to escape the commas, but it's not a best >practice. In fact, in a displayname, I do want to use commas, but I think >you meant in the CN you wouldn't want a comma. I frequently do want them, >but mostly because I've always worked with Exchange and the upgrade from >5.5 >will often cause that. It's valid, it's not against any best practices, >but >it can be a pain to work with. > >You found a workaround, but I wonder if there's another way to handle the >special characters? > >Just curious mostly. > > > >From: "Smith, Brad" <[EMAIL PROTECTED]> > >Reply-To: ActiveDir@mail.activedir.org > >To: ActiveDir@mail.activedir.org > >Subject: RE: [ActiveDir] Interesting Scripting Task..... > >Date: Thu, 20 Oct 2005 15:16:59 +0100 > > > >All, Just thought a quick update might save a bit of pain for those of > >you that ever want to use the CreateXMLFromEnvironment.wsf and > >CreateEnvironmentFromXML.wsf scripts from GPMC. I found a snag where > >CreateEnvironmentFromXML.wsf can't import user accounts where the name > >contains a comma (and probably othe special characters). I know it is > >bad practice to use these in display names, but it is supported by > >dsa.msc and so inevitably has been used. There are a few ways around > >this, I got past it by changing line 596 from > > > >szName = User.Get("name"); > > > >To > > > >szName = User.Get("samAccountName"); > > > > > >This could be done a lot smarter I know, but for a quick fix this works > >and is all I need for now. > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Smith, Brad > >Sent: 12 October 2005 13:16 > >To: ActiveDir@mail.activedir.org > >Subject: RE: [ActiveDir] Interesting Scripting Task..... > > > >The script Darren pointed out seem to be working just fine, now I need > >to configure a decent migtable ;-) > > > >Thanks again for the heads up Darren. > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Darren > >Mar-Elia > >Sent: 10 October 2005 17:40 > >To: ActiveDir@mail.activedir.org > >Subject: RE: [ActiveDir] Interesting Scripting Task..... > > > >Yes, Microsoft has attempted it. Check out the scripts directory under > >the GPMC install. It has two scripts: > > > >CreateXMLFromEnvironment.wsf and > >CreateEnvironmentFromXML.wsf > > > >That do pretty much everything that you've described below. > > > >Darren > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Smith, Brad > >Sent: Monday, October 10, 2005 8:08 AM > >To: ActiveDir@mail.activedir.org > >Subject: [ActiveDir] Interesting Scripting Task..... > > > >All, > > > >I am pondering the possibility of automating the creation of > >development environments. The problem I am hoping to solve is that a > >lot of our testing needs to be done in an environment where all our > >Ous, GPOs, Groups and so forth are present. Recreating this is a > >nightmare, so to alleviate this I want to write an import/export > >script that dumps all the OU's, Groups, Users and GPO's (including > >security) and then restores them in a different target domain > >(different forest too). Has anyone attempted/achieved this before? > > > >Brad > > > > > >This email and any attached files are confidential and copyright >protected. > >If you are not the addressee, any dissemination of this communication > >is strictly prohibited. Unless otherwise expressly agreed in writing, > >nothing stated in this communication shall be legally binding. > >List info : http://www.activedir.org/List.aspx > >List FAQ : http://www.activedir.org/ListFAQ.aspx > >List archive: > >http://www.mail-archive.com/activedir%40mail.activedir.org/ > >List info : http://www.activedir.org/List.aspx > >List FAQ : http://www.activedir.org/ListFAQ.aspx > >List archive: > >http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > >This message has been scanned for viruses by MailControl - (see > >http://bluepages.wsatkins.co.uk/?4318150) > >List info : http://www.activedir.org/List.aspx > >List FAQ : http://www.activedir.org/ListFAQ.aspx > >List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > >List info : http://www.activedir.org/List.aspx > >List FAQ : http://www.activedir.org/ListFAQ.aspx > >List archive: > >http://www.mail-archive.com/activedir%40mail.activedir.org/ > > >List info : http://www.activedir.org/List.aspx >List FAQ : http://www.activedir.org/ListFAQ.aspx >List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > >List info : http://www.activedir.org/List.aspx >List FAQ : http://www.activedir.org/ListFAQ.aspx >List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
