USN rollbacks when importing VM DC's into isolated VM Lab

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've done this on physical machines a million times, with VMware GSX and
copies of production virtual domain controllers on portable hard drives, and
have NEVER had this problem, I had never even heard of a USN rollback until
I started cloning my prod VMDC's into my isolated lab ESX box. The VM's
that I put on portable hard drives and brought into the physical machine lab
replicated with the root DC even thougth they had a higher number than the
root. Why is this happening here, now? Is it going to mean that for VM
restoration of my forest I have to start with the newest VM by date and
bring in only by gradually decreasing USN/HWMV #'s ?
 
ETA is it possible for me to manually up the USN/HWMV on my root DC in the
lab so whichever child DC's come in, no matter when, they will be
subordinate in thur replication to the root DC?
 
The high watermark isn't the issue since its maintained on the inbound
sideend of replication; the up-to-dateness vector and the invocation IDs
are the problem. You can force an invocation ID reset but it sounds too
late for that. Are you using this in production as a DR measure?
 
Images of DCs are not a good backup method. Better yet, it is not supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
 
Hi there,

fortunately this is not production. We usually use GSX (I know it's not GSX
anymore but it's the only way to mean the windows/windows vm's) domain
controllers on portable HDD's and restore them in the lab. I've done it
literally over a hundred times and never had a problem. Now we're on ESX.
I know the version of VMware can't be the cause in and of itself. I was
talking with a colleague and we kind of came to the conclusion that I was
doing the metadata cleanup too early. So if I brought in a newer DC which
already had a higher up-to-dateness vector and Invocation ID, and then
immediately do the metadata cleanup, then it could make these values for the
Configuration partition be higher, and since the other domains had metadata
cleanups and some without their original DC's anymore, there would be no
replication objects left in the other domains for it to communicate. That's
what's happening now.


Dean Wells (MVP) said:
The high watermark isn't the issue since its maintained on the inbound
sideend of replication; the up-to-dateness vector and the invocation IDs
are the problem. You can force an invocation ID reset but it sounds too
late for that. Are you using this in production as a DR measure?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


ETA is it possible for me to manually up the USN/HWMV on my root DC in
the lab so whichever child DC's come in, no matter when, they will be
subordinate in thur replication to the root DC?
Click to expand...
Click to expand...
 
Agreed and I will review your blog notes. I'm trying to find this but I
can't find the method to reset the Invocation ID though, would you happen to
know how I can do that, otherwise I'm going to toss the whole group of test
VM's in the trash can and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
 
when an image is taken from a system, the invocation ID should be reset
before AD starts. if you restore the image and AD starts without resetting
the inv ID you cannot shutdown and configure it to reset the inv ID, you
must restore the image again to the state where it has never been booted
after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of images of
DCs from a certain domain make sure ONE is configured with the burflags=D4
option and all others in the same domain with burflags=D2 option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
Agreed and I will review your blog notes. I'm trying to find this but I
can't find the method to reset the Invocation ID though, would you happen
to know how I can do that, otherwise I'm going to toss the whole group of
test VM's in the trash can and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
Images of DCs are not a good backup method. Better yet, it is not
supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
Click to expand...
Click to expand...
 
Dean,
I'm curious as to how you determined it was the invocation id?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.

Dean Wells (MVP) said:
The high watermark isn't the issue since its maintained on the inbound
sideend of replication; the up-to-dateness vector and the invocation IDs
are the problem. You can force an invocation ID reset but it sounds too
late for that. Are you using this in production as a DR measure?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


ETA is it possible for me to manually up the USN/HWMV on my root DC in
the lab so whichever child DC's come in, no matter when, they will be
subordinate in thur replication to the root DC?
Click to expand...
Click to expand...
 
USN rollbacks are a symptom of an unsupported restore process and
propogation dampening combined; the latter is something that is governed
by the up-to-dateness vector table, not the high watermark. Each HWV
uses the DC's GUID (objectGUID property of the DC's NTDSDSA instance)
while UTD vectors use the invocation ID ... et voila! For these
reasons, an entire mechanism has been built to both reset and retain a
DC's invocation IDs over time. The invocation ID is reset when a DC is
restored using a supported means or in the lesser-known scenario where
an app. NC is added to a DC, later removed and then re-added.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


Paul Bergson said:
Dean,
I'm curious as to how you determined it was the invocation id?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.

