Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

repadmin /showvector display strange GUIDs

902 views
Skip to first unread message

B

unread,
Jun 20, 2006, 11:07:03 AM6/20/06
to
When running repadmin /showvector dc=abc,dc=com, it shows strange GUIDs
(besides Site\Server name @USN) as follows;


0370a2f9-0f48-4d2c-9fd3-2254e3a26f81 @ USN 617700 @ Time 2005-11-01
07:51:00
04e45879-11f2-4760-8964-50ff37b7a051 @ USN 308755 @ Time 2004-04-05
09:46:11

How can I get rid of it?

Jorge Silva

unread,
Jun 20, 2006, 12:40:02 PM6/20/06
to
Hi


These numbers identifies the servers GUID, these servers aren't in use
anymore, and did you remove them from AD using Dcpromo?

If yes, then just delete these GUID from DNS.


--
I hope that the information above helps you

Good Luck
Jorge Silva
MCSA
Systems Administrator

"B" <B...@discussions.microsoft.com> wrote in message
news:555CA3C0-F624-46DF...@microsoft.com...

B

unread,
Jun 20, 2006, 1:10:02 PM6/20/06
to
Hi Jorge
It was you again. Thank you very much for replying my e-mail.
These GUIDs are not in use, because that was moved using dcpromo. And When
I looked at DNS, I could not find out at all. I looked at each tree one by
one and can't find out at all. Is there any way to clean them up?

Jorge de Almeida Pinto [MVP]

unread,
Jun 20, 2006, 4:44:52 PM6/20/06
to
those are not server GUIDs (or better yet: DSA GUIDs or objectGUIDs from the
NTDS Settings object which identify a DC).
those GUIDs are Invocation IDs which identify database instances on DCs.
Those Invocation IDs are changed when a DC is restored or when an app NC is
sourced onto the DC.
DSA GUIDs never change during the lifetime of a DC, only when demoting

in DNS you will find DSA GUIDs, NOT invocation IDs

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"Jorge Silva" <jorges...@hotmail.com> wrote in message
news:e%23bf0gIl...@TK2MSFTNGP05.phx.gbl...

Joe Richards [MVP]

unread,
Jun 20, 2006, 7:25:18 PM6/20/06
to
Those are up-to-dateness vector (UTDV) entries and can't be removed. You
don't want them removed, they are a critical part of replication
dampening. If you actually want to understand this stuff, pick up the
book in the signature and read carefully through chapter 5.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

B

unread,
Jun 21, 2006, 12:33:42 PM6/21/06
to
Jorge,

I thought these were objectGIODs from the NTDS Settings, but when I found
the DNS Alias (from Property of NTDS Settings on each DC), none of the GUIDs
are matched between DNS Alias and the one showing on repadmin /showvector.

Also, when I found the CNAME in DNS (_msdcs), they are completelly matched
with DNS Alias (Property of NTDS Setting).

We removed bunch of DC before and we did not follow the correct process (we
just ran dcpromo and did not clean up from NTDS Utility nor adsiedit), so I
thought those removed DCs informations are still remained somewhere.
Especially, those time and dates were never updated.

Don't I need to worry about it??

Jorge de Almeida Pinto [MVP]

unread,
Jun 21, 2006, 2:04:17 PM6/21/06
to
there are to ways to remove DCs from AD:
(1) demote and cleanup server object manually
(2) just shutdown the DC (never to be connected again!), perform a metadata
cleanup and cleanup the server object manually

to answer your question...
YES, you should cleanup the AD metadata of DCs that still exist in AD but
are not alive anymore.

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------

"B" <B...@discussions.microsoft.com> wrote in message

news:D205C844-6CE7-41BF...@microsoft.com...

B

unread,
Jun 21, 2006, 3:00:03 PM6/21/06
to
Hi Jorge,

I was trying to clean up MetaData using NTDS Utility, but I could not find
out the DC information that demoted for a while ago. Normally after demoted,
you see that DC name in the server list in that site. But I don't see any
GUIDs at all anymore.

Instead, I checked all DNS Entry including any tree/folders, I saw bunch of
demoted DC information. So, I deleted all of them.

However, still showing that GUIDs when running repadmin /showvector
dc=xxx,dc=com

I wonder where the information is coming from... Do you have any idea?

B

unread,
Jun 21, 2006, 3:01:02 PM6/21/06
to
Joe,

I thought these were objectGIODs from the NTDS Settings, but when I found
the DNS Alias (from Property of NTDS Settings on each DC), none of the GUIDs
are matched between DNS Alias and the one showing on repadmin /showvector.

Also, when I found the CNAME in DNS (_msdcs), they are completelly matched
with DNS Alias (Property of NTDS Setting).

We removed bunch of DC before and we did not follow the correct process (we
just ran dcpromo and did not clean up from NTDS Utility nor adsiedit), so I
thought those removed DCs informations are still remained somewhere.
Especially, those time and dates were never updated.

Don't I need to worry about it??

Joe Richards [MVP]

unread,
Jun 21, 2006, 3:29:38 PM6/21/06
to
You do not need to worry about unresolved GUIDs in the UDTV tables, they
are expected and will be there forever. Maybe a later version of the
tool will block them from view but they are required internally for
proper dampening of AD replication.

Jorge de Almeida Pinto [MVP]

unread,
Jun 21, 2006, 3:51:17 PM6/21/06
to
no need to worry about those GUIDs (invocation IDs) you see.

it is even possible to see more than one for each DC when the normal name is
shown.

let's day you have a DC called DC01:
objectGUID=12345
InvocID=ABCDE

for some reason you need to do a non-auth restore of AD. after the restore
when the DC is up and running again...
objectGUID=12345
InvocID=FGHIJ

checking the UTDs again you will see
DC1 ......
DC1 (retired) ......

the InvocID is also changed when a new app partition is hosted on the DC


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"B" <B...@discussions.microsoft.com> wrote in message

news:DCC11ACE-532A-4B45...@microsoft.com...

0 new messages