Domain Controller version

  • 5.7K Views
  • Last Post 18 July 2008
dharding posted this 18 July 2008

I can use the following command to list all DCs in my forest, but what
command can I use to get the version (2000 or 2003)?



dsquery server -o rdn -forest



Devon Harding

Windows Systems Engineer

Southern Wine & Spirits - BSG

954-602-2469




This message is the property of Southern Wine & Spirits or its affiliates. It is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.

Thank you.

Order By: Standard | Newest | Votes
laurahcomputing posted this 18 July 2008

Is there any reasonable way to pull out up-to-dateness vector informaton? I
was playing around with different things but wasn't coming up with it.

- L

show

bdesmond posted this 18 July 2008

Look at the S.DS.AD classes - there are abunch of replicaiton ones ... might
be something there.


Thanks,
Brian Desmond
brian@briandesmond.com

c - 312.731.3132

show

listmail posted this 18 July 2008

Why? This data is in the directory, no need to go touch every DC which would
take likely minutes instead of seconds.

Run this against every domain (replacing the -b switch as necessary)

adfind -b dc=domain,dc=com -f
"&(objectcategory=computer)(primarygroupid=516)" operatingsystem
operatingsystemversion operatingsystemservicepack -csv


joe



--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm





show

bsonposh posted this 18 July 2008

Cause that is for the domain... he wants it for his forest.

show

dharding posted this 18 July 2008

Well, when you have some sites which work on their own IT schedule, it
can be tough to keep up. Especially in a forest with over 15 domains
and 50 domain controllers.



BTW, the powershell command worked great!



-Devon

show

listmail posted this 18 July 2008

Out of curiosity, how much faster was the perl script? I am wondering if it
hit the orders of magnitude prediction.


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm





show

bsonposh posted this 18 July 2008

@joe, I dont think anyone would suggest that you perl script wouldn't be, as
you put it "orders of magnitude" faster. Just more complex than needed :) by
the time you posted it the powershell script was done.

To be clear here... I am not entirely sure how the .NET call actually works.
It may very due what you suggest, but I am not certain.

show

listmail posted this 18 July 2008

Err didn't know it was a race Mr. Hare.

Kind of scary that you don't have an understanding of what your script is
doing... What if you had a couple hundred or even a couple thousand DCs, you
would have no clue how it would perform or what the possible issues might be
that it runs into. I am being serious.

joe

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm





show

bsonposh posted this 18 July 2008

joe... there are only a very few that know what the APIs they are calling
"REALLY" do. They can speculate, but unless you have source code access and
the ability to comb through 1000s of sources files there is a point at which
you need to trust.
Everyone that use adfind.exe has to place some level of trust in you.
AFAIK... your the only one with the source. Are you suggesting that everyone
stop using adfind.exe because they dont know how it works?

RE: What I posted. We have discuss this before. The impression the OP gave
was that he just wanted the information. I posted how I knew he could it do
it. End of story. Had he suggested this is something to be ran regularly
then performance would have been a consideration.

show

darren posted this 18 July 2008

Boys.now, go to your corners and don't come out until teacher says to.

show

irishbug posted this 18 July 2008

Zing!!!!! joe, your reply?

show

listmail posted this 18 July 2008

I feel for something like this in the generic case you should have some idea
at a high level such as, this reaches out to all of the individual DCs or
this makes a LDAP call to any DC in the domain/forest. If someone has a mom
and pop shop, true, they likely won't care because it won't matter either
way. But once you get into larger environments you need to be more cognizant
of what is going on. That way you can maybe give a caveat like... this
works, but in a larger environment there might be a better way or this will
go a bit slow unless you multithread it.

You seemed to indicate though in your initial post that you knew what was
going on. You mentioned getting the info from rootdse with simple scripting.
Then posted that script which I took to mean that was your way to script
going against the RootDSE for this info. Then you came back and admitted you
didn't really know how it worked.

Had you never posted the script, I simply would have said, going to the
RootDSE of every DC in the forest for this information is not an optimal
plan in any but the smallest orgs and would have suggested the same query I
did before (choose your query tool, you could probably even use PowerShell
to do it). Then you would have come back and said but he needs the info for
the whole forest, not just a single domain like that helped it make sense to
query every DC in the forest and I would have again said, so ping one DC in
every domain with the query...

BTW, the AdFind example is a bad example. It does an LDAP call, you know it
does, that is what AdFind does. ;) Anyway, you don't need source access or
the ability to read source to get a generic idea of what something is doing,
for something like this, just turn on WireShark and watch it.

joe