Dean Wells (MVP) said:
The high watermark isn't the issue since its maintained on the
inbound sideend of replication; the up-to-dateness vector and the
invocation IDs are the problem. You can force an invocation ID reset
but it sounds too late for that. Are you using this in production as
a DR measure?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


ETA is it possible for me to manually up the USN/HWMV on my root DC
in the lab so whichever child DC's come in, no matter when, they
will be subordinate in thur replication to the root DC?


<-> wrote in message I've done this on physical machines a million times, with VMware
GSX and copies of production virtual domain controllers on portable
hard drives, and have NEVER had this problem, I had never even
heard of a USN rollback until I started cloning my prod VMDC's into
my isolated lab ESX box. The VM's that I put on portable hard
drives and brought into the physical machine lab replicated with
the root DC even thougth they had a higher number than the root.
Why is this happening here, now? Is it going to mean that for VM
restoration of my forest I have to start with the newest VM by date
and bring in only by gradually decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each domain, so
their domain sysvol is authoritative to its own domain, I believe. I looked
through the blog, but I didn't see exactly how to do the "reset" of the
Invocation ID. I have the pre-replication VM's there I can restore. I
actually did that yesterday, and purposely didn't perform the metadata
cleanup, but basically what happened is, the newer child DC's would
replicate inbound from older and modified root (again, without any
metadata-cleanup having been done on the child). The child didn't have a
living DC in the root from which to make contact. So I have the following:

All the ones on the left were 2095, 2103, toast basically, so I promoted
never-before-seen domain controllers, and the errors stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old childB-DC2


ok, they're all talking, replicating fine. I wanted to demote/repromote the
left column ones but dcpromo demotion fails, I get ~"couldn't establish
mutual delegation." so metadata cleanup was done. So left column is gone,
only right column lives now in the VM Lab. Now, I introduce two new DC's
from the remaining two children domains, that have never seen these DC's in
the right column, and basically, though there are no further 2103/2095
errors, the two new guests at the party have never heard of anyone in column
two, and will not accept configuration data from any of them. Simply put
there's no DC in the VM Lab that exists in their configuration partition. I
would think that it would query the domain through port 389 and get updated
information though, but I think my whole problem centers around the fact
that I was too quick to do metadata cleanups prior to everybody being on the
boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the newcomers) to
successfully pull down from the new right-column DC's (in particular
root-DC2) and get the updated configuration partition I'd be happy, but if I
can't I'm going to have to trash-heap this test-bed and start again.




"Jorge de Almeida Pinto [MVP - DS]"
when an image is taken from a system, the invocation ID should be reset
before AD starts. if you restore the image and AD starts without resetting
the inv ID you cannot shutdown and configure it to reset the inv ID, you
must restore the image again to the state where it has never been booted
after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of images of
DCs from a certain domain make sure ONE is configured with the burflags=D4
option and all others in the same domain with burflags=D2 option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
Agreed and I will review your blog notes. I'm trying to find this but I
can't find the method to reset the Invocation ID though, would you happen
to know how I can do that, otherwise I'm going to toss the whole group of
test VM's in the trash can and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
Images of DCs are not a good backup method. Better yet, it is not
supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message I've done this on physical machines a million times, with VMware GSX
and copies of production virtual domain controllers on portable hard
drives, and have NEVER had this problem, I had never even heard of a
USN rollback until I started cloning my prod VMDC's into my isolated
lab ESX box. The VM's that I put on portable hard drives and brought
into the physical machine lab replicated with the root DC even thougth
they had a higher number than the root. Why is this happening here,
now? Is it going to mean that for VM restoration of my forest I have
to start with the newest VM by date and bring in only by gradually
decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
Fortunately (or unfortunately) I was only taking one DC from each domain,
so their domain sysvol is authoritative to its own domain, I believe. I
looked through the blog, but I didn't see exactly how to do the "reset" of
the Invocation ID.
Click to expand...

go to this post:
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx
and search for: Procedure for using the recovery option

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each domain,
so their domain sysvol is authoritative to its own domain, I believe. I
looked through the blog, but I didn't see exactly how to do the "reset" of
the Invocation ID. I have the pre-replication VM's there I can restore.
I actually did that yesterday, and purposely didn't perform the metadata
cleanup, but basically what happened is, the newer child DC's would
replicate inbound from older and modified root (again, without any
metadata-cleanup having been done on the child). The child didn't have a
living DC in the root from which to make contact. So I have the
following:

All the ones on the left were 2095, 2103, toast basically, so I promoted
never-before-seen domain controllers, and the errors stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old childB-DC2


