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: [email protected]
To: <[email protected]>
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: [email protected]
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: [email protected]
>To: [email protected]
>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: [email protected]
>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: [email protected]
>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: [email protected]
>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/