P.S. If the .NET stuff is using a couple of LDAP calls to the domains to get
the info instead of querying the RootDSE on every DC in a forest, excellent.
It shows exactly why folks who don't have a thorough understanding of the
things they are working with should use it. :)


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm





show

laurahcomputing posted this 18 July 2008

I was specifically looking for the PoSH answer, yeah. Having fun with S.DS,
and all.

show

bsonposh posted this 18 July 2008

I feel for something like this in the generic case you should have some idea
at a high level such as, this reaches out to all of the individual DCs or
this makes a LDAP call to any DC in the domain/forest. If someone has a mom
and pop shop, true, they likely won't care because it won't matter either
way. But once you get into larger environments you need to be more cognizant
of what is going on. That way you can maybe give a caveat like... this
works, but in a larger environment there might be a better way or this will
go a bit slow unless you multithread it.

BS: This is a one off command (not script really.) There no project or code
to be repeated. Why would you create a multithreaded app for a one time shot
at the information? Why caveat it? I simply posted a suggestion.

You seemed to indicate though in your initial post that you knew what was
going on. You mentioned getting the info from rootdse with simple scripting.
Then posted that script which I took to mean that was your way to script
going against the RootDSE for this info. Then you came back and admitted you
didn't really know how it worked.

BS: I am not sure we are on the same page regarding the flow of the
conversation. He asked how… I stated he could get the info from rootDSE, but
that would involve a script. He then asked for a command… I gave him a
command. We should get on the same page on what exactly defines a"Script." I
never stated nor indicated I knew how the command I posted worked. You made
that assumption and I never admitted to anything. I simply stated a fact.
There is a variety of ways to get the answer. I am not sure which one the
.NET Class uses.

Had you never posted the script, I simply would have said, going to the
RootDSE of every DC in the forest for this information is not an optimal
plan in any but the smallest orgs and would have suggested the same query I
did before (choose your query tool, you could probably even use PowerShell
to do it). Then you would have come back and said but he needs the info for
the whole forest, not just a single domain like that helped it make sense to
query every DC in the forest and I would have again said, so ping one DC in
every domain with the query...

BS: Again… you're adding this extra "requirement" to the OP's goal. They way
the request was posted is that he just wanted the information as quick as
possible. Who cares if the command takes an extra 1min, 5min, or heck
10mins… It would still be done by the time you provided anything that meets
the "joe" standard.

BTW, the AdFind example is a bad example. It does an LDAP call, you know it
does, that is what AdFind does. ;) Anyway, you don't need source access or
the ability to read source to get a generic idea of what something is doing,
for something like this, just turn on WireShark and watch it.

BS: I don't KNOW what it does. I know what you SAY it does.

show

listmail posted this 18 July 2008

The basics of doing this in any scripting language would be

1. Retrieve the msDS-NCReplCursors attribute from the NC Head of the NC you
are concerned about.
A. By default this will come back as a XML stream. However you can
append ;binary and get it in a DSREPLCURSORBLOB format if you can work
with it.

2. Parse the XML (or the DS
REPLCURSORBLOB structures)

Likely for scripting unless you call repadmin or adfind, the XML output
format is the most useful. The main fields out of the XML you care about are

usnAttributeFilter
ftimeLastSyncSuccess
pszSourceDsaDN

If pszSourceDsaDN is empty then it is a deleted DSA.


Likely with this information, Brandon can greatly simply his previous script
especially as I expect there is considerable XML handling capability built
in.


The default that AD will output that attribute looks like

G:\Temp>adfind -default -s base msDS-NCReplCursors -h r2dc1

AdFind V01.37.00cpp Joe Richards ( <mailto:joe@joeware.net> joe@joeware.net)
June 2007

Using server: r2dc1.test.loc:389
Directory: Windows Server 2003
Base DN: DC=test,DC=loc

dn:DC=test,DC=loc
>msDS-NCReplCursors: <DSREPLCURSOR>

<uuidSourceDsaInvocationID>a34ea639-dd63-4ce8-a1c2-3ecdebd0519d</uuidSourceD
saInvocationID>
<usnAttributeFilter>2078950</usnAttributeFilter>
<ftimeLastSyncSuccess>2008-07-18T15:31:16Z</ftimeLastSyncSuccess>
<pszSourceDsaDN>CN=NTDS
Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=test,DC=loc</pszSourceDsaDN>
</DSREPLCURSOR>

>msDS-NCReplCursors: <DSREPLCURSOR>