ok, they're all talking, replicating fine. I wanted to demote/repromote
the left column ones but dcpromo demotion fails, I get ~"couldn't
establish mutual delegation." so metadata cleanup was done. So left
column is gone, only right column lives now in the VM Lab. Now, I
introduce two new DC's from the remaining two children domains, that have
never seen these DC's in the right column, and basically, though there are
no further 2103/2095 errors, the two new guests at the party have never
heard of anyone in column two, and will not accept configuration data from
any of them. Simply put there's no DC in the VM Lab that exists in their
configuration partition. I would think that it would query the domain
through port 389 and get updated information though, but I think my whole
problem centers around the fact that I was too quick to do metadata
cleanups prior to everybody being on the boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the newcomers) to
successfully pull down from the new right-column DC's (in particular
root-DC2) and get the updated configuration partition I'd be happy, but if
I can't I'm going to have to trash-heap this test-bed and start again.




"Jorge de Almeida Pinto [MVP - DS]"
when an image is taken from a system, the invocation ID should be reset
before AD starts. if you restore the image and AD starts without
resetting the inv ID you cannot shutdown and configure it to reset the
inv ID, you must restore the image again to the state where it has never
been booted after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of images of
DCs from a certain domain make sure ONE is configured with the
burflags=D4 option and all others in the same domain with burflags=D2
option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
Agreed and I will review your blog notes. I'm trying to find this but I
can't find the method to reset the Invocation ID though, would you
happen to know how I can do that, otherwise I'm going to toss the whole
group of test VM's in the trash can and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
Images of DCs are not a good backup method. Better yet, it is not
supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message I've done this on physical machines a million times, with VMware GSX
and copies of production virtual domain controllers on portable hard
drives, and have NEVER had this problem, I had never even heard of a
USN rollback until I started cloning my prod VMDC's into my isolated
lab ESX box. The VM's that I put on portable hard drives and brought
into the physical machine lab replicated with the root DC even thougth
they had a higher number than the root. Why is this happening here,
now? Is it going to mean that for VM restoration of my forest I have
to start with the newest VM by date and bring in only by gradually
decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
Ughhh ... >> "propagation" ... sorry Mum! :0(

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


Dean Wells (MVP) said:
USN rollbacks are a symptom of an unsupported restore process and
propogation dampening combined; the latter is something that is
governed by the up-to-dateness vector table, not the high watermark.
Each HWV uses the DC's GUID (objectGUID property of the DC's NTDSDSA
instance) while UTD vectors use the invocation ID ... et voila! For
these reasons, an entire mechanism has been built to both reset and
retain a DC's invocation IDs over time. The invocation ID is reset
when a DC is restored using a supported means or in the lesser-known
scenario where an app. NC is added to a DC, later removed and then
re-added.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


Paul Bergson said:
Dean,
I'm curious as to how you determined it was the invocation id?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.

Dean Wells (MVP) said:
The high watermark isn't the issue since its maintained on the
inbound sideend of replication; the up-to-dateness vector and the
invocation IDs are the problem. You can force an invocation ID
reset but it sounds too late for that. Are you using this in
production as a DR measure?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


<-> wrote in message ETA is it possible for me to manually up the USN/HWMV on my root DC
in the lab so whichever child DC's come in, no matter when, they
will be subordinate in thur replication to the root DC?


<-> wrote in message I've done this on physical machines a million times, with VMware
GSX and copies of production virtual domain controllers on
portable hard drives, and have NEVER had this problem, I had never
even heard of a USN rollback until I started cloning my prod
VMDC's into my isolated lab ESX box. The VM's that I put on
portable hard drives and brought into the physical machine lab
replicated with the root DC even thougth they had a higher number
than the root. Why is this happening here, now? Is it going to
mean that for VM restoration of my forest I have to start with the
newest VM by date and bring in only by gradually decreasing
USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
I should note that this is a 2000 AD (the lab is for testing the 2003 forest
upgrade). I'm almost positive the admins of the C & D child domains don't
remember the DSR password. But if one of the two does though, I'll go
through the process.

"Jorge de Almeida Pinto [MVP - DS]"
Fortunately (or unfortunately) I was only taking one DC from each domain,
so their domain sysvol is authoritative to its own domain, I believe. I
looked through the blog, but I didn't see exactly how to do the "reset"
of the Invocation ID.
Click to expand...

