|
That’s just the thing. There
are way too many string choices. You have general string, teletex,
printable, IA5 and Unicode. I basically don’t have any idea when it
would be more appropriate to use the ones besides Unicode. Unicode is by
far the most prevalent in my directory although teletex gets used a fair
amount. Printable and IA5 are pretty rare. General is never used at
all, so I assume it is only the schema for standards compliance. I take your point about case sensitive as
that is sure to cause chaos with search filters. It seems like mostly
Exchange attributes that use the case sensitive versions. Does someone have a clear use case on when
to use the non-unicode syntaxes? Joe K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe I am not sure it is limited to SAM, I
think it may be when it is likely they will be doing comparisons and modifying
by a delta or finding a delta. I could be wrong though. What kind of conversation on strings are
you looking for? Generally use case insensitive unicode strings. If you use
case sensitive get ready to hear Windows Admins/Devs screaming because they
don't know what is happening. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] My observation is that MS uses integer8
when they are representing OS data that is manipulated as FILETIME in normal
Windows routines. I’m guessing that the SAM functions use FILETIME
internally, so it was natural to store them natively in AD this way for
compatibility. They use the LDAP time formats when they
are creating attributes that try to match existing LDAP standards. Then there is the rest of the time in
between where I have no idea what made them decide to go one way or the
other. J I would love to hear how their schema designers actually make
these decisions. Maybe we can get someone from the product team to
comment (hint hint). I’d also love to hear a good
discussion on which string syntax to use in which situation. Good schema
design takes some real knowledge that isn’t that easy to come by.
It is a lot harder to dive into than SQL for example. Joe K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph I really appreciate all of the opinions on
this. I've been playing around with these different types in my
sandbox. I've used VBS, C#, VB.NET, and pretty much all of the languages
that we hack programmers use :) The generalized date type worked really
well. From looking at the base AD schema it appears that there is a
difference of opinion among the MS programmers because the use of these
different types is roughly the same. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe If you use large int use filetime - Number
100 nanosecond intervals from jan 1, 1601. There is some docs (in
fact I think there are some typos in Gil's book) that mention the 1970 date but
I am not aware of anything in AD that uses anything but filetime. http://msdn.microsoft.com/library/default.asp?url=""> If you use int8 and don't use
filetime, you will have some developer hunt you down most likely later on
because their generic function that works on all other int8's doesn't work
on yours. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph We are going to be modifying the field
programmatically so from what Gil said it sounds like the large integer method
is appropriate. As a follow up question, do you think I should use nano
seconds from the Jan 2, 1970 (UNIX style) or January 1, 1601 (The date used by
pwdLastSet)? From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Bingo, how is the data going to be used? I
definitely agree, don't come up with your own format unless you have some
amazing scheme that blows all of the other formats out of the water that makes
it the best thing to do. Not saying you aren't going to come up with something
amazing but I would guess the odds are against you. Anything you put into the
directory, keep it in UTC. Less confusion that way. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Depends on the domain of the date values,
and how they are used. If the dates will be passed along to other X.500/LDAP
type directories, you probably should use the Generalized Time syntax
(2.5.5.11). If the dates are manipulated programmatically, use the long integer
representation. Its pretty trivial to manipulate it as a date in your code. I'd
avoid using a string representation unless your code requires a funny string
format or unless it requires unusual date values like "today",
"yesterday", or "when hell freezes over" (we use the latter
for setting development dates for certain silly feature requests in our
products :) -gil From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph I'm
looking for some opinions on a schema extension. I need to store a date
type in AD. I figure I have several options. Store
it as a long integer. To determine the date the consumer will need to
count the nano seconds from a certain date (the way that pwdLastSet works) Store
it as a date type (which I've never used, and looking at the current schema it
appears that most people do not choose this option). Store
it as a unicode string and come up with a format like: YYYYMMDD[ss][ss]
Does
anyone have an opinion on how this should be done? Thanks
This
message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
Title: Storing dates in AD
- RE: [ActiveDir] Storing dates in AD joseph.e.kaplan