<uuidSourceDsaInvocationID>4dd96a30-d20d-4b40-bd83-556c172b8d37</uuidSourceD
saInvocationID>
<usnAttributeFilter>3103240</usnAttributeFilter>
<ftimeLastSyncSuccess>2008-07-18T15:18:49Z</ftimeLastSyncSuccess>
<pszSourceDsaDN>CN=NTDS
Settings,CN=TEST-DC1,CN=Servers,CN=secondsite,CN=Sites,CN=Configuration,DC=t
est,DC=loc</pszSourceDsaDN>
</DSREPLCURSOR>

>msDS-NCReplCursors: <DSREPLCURSOR>

<uuidSourceDsaInvocationID>47e66f05-61fa-4bff-88e1-2a62b5ef8289</uuidSourceD
saInvocationID>
<usnAttributeFilter>719116</usnAttributeFilter>
<ftimeLastSyncSuccess>2007-05-16T18:47:55Z</ftimeLastSyncSuccess>
<pszSourceDsaDN></pszSourceDsaDN>
</DSREPLCURSOR>

>msDS-NCReplCursors: <DSREPLCURSOR>

<uuidSourceDsaInvocationID>343d88a0-0fef-4df2-ac7c-151aa3106a68</uuidSourceD
saInvocationID>
<usnAttributeFilter>13177</usnAttributeFilter>
<ftimeLastSyncSuccess>2006-07-15T13:43:49Z</ftimeLastSyncSuccess>
<pszSourceDsaDN></pszSourceDsaDN>
</DSREPLCURSOR>



1 Objects returned

AdFind also knows how to decode the BLOB format as well so you can instead
see it like

G:\Temp>adfind -default -s base msDS-NCReplCursors;binary -h r2dc1

AdFind V01.37.00cpp Joe Richards ( <mailto:joe@joeware.net> joe@joeware.net)
June 2007

Using server: r2dc1.test.loc:389
Directory: Windows Server 2003
Base DN: DC=test,DC=loc

dn:DC=test,DC=loc
>msDS-NCReplCursors;binary: 13177 2006/07/15-09:43:49 DeletedDSA
>msDS-NCReplCursors;binary: 719116 2007/05/16-14:47:55 DeletedDSA
>msDS-NCReplCursors;binary: 3103279 2008/07/18-12:03:49
secondsite\TEST-DC1
>msDS-NCReplCursors;binary: 2078979 2008/07/18-12:04:51
Default-First-Site-Name\R2DC1


1 Objects returned


The fun thing with AdFind over repadmin is that you could query a GC and get
the status of all of the domain NCs in a single call with something like

adfind -gcb -f objectcategory=domain msDS-NCReplCursors -h r2dc1

If you wanted to get the status of the domain parts as well as the config
and schema you could also craft a single query to do that as well. On a GC
you could use the GC port, on a non-GC DC, you would have to use the Phantom
Root control and a null base.



joe


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm





show

listmail posted this 18 July 2008

I like how you prefix what you say with BS. <eg>

command vs script = semantics here.

The caveat is for the future folks who hit the thread in google and say oh
wow, look this is how we build our app that does this every
month/week/day/hour/minute whatever. I just believe in trying to give as
much info to the folks asking so they have good info to make a decision on.
That way they may know up front that when they run it against their 500 DCs
and the 500 LDAP calls it takes and that it may take a bit versus just a
single LDAP call to a single DC or 4 LDAP calls in total to 4 domains. You
are welcome to do whatever you want to do though of course. :)

If I had responded before you, he would have had his answer before you
produced the lower "Brandon" standard answer. :) Because you responded first
doesn't make it faster.

> BS: I don't KNOW what it does. I know what you SAY it does.

So get off your butt and do a network trace if you are concerned. :)

joe


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm





show

bsonposh posted this 18 July 2008

It should absolutely will make it easier. Thanks for this.

show

bsonposh posted this 18 July 2008

1) I NEVER claimed mine was faster or even fast. Just easy.

2) If someone read this thread and picked my line and wrote an app around
it... I doubt me clarifying what it did would make a difference. They have
much bigger issues.

3) If you REALLY want to pound your drum on efficiency, perhaps you should
focus a bit on reliability of information. AFAIK those attribute are not
protected and could be changed to whatever. The only reliable way to get the
information is to check locally.

4) RE: Adfind.exe, I do trust your coding, but my point is still valid.
Unless you want to write everything yourself, you have to trust at some
level.

show

irishbug posted this 18 July 2008

What doe BS really mean? ; )

show

bsonposh posted this 18 July 2008

Brilliant Stuff

show

Show More Posts
Close