go to this post:
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx
and search for: Procedure for using the recovery option

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each domain,
so their domain sysvol is authoritative to its own domain, I believe. I
looked through the blog, but I didn't see exactly how to do the "reset"
of the Invocation ID. I have the pre-replication VM's there I can
restore. I actually did that yesterday, and purposely didn't perform the
metadata cleanup, but basically what happened is, the newer child DC's
would replicate inbound from older and modified root (again, without any
metadata-cleanup having been done on the child). The child didn't have a
living DC in the root from which to make contact. So I have the
following:

All the ones on the left were 2095, 2103, toast basically, so I promoted
never-before-seen domain controllers, and the errors stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old childB-DC2


ok, they're all talking, replicating fine. I wanted to demote/repromote
the left column ones but dcpromo demotion fails, I get ~"couldn't
establish mutual delegation." so metadata cleanup was done. So left
column is gone, only right column lives now in the VM Lab. Now, I
introduce two new DC's from the remaining two children domains, that have
never seen these DC's in the right column, and basically, though there
are no further 2103/2095 errors, the two new guests at the party have
never heard of anyone in column two, and will not accept configuration
data from any of them. Simply put there's no DC in the VM Lab that
exists in their configuration partition. I would think that it would
query the domain through port 389 and get updated information though, but
I think my whole problem centers around the fact that I was too quick to
do metadata cleanups prior to everybody being on the boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the newcomers) to
successfully pull down from the new right-column DC's (in particular
root-DC2) and get the updated configuration partition I'd be happy, but
if I can't I'm going to have to trash-heap this test-bed and start again.




"Jorge de Almeida Pinto [MVP - DS]"
when an image is taken from a system, the invocation ID should be reset
before AD starts. if you restore the image and AD starts without
resetting the inv ID you cannot shutdown and configure it to reset the
inv ID, you must restore the image again to the state where it has never
been booted after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of images
of DCs from a certain domain make sure ONE is configured with the
burflags=D4 option and all others in the same domain with burflags=D2
option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message Agreed and I will review your blog notes. I'm trying to find this but
I can't find the method to reset the Invocation ID though, would you
happen to know how I can do that, otherwise I'm going to toss the whole
group of test VM's in the trash can and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
message Images of DCs are not a good backup method. Better yet, it is not
supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services
#

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message I've done this on physical machines a million times, with VMware GSX
and copies of production virtual domain controllers on portable hard
drives, and have NEVER had this problem, I had never even heard of a
USN rollback until I started cloning my prod VMDC's into my isolated
lab ESX box. The VM's that I put on portable hard drives and brought
into the physical machine lab replicated with the root DC even
thougth they had a higher number than the root. Why is this
happening here, now? Is it going to mean that for VM restoration of
my forest I have to start with the newest VM by date and bring in
only by gradually decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
Thanks for the info, I need to do a whole lot more research. I need to find
more articles on this, I do have a basic understanding but I would like to
have a stronger background.

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.

Dean Wells (MVP) said:
USN rollbacks are a symptom of an unsupported restore process and
propogation dampening combined; the latter is something that is governed
by the up-to-dateness vector table, not the high watermark. Each HWV uses
the DC's GUID (objectGUID property of the DC's NTDSDSA instance) while UTD
vectors use the invocation ID ... et voila! For these reasons, an entire
mechanism has been built to both reset and retain a DC's invocation IDs
over time. The invocation ID is reset when a DC is restored using a
supported means or in the lesser-known scenario where an app. NC is added
to a DC, later removed and then re-added.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


Paul Bergson said:
Dean,
I'm curious as to how you determined it was the invocation id?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.

Dean Wells (MVP) said:
The high watermark isn't the issue since its maintained on the inbound
sideend of replication; the up-to-dateness vector and the invocation IDs
are the problem. You can force an invocation ID reset but it sounds too
late for that. Are you using this in production as a DR measure?

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


<-> wrote in message ETA is it possible for me to manually up the USN/HWMV on my root DC in
the lab so whichever child DC's come in, no matter when, they will be
subordinate in thur replication to the root DC?


<-> wrote in message I've done this on physical machines a million times, with VMware GSX
and copies of production virtual domain controllers on portable hard
drives, and have NEVER had this problem, I had never even heard of a
USN rollback until I started cloning my prod VMDC's into my isolated
lab ESX box. The VM's that I put on portable hard drives and brought
into the physical machine lab replicated with the root DC even thougth
they had a higher number than the root. Why is this happening here,
now? Is it going to mean that for VM restoration of my forest I have
to start with the newest VM by date and bring in only by gradually
decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
on w2k you can reset the DSRM using the SETPWD tool

On w2k3 you must do that through NTDSUTIL

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
I should note that this is a 2000 AD (the lab is for testing the 2003
forest upgrade). I'm almost positive the admins of the C & D child domains
don't remember the DSR password. But if one of the two does though, I'll
go through the process.

"Jorge de Almeida Pinto [MVP - DS]"
Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own domain, I
believe. I looked through the blog, but I didn't see exactly how to do
the "reset" of the Invocation ID.
Click to expand...

go to this post:
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx
and search for: Procedure for using the recovery option

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own domain, I
believe. I looked through the blog, but I didn't see exactly how to do
the "reset" of the Invocation ID. I have the pre-replication VM's there
I can restore. I actually did that yesterday, and purposely didn't
perform the metadata cleanup, but basically what happened is, the newer
child DC's would replicate inbound from older and modified root (again,
without any metadata-cleanup having been done on the child). The child
didn't have a living DC in the root from which to make contact. So I
have the following:

All the ones on the left were 2095, 2103, toast basically, so I promoted
never-before-seen domain controllers, and the errors stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old childB-DC2


ok, they're all talking, replicating fine. I wanted to demote/repromote
the left column ones but dcpromo demotion fails, I get ~"couldn't
establish mutual delegation." so metadata cleanup was done. So left
column is gone, only right column lives now in the VM Lab. Now, I
introduce two new DC's from the remaining two children domains, that
have never seen these DC's in the right column, and basically, though
there are no further 2103/2095 errors, the two new guests at the party
have never heard of anyone in column two, and will not accept
configuration data from any of them. Simply put there's no DC in the VM
Lab that exists in their configuration partition. I would think that it
would query the domain through port 389 and get updated information
though, but I think my whole problem centers around the fact that I was
too quick to do metadata cleanups prior to everybody being on the boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the newcomers) to
successfully pull down from the new right-column DC's (in particular
root-DC2) and get the updated configuration partition I'd be happy, but
if I can't I'm going to have to trash-heap this test-bed and start
again.




"Jorge de Almeida Pinto [MVP - DS]"
when an image is taken from a system, the invocation ID should be reset
before AD starts. if you restore the image and AD starts without
resetting the inv ID you cannot shutdown and configure it to reset the
inv ID, you must restore the image again to the state where it has
never been booted after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of images
of DCs from a certain domain make sure ONE is configured with the
burflags=D4 option and all others in the same domain with burflags=D2
option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message Agreed and I will review your blog notes. I'm trying to find this but
I can't find the method to reset the Invocation ID though, would you
happen to know how I can do that, otherwise I'm going to toss the
whole group of test VM's in the trash can and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
message Images of DCs are not a good backup method. Better yet, it is not
supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services
#

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message I've done this on physical machines a million times, with VMware GSX
and copies of production virtual domain controllers on portable hard
drives, and have NEVER had this problem, I had never even heard of a
USN rollback until I started cloning my prod VMDC's into my isolated
lab ESX box. The VM's that I put on portable hard drives and
brought into the physical machine lab replicated with the root DC
even thougth they had a higher number than the root. Why is this
happening here, now? Is it going to mean that for VM restoration of
my forest I have to start with the newest VM by date and bring in
only by gradually decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
Well, "must" is a little strong Princess :0) ... if you happen to have a
2K box around (or the media), you can continue to use SETPWD.EXE. In
fact, there's a script that is based on SETPWD available from here that
will reset all DSRM passwords within a supplied forest -

ftp://falcon.msetechnology.com/scripts/dsrmreset.cmd.txt

C:\>dsrmreset

DSRMreset 1.0 / Dean Wells ([email protected]) - June 2005

SYNTAX - dsrmreset <Forest Root FQDN> <DSRM password>

Resets DSRM password on all Domain Controllers within the Forest
- requires Windows 2000 SETPWD.EXE within path
- requires sufficient security context

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


"Jorge de Almeida Pinto [MVP - DS]"
on w2k you can reset the DSRM using the SETPWD tool

On w2k3 you must do that through NTDSUTIL

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services
#

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
I should note that this is a 2000 AD (the lab is for testing the 2003
forest upgrade). I'm almost positive the admins of the C & D child
domains don't remember the DSR password. But if one of the two does
though, I'll go through the process.

"Jorge de Almeida Pinto [MVP - DS]"
Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own domain,
I believe. I looked through the blog, but I didn't see exactly how
to do the "reset" of the Invocation ID.

go to this post:
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx
and search for: Procedure for using the recovery option

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own domain,
I believe. I looked through the blog, but I didn't see exactly how
to do the "reset" of the Invocation ID. I have the pre-replication
VM's there I can restore. I actually did that yesterday, and
purposely didn't perform the metadata cleanup, but basically what
happened is, the newer child DC's would replicate inbound from
older and modified root (again, without any metadata-cleanup having
been done on the child). The child didn't have a living DC in the
root from which to make contact. So I have the following:

All the ones on the left were 2095, 2103, toast basically, so I
promoted never-before-seen domain controllers, and the errors
stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old childB-DC2


ok, they're all talking, replicating fine. I wanted to
demote/repromote the left column ones but dcpromo demotion fails, I
get ~"couldn't establish mutual delegation." so metadata cleanup
was done. So left column is gone, only right column lives now in
the VM Lab. Now, I introduce two new DC's from the remaining two
children domains, that have never seen these DC's in the right
column, and basically, though there are no further 2103/2095
errors, the two new guests at the party have never heard of anyone
in column two, and will not accept configuration data from any of
them. Simply put there's no DC in the VM Lab that exists in their
configuration partition. I would think that it would query the
domain through port 389 and get updated information though, but I
think my whole problem centers around the fact that I was too quick
to do metadata cleanups prior to everybody being on the boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the newcomers)
to successfully pull down from the new right-column DC's (in
particular root-DC2) and get the updated configuration partition
I'd be happy, but if I can't I'm going to have to trash-heap this
test-bed and start again.




"Jorge de Almeida Pinto [MVP - DS]"
message when an image is taken from a system, the invocation ID should be
reset before AD starts. if you restore the image and AD starts
without resetting the inv ID you cannot shutdown and configure it
to reset the inv ID, you must restore the image again to the state
where it has never been booted after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of
images of DCs from a certain domain make sure ONE is configured
with the burflags=D4 option and all others in the same domain with
burflags=D2 option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question -->
http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers
no rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message
Agreed and I will review your blog notes. I'm trying to find
this but I can't find the method to reset the Invocation ID
though, would you happen to know how I can do that, otherwise I'm
going to toss the whole group of test VM's in the trash can and
start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
message Images of DCs are not a good backup method. Better yet, it is
not supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)-->
http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question -->
http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and
confers no rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message
I've done this on physical machines a million times, with
VMware GSX and copies of production virtual domain controllers
on portable hard drives, and have NEVER had this problem, I had
never even heard of a USN rollback until I started cloning my
prod VMDC's into my isolated lab ESX box. The VM's that I put
on portable hard drives and brought into the physical machine
lab replicated with the root DC even thougth they had a higher
number than the root. Why is this happening here, now? Is it
going to mean that for VM restoration of my forest I have to
start with the newest VM by date and bring in only by gradually
decreasing USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
belive me when I say that I wrote the MUST word I was already thinking you
would say something about it....and you did, you did... ;-)

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
Dean Wells (MVP) said:
Well, "must" is a little strong Princess :0) ... if you happen to have a
2K box around (or the media), you can continue to use SETPWD.EXE. In
fact, there's a script that is based on SETPWD available from here that
will reset all DSRM passwords within a supplied forest -

ftp://falcon.msetechnology.com/scripts/dsrmreset.cmd.txt

C:\>dsrmreset

DSRMreset 1.0 / Dean Wells ([email protected]) - June 2005

SYNTAX - dsrmreset <Forest Root FQDN> <DSRM password>

Resets DSRM password on all Domain Controllers within the Forest
- requires Windows 2000 SETPWD.EXE within path
- requires sufficient security context

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


"Jorge de Almeida Pinto [MVP - DS]"
on w2k you can reset the DSRM using the SETPWD tool

On w2k3 you must do that through NTDSUTIL

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
I should note that this is a 2000 AD (the lab is for testing the 2003
forest upgrade). I'm almost positive the admins of the C & D child
domains don't remember the DSR password. But if one of the two does
though, I'll go through the process.

"Jorge de Almeida Pinto [MVP - DS]"
Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own domain, I
believe. I looked through the blog, but I didn't see exactly how to
do the "reset" of the Invocation ID.

go to this post:
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx
and search for: Procedure for using the recovery option

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own domain, I
believe. I looked through the blog, but I didn't see exactly how to
do the "reset" of the Invocation ID. I have the pre-replication VM's
there I can restore. I actually did that yesterday, and purposely
didn't perform the metadata cleanup, but basically what happened is,
the newer child DC's would replicate inbound from older and modified
root (again, without any metadata-cleanup having been done on the
child). The child didn't have a living DC in the root from which to
make contact. So I have the following:

All the ones on the left were 2095, 2103, toast basically, so I
promoted never-before-seen domain controllers, and the errors stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old childB-DC2


ok, they're all talking, replicating fine. I wanted to
demote/repromote the left column ones but dcpromo demotion fails, I
get ~"couldn't establish mutual delegation." so metadata cleanup was
done. So left column is gone, only right column lives now in the VM
Lab. Now, I introduce two new DC's from the remaining two children
domains, that have never seen these DC's in the right column, and
basically, though there are no further 2103/2095 errors, the two new
guests at the party have never heard of anyone in column two, and will
not accept configuration data from any of them. Simply put there's no
DC in the VM Lab that exists in their configuration partition. I
would think that it would query the domain through port 389 and get
updated information though, but I think my whole problem centers
around the fact that I was too quick to do metadata cleanups prior to
everybody being on the boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the newcomers) to
successfully pull down from the new right-column DC's (in particular
root-DC2) and get the updated configuration partition I'd be happy,
but if I can't I'm going to have to trash-heap this test-bed and start
again.




"Jorge de Almeida Pinto [MVP - DS]"
message when an image is taken from a system, the invocation ID should be
reset before AD starts. if you restore the image and AD starts
without resetting the inv ID you cannot shutdown and configure it to
reset the inv ID, you must restore the image again to the state where
it has never been booted after the image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of
images of DCs from a certain domain make sure ONE is configured with
the burflags=D4 option and all others in the same domain with
burflags=D2 option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services
#

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message Agreed and I will review your blog notes. I'm trying to find this
but I can't find the method to reset the Invocation ID though, would
you happen to know how I can do that, otherwise I'm going to toss
the whole group of test VM's in the trash can and start again
tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
message Images of DCs are not a good backup method. Better yet, it is not
supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers
no rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message I've done this on physical machines a million times, with VMware
GSX and copies of production virtual domain controllers on
portable hard drives, and have NEVER had this problem, I had never
even heard of a USN rollback until I started cloning my prod
VMDC's into my isolated lab ESX box. The VM's that I put on
portable hard drives and brought into the physical machine lab
replicated with the root DC even thougth they had a higher number
than the root. Why is this happening here, now? Is it going to
mean that for VM restoration of my forest I have to start with the
newest VM by date and bring in only by gradually decreasing
USN/HWMV #'s ?
Click to expand...
Click to expand...
Click to expand...
 
Glad not to disappoint my friend :-p

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


"Jorge de Almeida Pinto [MVP - DS]"
belive me when I say that I wrote the MUST word I was already thinking
you would say something about it....and you did, you did... ;-)

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services
#

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
Dean Wells (MVP) said:
Well, "must" is a little strong Princess :0) ... if you happen to
have a 2K box around (or the media), you can continue to use
SETPWD.EXE. In fact, there's a script that is based on SETPWD
available from here that will reset all DSRM passwords within a
supplied forest -

ftp://falcon.msetechnology.com/scripts/dsrmreset.cmd.txt

C:\>dsrmreset

DSRMreset 1.0 / Dean Wells ([email protected]) - June 2005

SYNTAX - dsrmreset <Forest Root FQDN> <DSRM password>

Resets DSRM password on all Domain Controllers within the Forest
- requires Windows 2000 SETPWD.EXE within path
- requires sufficient security context

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l


"Jorge de Almeida Pinto [MVP - DS]"
on w2k you can reset the DSRM using the SETPWD tool

On w2k3 you must do that through NTDSUTIL

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message I should note that this is a 2000 AD (the lab is for testing the
2003 forest upgrade). I'm almost positive the admins of the C & D
child domains don't remember the DSR password. But if one of the
two does though, I'll go through the process.

"Jorge de Almeida Pinto [MVP - DS]"
message Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own
domain, I believe. I looked through the blog, but I didn't see
exactly how to do the "reset" of the Invocation ID.

go to this post:
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx
and search for: Procedure for using the recovery option

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question -->
http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers
no rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message So, on today's episode of : "Can This Forest Be Saved?"

Fortunately (or unfortunately) I was only taking one DC from each
domain, so their domain sysvol is authoritative to its own
domain, I believe. I looked through the blog, but I didn't see
exactly how to do the "reset" of the Invocation ID. I have the
pre-replication VM's there I can restore. I actually did that
yesterday, and purposely didn't perform the metadata cleanup, but
basically what happened is, the newer child DC's would replicate
inbound from older and modified root (again, without any
metadata-cleanup having been done on the child). The child didn't
have a living DC in the root from which to make contact. So I
have the following:

All the ones on the left were 2095, 2103, toast basically, so I
promoted never-before-seen domain controllers, and the errors
stopped.


root-DC1-old promote root-DC2
childA-DC1-old --------> childA-DC2
childB-DC1-old
childB-DC2


ok, they're all talking, replicating fine. I wanted to
demote/repromote the left column ones but dcpromo demotion fails,
I get ~"couldn't establish mutual delegation." so metadata
cleanup was done. So left column is gone, only right column
lives now in the VM Lab. Now, I introduce two new DC's from the
remaining two children domains, that have never seen these DC's
in the right column, and basically, though there are no further
2103/2095 errors, the two new guests at the party have never
heard of anyone in column two, and will not accept configuration
data from any of them. Simply put there's no DC in the VM Lab
that exists in their configuration partition. I would think that
it would query the domain through port 389 and get updated
information though, but I think my whole problem centers around
the fact that I was too quick to do metadata cleanups prior to
everybody being on the boat.

Basically, if I could get ChildC-DC1 and ChildD-DC1 (the
newcomers) to successfully pull down from the new right-column
DC's (in particular root-DC2) and get the updated configuration
partition I'd be happy, but if I can't I'm going to have to
trash-heap this test-bed and start again.




"Jorge de Almeida Pinto [MVP - DS]"
message when an image is taken from a system, the invocation ID should
be reset before AD starts. if you restore the image and AD
starts without resetting the inv ID you cannot shutdown and
configure it to reset the inv ID, you must restore the image
again to the state where it has never been booted after the
image creation.

To reset the inv ID see the blog entries I posted earlier.

USN rollbacks do not occur only in AD, but also in the SYSVOL
To make sure everything goes as needed. When restoring a set of
images of DCs from a certain domain make sure ONE is configured
with the burflags=D4 option and all others in the same domain
with burflags=D2 option.

again see my blog

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)-->
http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question -->
http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and
confers no rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message
Agreed and I will review your blog notes. I'm trying to find
this but I can't find the method to reset the Invocation ID
though, would you happen to know how I can do that, otherwise
I'm going to toss the whole group of test VM's in the trash can
and start again tomorrow.




"Jorge de Almeida Pinto [MVP - DS]"
in message Images of DCs are not a good backup method. Better yet, it is
not supported.

read more here:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/09/DSA_2D00_GUIDs-and-Invocation-IDs.aspx
http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory
Services #

BLOG (WEB-BASED)-->
http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)-->
http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question -->
http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and
confers no rights!
* Always test ANY suggestion in a test environment before
implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
<-> wrote in message
I've done this on physical machines a million times, with
VMware GSX and copies of production virtual domain
controllers on portable hard drives, and have NEVER had this
problem, I had never even heard of a USN rollback until I
started cloning my prod VMDC's into my isolated lab ESX box.
The VM's that I put on portable hard drives and brought into
the physical machine lab replicated with the root DC even
thougth they had a higher number than the root. Why is this
happening here, now? Is it going to mean that for VM
restoration of my forest I have to start with the newest VM
by date and bring in only by gradually decreasing USN/HWMV
#'s ?
Click to expand...
Click to expand...
Click to expand...
 
Please visit [email protected]/blog
I am starting up a business and need new customers. Any help that you could
give me, I would really appreciate it. Im not spaming anyone, so please let
me know if there are anyone you know who lives in the london area and would
be interested in the purchase of medical uniforms.

Im trying to get as many customers as i can. i need help tho. Please pass
this email on to whom ever you know who would be interested. I would really
appreciate it.

Here is a little about it:

We are a business that makes Medical Uniforms which are made for Nurse's,
Doctors, and any Medical team that there is out there like PSW's.

You can find more out about it at: [email protected]/blog

We have flexible plans to accommodate growth. All size's, styles and colors
that you can think of

We are located in London, Ontario

Thank you for your time.

Margaret
 
Back
Top