Forum Search:
Forum.Brain-Cluster.com: Brain Cluster Technical Forum
Ultimate forum for Technical Discussions

Home » Microsoft » Windows Server » Active Directory » ADAM - Migration of Replica from Workgroup to Domain question
ADAM - Migration of Replica from Workgroup to Domain question [message #156128] Wed, 10 June 2009 15:59 Go to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
I'm currently involved in a project where we had two ADAM instances set up...
one on two unique servers. One was a replica of the other. Our new
application that will be using ADAM will be using AzMan and we will be adding
internal domain users to AzMan roles.

The server name and service user is now different than the original. I'm
using a service account in the domain that has been granted proper rights,
local admin, local admins is in the adminstrators ADAM role, etc.

The requirement was to leave the primary ADAM instance running in
production, disable replication, move the replica instance internally to our
domain.

I changed the service user using dsdbutil, corrected the SCP errors with
ADSIEdit in the domain.

The Cisco firewall blocks all communication, so replication had to be
suspended... which I did with repadmin

I tried using metadata cleanup and seizing the naming and schema master
roles. It appears that the instance of ADAM is not recognizing the new server
name. When I list servers in msmgmt, it shows the original server name. It
also appears that replication is still trying to take place.

I'm unable to view one of the replicated partitions because ADSIedit gives
me a referral error.

Is a migration even possible like this? I've seen Lee Flight mention that a
better approach would be to back up and then restore onto a clean server.
But, can the server name even be changed in a situation where the replica's
server name is changed and then the roles are seized?

Thanks

Ted
RE: ADAM - Migration of Replica from Workgroup to Domain question [message #156166 is a reply to message #156128] Thu, 11 June 2009 09:52 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Let me break this down further....

A) when I do a DSDiag, I can see the instance is still trying to refer to
the old server name. How do I change the running instance to stop referring
to the old server name but change it to the new server name?

B) Although I've suspended outbound/inboud replication, how do I completely
remove all replicas (and cease replication altogether) so that I can seize
the roles and make the current instance the only instance?

I would assume using metadata cleanup and seizing the naming and schema
roles should take care of this for ADAM? Is that true?

Thank you

Ted

"Ted Wagner" wrote:

> I'm currently involved in a project where we had two ADAM instances set up...
> one on two unique servers. One was a replica of the other. Our new
> application that will be using ADAM will be using AzMan and we will be adding
> internal domain users to AzMan roles.
>
> The server name and service user is now different than the original. I'm
> using a service account in the domain that has been granted proper rights,
> local admin, local admins is in the adminstrators ADAM role, etc.
>
> The requirement was to leave the primary ADAM instance running in
> production, disable replication, move the replica instance internally to our
> domain.
>
> I changed the service user using dsdbutil, corrected the SCP errors with
> ADSIEdit in the domain.
>
> The Cisco firewall blocks all communication, so replication had to be
> suspended... which I did with repadmin
>
> I tried using metadata cleanup and seizing the naming and schema master
> roles. It appears that the instance of ADAM is not recognizing the new server
> name. When I list servers in msmgmt, it shows the original server name. It
> also appears that replication is still trying to take place.
>
> I'm unable to view one of the replicated partitions because ADSIedit gives
> me a referral error.
>
> Is a migration even possible like this? I've seen Lee Flight mention that a
> better approach would be to back up and then restore onto a clean server.
> But, can the server name even be changed in a situation where the replica's
> server name is changed and then the roles are seized?
>
> Thanks
>
> Ted
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156195 is a reply to message #156166] Thu, 11 June 2009 12:57 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi

seizing the roles and metadata cleanup should work in your situation.
What problems are you seeing when you try?

Lee Flight

"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
>
> Let me break this down further....
>
> A) when I do a DSDiag, I can see the instance is still trying to refer to
> the old server name. How do I change the running instance to stop
> referring
> to the old server name but change it to the new server name?
>
> B) Although I've suspended outbound/inboud replication, how do I
> completely
> remove all replicas (and cease replication altogether) so that I can seize
> the roles and make the current instance the only instance?
>
> I would assume using metadata cleanup and seizing the naming and schema
> roles should take care of this for ADAM? Is that true?
>
> Thank you
>
> Ted
>
> "Ted Wagner" wrote:
>
>> I'm currently involved in a project where we had two ADAM instances set
>> up...
>> one on two unique servers. One was a replica of the other. Our new
>> application that will be using ADAM will be using AzMan and we will be
>> adding
>> internal domain users to AzMan roles.
>>
>> The server name and service user is now different than the original. I'm
>> using a service account in the domain that has been granted proper
>> rights,
>> local admin, local admins is in the adminstrators ADAM role, etc.
>>
>> The requirement was to leave the primary ADAM instance running in
>> production, disable replication, move the replica instance internally to
>> our
>> domain.
>>
>> I changed the service user using dsdbutil, corrected the SCP errors with
>> ADSIEdit in the domain.
>>
>> The Cisco firewall blocks all communication, so replication had to be
>> suspended... which I did with repadmin
>>
>> I tried using metadata cleanup and seizing the naming and schema master
>> roles. It appears that the instance of ADAM is not recognizing the new
>> server
>> name. When I list servers in msmgmt, it shows the original server name.
>> It
>> also appears that replication is still trying to take place.
>>
>> I'm unable to view one of the replicated partitions because ADSIedit
>> gives
>> me a referral error.
>>
>> Is a migration even possible like this? I've seen Lee Flight mention that
>> a
>> better approach would be to back up and then restore onto a clean server.
>> But, can the server name even be changed in a situation where the
>> replica's
>> server name is changed and then the roles are seized?
>>
>> Thanks
>>
>> Ted
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156196 is a reply to message #156195] Thu, 11 June 2009 13:35 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Hi Lee,

When I try to seize the schema and naming roles, I receive the gui prompt
confirming I want to seize the roles from server localhost:389. The DN of
the object is the old server name.

I click yes and I receive the message that the server knows about 2 roles,
however, the DN of the server object in both instances remains the old server
name.

When trying to do the metadata cleanup, after selecting the
Default-First-Site-Name, when I list the servers, the DN is of the old server
name.

After getting out and back in to dsmgt and doing a 'remove selected server
"<full DN of the server>" on localhost:389

I receieve the LDAP error: 0x5e(94 no result present in message.

Unable to determine the domain hosted by the DC

DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)

Thanks

Ted

"Lee Flight" wrote:

> Hi
>
> seizing the roles and metadata cleanup should work in your situation.
> What problems are you seeing when you try?
>
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >
> > Let me break this down further....
> >
> > A) when I do a DSDiag, I can see the instance is still trying to refer to
> > the old server name. How do I change the running instance to stop
> > referring
> > to the old server name but change it to the new server name?
> >
> > B) Although I've suspended outbound/inboud replication, how do I
> > completely
> > remove all replicas (and cease replication altogether) so that I can seize
> > the roles and make the current instance the only instance?
> >
> > I would assume using metadata cleanup and seizing the naming and schema
> > roles should take care of this for ADAM? Is that true?
> >
> > Thank you
> >
> > Ted
> >
> > "Ted Wagner" wrote:
> >
> >> I'm currently involved in a project where we had two ADAM instances set
> >> up...
> >> one on two unique servers. One was a replica of the other. Our new
> >> application that will be using ADAM will be using AzMan and we will be
> >> adding
> >> internal domain users to AzMan roles.
> >>
> >> The server name and service user is now different than the original. I'm
> >> using a service account in the domain that has been granted proper
> >> rights,
> >> local admin, local admins is in the adminstrators ADAM role, etc.
> >>
> >> The requirement was to leave the primary ADAM instance running in
> >> production, disable replication, move the replica instance internally to
> >> our
> >> domain.
> >>
> >> I changed the service user using dsdbutil, corrected the SCP errors with
> >> ADSIEdit in the domain.
> >>
> >> The Cisco firewall blocks all communication, so replication had to be
> >> suspended... which I did with repadmin
> >>
> >> I tried using metadata cleanup and seizing the naming and schema master
> >> roles. It appears that the instance of ADAM is not recognizing the new
> >> server
> >> name. When I list servers in msmgmt, it shows the original server name.
> >> It
> >> also appears that replication is still trying to take place.
> >>
> >> I'm unable to view one of the replicated partitions because ADSIedit
> >> gives
> >> me a referral error.
> >>
> >> Is a migration even possible like this? I've seen Lee Flight mention that
> >> a
> >> better approach would be to back up and then restore onto a clean server.
> >> But, can the server name even be changed in a situation where the
> >> replica's
> >> server name is changed and then the roles are seized?
> >>
> >> Thanks
> >>
> >> Ted
>
>
>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156197 is a reply to message #156195] Thu, 11 June 2009 13:56 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Hmmmm

You know what. Thinking out loud here as I'm looking at this; I'm wondering
something...

In the original configuration there were two servers. Let's call them
"extserver1" and "extserver2". "extserver1" was the initial instance of
ADAM. We used the out-of-box wizard in creating a replicated instance on
"extserver2". So, "extserver2" was the replica ADAM instance.

I'm attempting to seize the roles on extserver2. But, server2's NEW name is
"intserver2".

In the msmgmt, I did a meta cleanup on extserver1. extserver2 still remains
in the list.

So, did I end up hosing myself because I removed the primary instance first
and am left with a replica? Or, does it matter?

Thanks

Ted

"Lee Flight" wrote:

> Hi
>
> seizing the roles and metadata cleanup should work in your situation.
> What problems are you seeing when you try?
>
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >
> > Let me break this down further....
> >
> > A) when I do a DSDiag, I can see the instance is still trying to refer to
> > the old server name. How do I change the running instance to stop
> > referring
> > to the old server name but change it to the new server name?
> >
> > B) Although I've suspended outbound/inboud replication, how do I
> > completely
> > remove all replicas (and cease replication altogether) so that I can seize
> > the roles and make the current instance the only instance?
> >
> > I would assume using metadata cleanup and seizing the naming and schema
> > roles should take care of this for ADAM? Is that true?
> >
> > Thank you
> >
> > Ted
> >
> > "Ted Wagner" wrote:
> >
> >> I'm currently involved in a project where we had two ADAM instances set
> >> up...
> >> one on two unique servers. One was a replica of the other. Our new
> >> application that will be using ADAM will be using AzMan and we will be
> >> adding
> >> internal domain users to AzMan roles.
> >>
> >> The server name and service user is now different than the original. I'm
> >> using a service account in the domain that has been granted proper
> >> rights,
> >> local admin, local admins is in the adminstrators ADAM role, etc.
> >>
> >> The requirement was to leave the primary ADAM instance running in
> >> production, disable replication, move the replica instance internally to
> >> our
> >> domain.
> >>
> >> I changed the service user using dsdbutil, corrected the SCP errors with
> >> ADSIEdit in the domain.
> >>
> >> The Cisco firewall blocks all communication, so replication had to be
> >> suspended... which I did with repadmin
> >>
> >> I tried using metadata cleanup and seizing the naming and schema master
> >> roles. It appears that the instance of ADAM is not recognizing the new
> >> server
> >> name. When I list servers in msmgmt, it shows the original server name.
> >> It
> >> also appears that replication is still trying to take place.
> >>
> >> I'm unable to view one of the replicated partitions because ADSIedit
> >> gives
> >> me a referral error.
> >>
> >> Is a migration even possible like this? I've seen Lee Flight mention that
> >> a
> >> better approach would be to back up and then restore onto a clean server.
> >> But, can the server name even be changed in a situation where the
> >> replica's
> >> server name is changed and then the roles are seized?
> >>
> >> Thanks
> >>
> >> Ted
>
>
>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156223 is a reply to message #156196] Fri, 12 June 2009 05:14 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi

the reason that you are seeing the "DN of the object is the old server
name" is that the server object in the your sites container still
has the old server name embedded in it, so if you browse to the
configuration naming context
and then cn=sites
and then cn=<your site name or Default-First-Site-Name>
and then cn=Servers

you will likely see a server object with the old server name embedded
in it. This embedding is not a problem it's just a string, the FSMO roles
that you have
seized will be referencing the NTDS Settings object beneath the server
object so it sounds like your FSMO roles have been seized correctly.

On the metadata cleanup the DsRemoveDsServer error may be due
to orphaned NTDS settings objects under the server objects you are
attemtping to cleanup OR you may have the syntax wrong and be attempting
to delete the server that you are currently connected to.

If you are sure that your syntax is correct then
you might want to delete the server objects that are no longer required
directly from the cn=Servers container to clean up your replication
connections but even that is not "required".

As the instance is in production I would recommend that if you
do wish to attempt ant further clean-up e.g. renaming the current
server object or deleting obsolete servers directly that you do that
in a test environment and of course always have a full backup.

Lee Flight


"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
> Hi Lee,
>
> When I try to seize the schema and naming roles, I receive the gui prompt
> confirming I want to seize the roles from server localhost:389. The DN of
> the object is the old server name.
>
> I click yes and I receive the message that the server knows about 2 roles,
> however, the DN of the server object in both instances remains the old
> server
> name.
>
> When trying to do the metadata cleanup, after selecting the
> Default-First-Site-Name, when I list the servers, the DN is of the old
> server
> name.
>
> After getting out and back in to dsmgt and doing a 'remove selected server
> "<full DN of the server>" on localhost:389
>
> I receieve the LDAP error: 0x5e(94 no result present in message.
>
> Unable to determine the domain hosted by the DC
>
> DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)
>
> Thanks
>
> Ted
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> seizing the roles and metadata cleanup should work in your situation.
>> What problems are you seeing when you try?
>>
>> Lee Flight
>>
>> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
>> >
>> > Let me break this down further....
>> >
>> > A) when I do a DSDiag, I can see the instance is still trying to refer
>> > to
>> > the old server name. How do I change the running instance to stop
>> > referring
>> > to the old server name but change it to the new server name?
>> >
>> > B) Although I've suspended outbound/inboud replication, how do I
>> > completely
>> > remove all replicas (and cease replication altogether) so that I can
>> > seize
>> > the roles and make the current instance the only instance?
>> >
>> > I would assume using metadata cleanup and seizing the naming and schema
>> > roles should take care of this for ADAM? Is that true?
>> >
>> > Thank you
>> >
>> > Ted
>> >
>> > "Ted Wagner" wrote:
>> >
>> >> I'm currently involved in a project where we had two ADAM instances
>> >> set
>> >> up...
>> >> one on two unique servers. One was a replica of the other. Our new
>> >> application that will be using ADAM will be using AzMan and we will be
>> >> adding
>> >> internal domain users to AzMan roles.
>> >>
>> >> The server name and service user is now different than the original.
>> >> I'm
>> >> using a service account in the domain that has been granted proper
>> >> rights,
>> >> local admin, local admins is in the adminstrators ADAM role, etc.
>> >>
>> >> The requirement was to leave the primary ADAM instance running in
>> >> production, disable replication, move the replica instance internally
>> >> to
>> >> our
>> >> domain.
>> >>
>> >> I changed the service user using dsdbutil, corrected the SCP errors
>> >> with
>> >> ADSIEdit in the domain.
>> >>
>> >> The Cisco firewall blocks all communication, so replication had to be
>> >> suspended... which I did with repadmin
>> >>
>> >> I tried using metadata cleanup and seizing the naming and schema
>> >> master
>> >> roles. It appears that the instance of ADAM is not recognizing the new
>> >> server
>> >> name. When I list servers in msmgmt, it shows the original server
>> >> name.
>> >> It
>> >> also appears that replication is still trying to take place.
>> >>
>> >> I'm unable to view one of the replicated partitions because ADSIedit
>> >> gives
>> >> me a referral error.
>> >>
>> >> Is a migration even possible like this? I've seen Lee Flight mention
>> >> that
>> >> a
>> >> better approach would be to back up and then restore onto a clean
>> >> server.
>> >> But, can the server name even be changed in a situation where the
>> >> replica's
>> >> server name is changed and then the roles are seized?
>> >>
>> >> Thanks
>> >>
>> >> Ted
>>
>>
>>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156231 is a reply to message #156223] Fri, 12 June 2009 07:56 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Ah, ok, makes perfect sense. And, that is what happened with my metadata
cleanup.

So, if manually remove the
CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT will fix
up the replication? I've been looking through repadmin documentation and
there's noting about using that for ceasing replication between two
instances.

Thanks

Ted

"Lee Flight" wrote:

> Hi
>
> the reason that you are seeing the "DN of the object is the old server
> name" is that the server object in the your sites container still
> has the old server name embedded in it, so if you browse to the
> configuration naming context
> and then cn=sites
> and then cn=<your site name or Default-First-Site-Name>
> and then cn=Servers
>
> you will likely see a server object with the old server name embedded
> in it. This embedding is not a problem it's just a string, the FSMO roles
> that you have
> seized will be referencing the NTDS Settings object beneath the server
> object so it sounds like your FSMO roles have been seized correctly.
>
> On the metadata cleanup the DsRemoveDsServer error may be due
> to orphaned NTDS settings objects under the server objects you are
> attemtping to cleanup OR you may have the syntax wrong and be attempting
> to delete the server that you are currently connected to.
>
> If you are sure that your syntax is correct then
> you might want to delete the server objects that are no longer required
> directly from the cn=Servers container to clean up your replication
> connections but even that is not "required".
>
> As the instance is in production I would recommend that if you
> do wish to attempt ant further clean-up e.g. renaming the current
> server object or deleting obsolete servers directly that you do that
> in a test environment and of course always have a full backup.
>
> Lee Flight
>
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
> > Hi Lee,
> >
> > When I try to seize the schema and naming roles, I receive the gui prompt
> > confirming I want to seize the roles from server localhost:389. The DN of
> > the object is the old server name.
> >
> > I click yes and I receive the message that the server knows about 2 roles,
> > however, the DN of the server object in both instances remains the old
> > server
> > name.
> >
> > When trying to do the metadata cleanup, after selecting the
> > Default-First-Site-Name, when I list the servers, the DN is of the old
> > server
> > name.
> >
> > After getting out and back in to dsmgt and doing a 'remove selected server
> > "<full DN of the server>" on localhost:389
> >
> > I receieve the LDAP error: 0x5e(94 no result present in message.
> >
> > Unable to determine the domain hosted by the DC
> >
> > DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)
> >
> > Thanks
> >
> > Ted
> >
> > "Lee Flight" wrote:
> >
> >> Hi
> >>
> >> seizing the roles and metadata cleanup should work in your situation.
> >> What problems are you seeing when you try?
> >>
> >> Lee Flight
> >>
> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >> >
> >> > Let me break this down further....
> >> >
> >> > A) when I do a DSDiag, I can see the instance is still trying to refer
> >> > to
> >> > the old server name. How do I change the running instance to stop
> >> > referring
> >> > to the old server name but change it to the new server name?
> >> >
> >> > B) Although I've suspended outbound/inboud replication, how do I
> >> > completely
> >> > remove all replicas (and cease replication altogether) so that I can
> >> > seize
> >> > the roles and make the current instance the only instance?
> >> >
> >> > I would assume using metadata cleanup and seizing the naming and schema
> >> > roles should take care of this for ADAM? Is that true?
> >> >
> >> > Thank you
> >> >
> >> > Ted
> >> >
> >> > "Ted Wagner" wrote:
> >> >
> >> >> I'm currently involved in a project where we had two ADAM instances
> >> >> set
> >> >> up...
> >> >> one on two unique servers. One was a replica of the other. Our new
> >> >> application that will be using ADAM will be using AzMan and we will be
> >> >> adding
> >> >> internal domain users to AzMan roles.
> >> >>
> >> >> The server name and service user is now different than the original.
> >> >> I'm
> >> >> using a service account in the domain that has been granted proper
> >> >> rights,
> >> >> local admin, local admins is in the adminstrators ADAM role, etc.
> >> >>
> >> >> The requirement was to leave the primary ADAM instance running in
> >> >> production, disable replication, move the replica instance internally
> >> >> to
> >> >> our
> >> >> domain.
> >> >>
> >> >> I changed the service user using dsdbutil, corrected the SCP errors
> >> >> with
> >> >> ADSIEdit in the domain.
> >> >>
> >> >> The Cisco firewall blocks all communication, so replication had to be
> >> >> suspended... which I did with repadmin
> >> >>
> >> >> I tried using metadata cleanup and seizing the naming and schema
> >> >> master
> >> >> roles. It appears that the instance of ADAM is not recognizing the new
> >> >> server
> >> >> name. When I list servers in msmgmt, it shows the original server
> >> >> name.
> >> >> It
> >> >> also appears that replication is still trying to take place.
> >> >>
> >> >> I'm unable to view one of the replicated partitions because ADSIedit
> >> >> gives
> >> >> me a referral error.
> >> >>
> >> >> Is a migration even possible like this? I've seen Lee Flight mention
> >> >> that
> >> >> a
> >> >> better approach would be to back up and then restore onto a clean
> >> >> server.
> >> >> But, can the server name even be changed in a situation where the
> >> >> replica's
> >> >> server name is changed and then the roles are seized?
> >> >>
> >> >> Thanks
> >> >>
> >> >> Ted
> >>
> >>
> >>
>
>
>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156328 is a reply to message #156231] Mon, 15 June 2009 05:22 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi,

if I have understood the server renaming that you did then
I suspect that the object that embeds oldserver2 in the name
may be the current (renamed) server and perhaps that is why
your metadata cleanup attempt failed if you specified that server?

Can we see the output from "list servers in site" from dsmgmt
connected to the (migrated) server you are attempting to cleanup
the replication connection on and also the output from:

repadmin /showrepl /conn <server>:<port>

run against that server.

Thanks
Lee Flight


"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
> Ah, ok, makes perfect sense. And, that is what happened with my metadata
> cleanup.
>
> So, if manually remove the
> CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
> CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT will
> fix
> up the replication? I've been looking through repadmin documentation and
> there's noting about using that for ceasing replication between two
> instances.
>
> Thanks
>
> Ted
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> the reason that you are seeing the "DN of the object is the old server
>> name" is that the server object in the your sites container still
>> has the old server name embedded in it, so if you browse to the
>> configuration naming context
>> and then cn=sites
>> and then cn=<your site name or Default-First-Site-Name>
>> and then cn=Servers
>>
>> you will likely see a server object with the old server name embedded
>> in it. This embedding is not a problem it's just a string, the FSMO roles
>> that you have
>> seized will be referencing the NTDS Settings object beneath the server
>> object so it sounds like your FSMO roles have been seized correctly.
>>
>> On the metadata cleanup the DsRemoveDsServer error may be due
>> to orphaned NTDS settings objects under the server objects you are
>> attemtping to cleanup OR you may have the syntax wrong and be attempting
>> to delete the server that you are currently connected to.
>>
>> If you are sure that your syntax is correct then
>> you might want to delete the server objects that are no longer required
>> directly from the cn=Servers container to clean up your replication
>> connections but even that is not "required".
>>
>> As the instance is in production I would recommend that if you
>> do wish to attempt ant further clean-up e.g. renaming the current
>> server object or deleting obsolete servers directly that you do that
>> in a test environment and of course always have a full backup.
>>
>> Lee Flight
>>
>>
>> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
>> > Hi Lee,
>> >
>> > When I try to seize the schema and naming roles, I receive the gui
>> > prompt
>> > confirming I want to seize the roles from server localhost:389. The DN
>> > of
>> > the object is the old server name.
>> >
>> > I click yes and I receive the message that the server knows about 2
>> > roles,
>> > however, the DN of the server object in both instances remains the old
>> > server
>> > name.
>> >
>> > When trying to do the metadata cleanup, after selecting the
>> > Default-First-Site-Name, when I list the servers, the DN is of the old
>> > server
>> > name.
>> >
>> > After getting out and back in to dsmgt and doing a 'remove selected
>> > server
>> > "<full DN of the server>" on localhost:389
>> >
>> > I receieve the LDAP error: 0x5e(94 no result present in message.
>> >
>> > Unable to determine the domain hosted by the DC
>> >
>> > DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)
>> >
>> > Thanks
>> >
>> > Ted
>> >
>> > "Lee Flight" wrote:
>> >
>> >> Hi
>> >>
>> >> seizing the roles and metadata cleanup should work in your situation.
>> >> What problems are you seeing when you try?
>> >>
>> >> Lee Flight
>> >>
>> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
>> >> >
>> >> > Let me break this down further....
>> >> >
>> >> > A) when I do a DSDiag, I can see the instance is still trying to
>> >> > refer
>> >> > to
>> >> > the old server name. How do I change the running instance to stop
>> >> > referring
>> >> > to the old server name but change it to the new server name?
>> >> >
>> >> > B) Although I've suspended outbound/inboud replication, how do I
>> >> > completely
>> >> > remove all replicas (and cease replication altogether) so that I can
>> >> > seize
>> >> > the roles and make the current instance the only instance?
>> >> >
>> >> > I would assume using metadata cleanup and seizing the naming and
>> >> > schema
>> >> > roles should take care of this for ADAM? Is that true?
>> >> >
>> >> > Thank you
>> >> >
>> >> > Ted
>> >> >
>> >> > "Ted Wagner" wrote:
>> >> >
>> >> >> I'm currently involved in a project where we had two ADAM instances
>> >> >> set
>> >> >> up...
>> >> >> one on two unique servers. One was a replica of the other. Our
>> >> >> new
>> >> >> application that will be using ADAM will be using AzMan and we will
>> >> >> be
>> >> >> adding
>> >> >> internal domain users to AzMan roles.
>> >> >>
>> >> >> The server name and service user is now different than the
>> >> >> original.
>> >> >> I'm
>> >> >> using a service account in the domain that has been granted proper
>> >> >> rights,
>> >> >> local admin, local admins is in the adminstrators ADAM role, etc.
>> >> >>
>> >> >> The requirement was to leave the primary ADAM instance running in
>> >> >> production, disable replication, move the replica instance
>> >> >> internally
>> >> >> to
>> >> >> our
>> >> >> domain.
>> >> >>
>> >> >> I changed the service user using dsdbutil, corrected the SCP errors
>> >> >> with
>> >> >> ADSIEdit in the domain.
>> >> >>
>> >> >> The Cisco firewall blocks all communication, so replication had to
>> >> >> be
>> >> >> suspended... which I did with repadmin
>> >> >>
>> >> >> I tried using metadata cleanup and seizing the naming and schema
>> >> >> master
>> >> >> roles. It appears that the instance of ADAM is not recognizing the
>> >> >> new
>> >> >> server
>> >> >> name. When I list servers in msmgmt, it shows the original server
>> >> >> name.
>> >> >> It
>> >> >> also appears that replication is still trying to take place.
>> >> >>
>> >> >> I'm unable to view one of the replicated partitions because
>> >> >> ADSIedit
>> >> >> gives
>> >> >> me a referral error.
>> >> >>
>> >> >> Is a migration even possible like this? I've seen Lee Flight
>> >> >> mention
>> >> >> that
>> >> >> a
>> >> >> better approach would be to back up and then restore onto a clean
>> >> >> server.
>> >> >> But, can the server name even be changed in a situation where the
>> >> >> replica's
>> >> >> server name is changed and then the roles are seized?
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Ted
>> >>
>> >>
>> >>
>>
>>
>>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156335 is a reply to message #156328] Mon, 15 June 2009 11:07 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Since our primary is still in production, I followed the procedure for
backing up and restoring ADAM onto another computer. That really IS the way
to go. Takes less than 10 mintues to do the service account change, scp fix
in AD, and the metadata cleanup.

So, now I have a copy of the schema and naming master on a single server
running in a single instance. I can connect to all the application
partitions and read data just fine.

I now am left with the "old" server name in the default-first-site-name
container. So, my question is, how do I change that name to match the
current server name?

here is the repadmin output

Default-First-Site-Name\ExtServer01$Extranet
DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
Site Options: (none)
DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08


==== KCC CONNECTION OBJECTS ============================================



"Lee Flight" wrote:

> Hi,
>
> if I have understood the server renaming that you did then
> I suspect that the object that embeds oldserver2 in the name
> may be the current (renamed) server and perhaps that is why
> your metadata cleanup attempt failed if you specified that server?
>
> Can we see the output from "list servers in site" from dsmgmt
> connected to the (migrated) server you are attempting to cleanup
> the replication connection on and also the output from:
>
> repadmin /showrepl /conn <server>:<port>
>
> run against that server.
>
> Thanks
> Lee Flight
>
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
> > Ah, ok, makes perfect sense. And, that is what happened with my metadata
> > cleanup.
> >
> > So, if manually remove the
> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT will
> > fix
> > up the replication? I've been looking through repadmin documentation and
> > there's noting about using that for ceasing replication between two
> > instances.
> >
> > Thanks
> >
> > Ted
> >
> > "Lee Flight" wrote:
> >
> >> Hi
> >>
> >> the reason that you are seeing the "DN of the object is the old server
> >> name" is that the server object in the your sites container still
> >> has the old server name embedded in it, so if you browse to the
> >> configuration naming context
> >> and then cn=sites
> >> and then cn=<your site name or Default-First-Site-Name>
> >> and then cn=Servers
> >>
> >> you will likely see a server object with the old server name embedded
> >> in it. This embedding is not a problem it's just a string, the FSMO roles
> >> that you have
> >> seized will be referencing the NTDS Settings object beneath the server
> >> object so it sounds like your FSMO roles have been seized correctly.
> >>
> >> On the metadata cleanup the DsRemoveDsServer error may be due
> >> to orphaned NTDS settings objects under the server objects you are
> >> attemtping to cleanup OR you may have the syntax wrong and be attempting
> >> to delete the server that you are currently connected to.
> >>
> >> If you are sure that your syntax is correct then
> >> you might want to delete the server objects that are no longer required
> >> directly from the cn=Servers container to clean up your replication
> >> connections but even that is not "required".
> >>
> >> As the instance is in production I would recommend that if you
> >> do wish to attempt ant further clean-up e.g. renaming the current
> >> server object or deleting obsolete servers directly that you do that
> >> in a test environment and of course always have a full backup.
> >>
> >> Lee Flight
> >>
> >>
> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
> >> > Hi Lee,
> >> >
> >> > When I try to seize the schema and naming roles, I receive the gui
> >> > prompt
> >> > confirming I want to seize the roles from server localhost:389. The DN
> >> > of
> >> > the object is the old server name.
> >> >
> >> > I click yes and I receive the message that the server knows about 2
> >> > roles,
> >> > however, the DN of the server object in both instances remains the old
> >> > server
> >> > name.
> >> >
> >> > When trying to do the metadata cleanup, after selecting the
> >> > Default-First-Site-Name, when I list the servers, the DN is of the old
> >> > server
> >> > name.
> >> >
> >> > After getting out and back in to dsmgt and doing a 'remove selected
> >> > server
> >> > "<full DN of the server>" on localhost:389
> >> >
> >> > I receieve the LDAP error: 0x5e(94 no result present in message.
> >> >
> >> > Unable to determine the domain hosted by the DC
> >> >
> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)
> >> >
> >> > Thanks
> >> >
> >> > Ted
> >> >
> >> > "Lee Flight" wrote:
> >> >
> >> >> Hi
> >> >>
> >> >> seizing the roles and metadata cleanup should work in your situation.
> >> >> What problems are you seeing when you try?
> >> >>
> >> >> Lee Flight
> >> >>
> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >> >> >
> >> >> > Let me break this down further....
> >> >> >
> >> >> > A) when I do a DSDiag, I can see the instance is still trying to
> >> >> > refer
> >> >> > to
> >> >> > the old server name. How do I change the running instance to stop
> >> >> > referring
> >> >> > to the old server name but change it to the new server name?
> >> >> >
> >> >> > B) Although I've suspended outbound/inboud replication, how do I
> >> >> > completely
> >> >> > remove all replicas (and cease replication altogether) so that I can
> >> >> > seize
> >> >> > the roles and make the current instance the only instance?
> >> >> >
> >> >> > I would assume using metadata cleanup and seizing the naming and
> >> >> > schema
> >> >> > roles should take care of this for ADAM? Is that true?
> >> >> >
> >> >> > Thank you
> >> >> >
> >> >> > Ted
> >> >> >
> >> >> > "Ted Wagner" wrote:
> >> >> >
> >> >> >> I'm currently involved in a project where we had two ADAM instances
> >> >> >> set
> >> >> >> up...
> >> >> >> one on two unique servers. One was a replica of the other. Our
> >> >> >> new
> >> >> >> application that will be using ADAM will be using AzMan and we will
> >> >> >> be
> >> >> >> adding
> >> >> >> internal domain users to AzMan roles.
> >> >> >>
> >> >> >> The server name and service user is now different than the
> >> >> >> original.
> >> >> >> I'm
> >> >> >> using a service account in the domain that has been granted proper
> >> >> >> rights,
> >> >> >> local admin, local admins is in the adminstrators ADAM role, etc.
> >> >> >>
> >> >> >> The requirement was to leave the primary ADAM instance running in
> >> >> >> production, disable replication, move the replica instance
> >> >> >> internally
> >> >> >> to
> >> >> >> our
> >> >> >> domain.
> >> >> >>
> >> >> >> I changed the service user using dsdbutil, corrected the SCP errors
> >> >> >> with
> >> >> >> ADSIEdit in the domain.
> >> >> >>
> >> >> >> The Cisco firewall blocks all communication, so replication had to
> >> >> >> be
> >> >> >> suspended... which I did with repadmin
> >> >> >>
> >> >> >> I tried using metadata cleanup and seizing the naming and schema
> >> >> >> master
> >> >> >> roles. It appears that the instance of ADAM is not recognizing the
> >> >> >> new
> >> >> >> server
> >> >> >> name. When I list servers in msmgmt, it shows the original server
> >> >> >> name.
> >> >> >> It
> >> >> >> also appears that replication is still trying to take place.
> >> >> >>
> >> >> >> I'm unable to view one of the replicated partitions because
> >> >> >> ADSIedit
> >> >> >> gives
> >> >> >> me a referral error.
> >> >> >>
> >> >> >> Is a migration even possible like this? I've seen Lee Flight
> >> >> >> mention
> >> >> >> that
> >> >> >> a
> >> >> >> better approach would be to back up and then restore onto a clean
> >> >> >> server.
> >> >> >> But, can the server name even be changed in a situation where the
> >> >> >> replica's
> >> >> >> server name is changed and then the roles are seized?
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Ted
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156337 is a reply to message #156335] Mon, 15 June 2009 11:30 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi

good to hear you went back to backup and restore it's
the right way. In my experience doing that fixes up the
server object names the

ExtServer01$Extranet

that you have below looks correct or is that not correct?
Can you post the full distinguishedName of the offending
object?

Thanks
Lee Flight

"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:9E1B42C9-9740-45CB-8A69-E5F5E38B1ACD@microsoft.com...
> Since our primary is still in production, I followed the procedure for
> backing up and restoring ADAM onto another computer. That really IS the
> way
> to go. Takes less than 10 mintues to do the service account change, scp
> fix
> in AD, and the metadata cleanup.
>
> So, now I have a copy of the schema and naming master on a single server
> running in a single instance. I can connect to all the application
> partitions and read data just fine.
>
> I now am left with the "old" server name in the default-first-site-name
> container. So, my question is, how do I change that name to match the
> current server name?
>
> here is the repadmin output
>
> Default-First-Site-Name\ExtServer01$Extranet
> DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
> Site Options: (none)
> DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
> DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08
>
>
> ==== KCC CONNECTION OBJECTS ============================================
>
>
>
> "Lee Flight" wrote:
>
>> Hi,
>>
>> if I have understood the server renaming that you did then
>> I suspect that the object that embeds oldserver2 in the name
>> may be the current (renamed) server and perhaps that is why
>> your metadata cleanup attempt failed if you specified that server?
>>
>> Can we see the output from "list servers in site" from dsmgmt
>> connected to the (migrated) server you are attempting to cleanup
>> the replication connection on and also the output from:
>>
>> repadmin /showrepl /conn <server>:<port>
>>
>> run against that server.
>>
>> Thanks
>> Lee Flight
>>
>>
>> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
>> > Ah, ok, makes perfect sense. And, that is what happened with my
>> > metadata
>> > cleanup.
>> >
>> > So, if manually remove the
>> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
>> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT
>> > will
>> > fix
>> > up the replication? I've been looking through repadmin documentation
>> > and
>> > there's noting about using that for ceasing replication between two
>> > instances.
>> >
>> > Thanks
>> >
>> > Ted
>> >
>> > "Lee Flight" wrote:
>> >
>> >> Hi
>> >>
>> >> the reason that you are seeing the "DN of the object is the old server
>> >> name" is that the server object in the your sites container still
>> >> has the old server name embedded in it, so if you browse to the
>> >> configuration naming context
>> >> and then cn=sites
>> >> and then cn=<your site name or Default-First-Site-Name>
>> >> and then cn=Servers
>> >>
>> >> you will likely see a server object with the old server name embedded
>> >> in it. This embedding is not a problem it's just a string, the FSMO
>> >> roles
>> >> that you have
>> >> seized will be referencing the NTDS Settings object beneath the server
>> >> object so it sounds like your FSMO roles have been seized correctly.
>> >>
>> >> On the metadata cleanup the DsRemoveDsServer error may be due
>> >> to orphaned NTDS settings objects under the server objects you are
>> >> attemtping to cleanup OR you may have the syntax wrong and be
>> >> attempting
>> >> to delete the server that you are currently connected to.
>> >>
>> >> If you are sure that your syntax is correct then
>> >> you might want to delete the server objects that are no longer
>> >> required
>> >> directly from the cn=Servers container to clean up your replication
>> >> connections but even that is not "required".
>> >>
>> >> As the instance is in production I would recommend that if you
>> >> do wish to attempt ant further clean-up e.g. renaming the current
>> >> server object or deleting obsolete servers directly that you do that
>> >> in a test environment and of course always have a full backup.
>> >>
>> >> Lee Flight
>> >>
>> >>
>> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
>> >> > Hi Lee,
>> >> >
>> >> > When I try to seize the schema and naming roles, I receive the gui
>> >> > prompt
>> >> > confirming I want to seize the roles from server localhost:389. The
>> >> > DN
>> >> > of
>> >> > the object is the old server name.
>> >> >
>> >> > I click yes and I receive the message that the server knows about 2
>> >> > roles,
>> >> > however, the DN of the server object in both instances remains the
>> >> > old
>> >> > server
>> >> > name.
>> >> >
>> >> > When trying to do the metadata cleanup, after selecting the
>> >> > Default-First-Site-Name, when I list the servers, the DN is of the
>> >> > old
>> >> > server
>> >> > name.
>> >> >
>> >> > After getting out and back in to dsmgt and doing a 'remove selected
>> >> > server
>> >> > "<full DN of the server>" on localhost:389
>> >> >
>> >> > I receieve the LDAP error: 0x5e(94 no result present in message.
>> >> >
>> >> > Unable to determine the domain hosted by the DC
>> >> >
>> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)
>> >> >
>> >> > Thanks
>> >> >
>> >> > Ted
>> >> >
>> >> > "Lee Flight" wrote:
>> >> >
>> >> >> Hi
>> >> >>
>> >> >> seizing the roles and metadata cleanup should work in your
>> >> >> situation.
>> >> >> What problems are you seeing when you try?
>> >> >>
>> >> >> Lee Flight
>> >> >>
>> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
>> >> >> >
>> >> >> > Let me break this down further....
>> >> >> >
>> >> >> > A) when I do a DSDiag, I can see the instance is still trying to
>> >> >> > refer
>> >> >> > to
>> >> >> > the old server name. How do I change the running instance to
>> >> >> > stop
>> >> >> > referring
>> >> >> > to the old server name but change it to the new server name?
>> >> >> >
>> >> >> > B) Although I've suspended outbound/inboud replication, how do I
>> >> >> > completely
>> >> >> > remove all replicas (and cease replication altogether) so that I
>> >> >> > can
>> >> >> > seize
>> >> >> > the roles and make the current instance the only instance?
>> >> >> >
>> >> >> > I would assume using metadata cleanup and seizing the naming and
>> >> >> > schema
>> >> >> > roles should take care of this for ADAM? Is that true?
>> >> >> >
>> >> >> > Thank you
>> >> >> >
>> >> >> > Ted
>> >> >> >
>> >> >> > "Ted Wagner" wrote:
>> >> >> >
>> >> >> >> I'm currently involved in a project where we had two ADAM
>> >> >> >> instances
>> >> >> >> set
>> >> >> >> up...
>> >> >> >> one on two unique servers. One was a replica of the other. Our
>> >> >> >> new
>> >> >> >> application that will be using ADAM will be using AzMan and we
>> >> >> >> will
>> >> >> >> be
>> >> >> >> adding
>> >> >> >> internal domain users to AzMan roles.
>> >> >> >>
>> >> >> >> The server name and service user is now different than the
>> >> >> >> original.
>> >> >> >> I'm
>> >> >> >> using a service account in the domain that has been granted
>> >> >> >> proper
>> >> >> >> rights,
>> >> >> >> local admin, local admins is in the adminstrators ADAM role,
>> >> >> >> etc.
>> >> >> >>
>> >> >> >> The requirement was to leave the primary ADAM instance running
>> >> >> >> in
>> >> >> >> production, disable replication, move the replica instance
>> >> >> >> internally
>> >> >> >> to
>> >> >> >> our
>> >> >> >> domain.
>> >> >> >>
>> >> >> >> I changed the service user using dsdbutil, corrected the SCP
>> >> >> >> errors
>> >> >> >> with
>> >> >> >> ADSIEdit in the domain.
>> >> >> >>
>> >> >> >> The Cisco firewall blocks all communication, so replication had
>> >> >> >> to
>> >> >> >> be
>> >> >> >> suspended... which I did with repadmin
>> >> >> >>
>> >> >> >> I tried using metadata cleanup and seizing the naming and schema
>> >> >> >> master
>> >> >> >> roles. It appears that the instance of ADAM is not recognizing
>> >> >> >> the
>> >> >> >> new
>> >> >> >> server
>> >> >> >> name. When I list servers in msmgmt, it shows the original
>> >> >> >> server
>> >> >> >> name.
>> >> >> >> It
>> >> >> >> also appears that replication is still trying to take place.
>> >> >> >>
>> >> >> >> I'm unable to view one of the replicated partitions because
>> >> >> >> ADSIedit
>> >> >> >> gives
>> >> >> >> me a referral error.
>> >> >> >>
>> >> >> >> Is a migration even possible like this? I've seen Lee Flight
>> >> >> >> mention
>> >> >> >> that
>> >> >> >> a
>> >> >> >> better approach would be to back up and then restore onto a
>> >> >> >> clean
>> >> >> >> server.
>> >> >> >> But, can the server name even be changed in a situation where
>> >> >> >> the
>> >> >> >> replica's
>> >> >> >> server name is changed and then the roles are seized?
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >>
>> >> >> >> Ted
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156338 is a reply to message #156337] Mon, 15 June 2009 12:09 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
The DN in ADAM is:

CN=ExServer01$Extranet,CN=Servers,CN=Default-First-Site-Name ,CN=Sites,CN=Configuration,CN={38E87918-118D-4790-868F-AF1B5 67AC051}

However, the new server name is IntServer110.

Ted

"Lee Flight" wrote:

> Hi
>
> good to hear you went back to backup and restore it's
> the right way. In my experience doing that fixes up the
> server object names the
>
> ExtServer01$Extranet
>
> that you have below looks correct or is that not correct?
> Can you post the full distinguishedName of the offending
> object?
>
> Thanks
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:9E1B42C9-9740-45CB-8A69-E5F5E38B1ACD@microsoft.com...
> > Since our primary is still in production, I followed the procedure for
> > backing up and restoring ADAM onto another computer. That really IS the
> > way
> > to go. Takes less than 10 mintues to do the service account change, scp
> > fix
> > in AD, and the metadata cleanup.
> >
> > So, now I have a copy of the schema and naming master on a single server
> > running in a single instance. I can connect to all the application
> > partitions and read data just fine.
> >
> > I now am left with the "old" server name in the default-first-site-name
> > container. So, my question is, how do I change that name to match the
> > current server name?
> >
> > here is the repadmin output
> >
> > Default-First-Site-Name\ExtServer01$Extranet
> > DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
> > Site Options: (none)
> > DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
> > DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08
> >
> >
> > ==== KCC CONNECTION OBJECTS ============================================
> >
> >
> >
> > "Lee Flight" wrote:
> >
> >> Hi,
> >>
> >> if I have understood the server renaming that you did then
> >> I suspect that the object that embeds oldserver2 in the name
> >> may be the current (renamed) server and perhaps that is why
> >> your metadata cleanup attempt failed if you specified that server?
> >>
> >> Can we see the output from "list servers in site" from dsmgmt
> >> connected to the (migrated) server you are attempting to cleanup
> >> the replication connection on and also the output from:
> >>
> >> repadmin /showrepl /conn <server>:<port>
> >>
> >> run against that server.
> >>
> >> Thanks
> >> Lee Flight
> >>
> >>
> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
> >> > Ah, ok, makes perfect sense. And, that is what happened with my
> >> > metadata
> >> > cleanup.
> >> >
> >> > So, if manually remove the
> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT
> >> > will
> >> > fix
> >> > up the replication? I've been looking through repadmin documentation
> >> > and
> >> > there's noting about using that for ceasing replication between two
> >> > instances.
> >> >
> >> > Thanks
> >> >
> >> > Ted
> >> >
> >> > "Lee Flight" wrote:
> >> >
> >> >> Hi
> >> >>
> >> >> the reason that you are seeing the "DN of the object is the old server
> >> >> name" is that the server object in the your sites container still
> >> >> has the old server name embedded in it, so if you browse to the
> >> >> configuration naming context
> >> >> and then cn=sites
> >> >> and then cn=<your site name or Default-First-Site-Name>
> >> >> and then cn=Servers
> >> >>
> >> >> you will likely see a server object with the old server name embedded
> >> >> in it. This embedding is not a problem it's just a string, the FSMO
> >> >> roles
> >> >> that you have
> >> >> seized will be referencing the NTDS Settings object beneath the server
> >> >> object so it sounds like your FSMO roles have been seized correctly.
> >> >>
> >> >> On the metadata cleanup the DsRemoveDsServer error may be due
> >> >> to orphaned NTDS settings objects under the server objects you are
> >> >> attemtping to cleanup OR you may have the syntax wrong and be
> >> >> attempting
> >> >> to delete the server that you are currently connected to.
> >> >>
> >> >> If you are sure that your syntax is correct then
> >> >> you might want to delete the server objects that are no longer
> >> >> required
> >> >> directly from the cn=Servers container to clean up your replication
> >> >> connections but even that is not "required".
> >> >>
> >> >> As the instance is in production I would recommend that if you
> >> >> do wish to attempt ant further clean-up e.g. renaming the current
> >> >> server object or deleting obsolete servers directly that you do that
> >> >> in a test environment and of course always have a full backup.
> >> >>
> >> >> Lee Flight
> >> >>
> >> >>
> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
> >> >> > Hi Lee,
> >> >> >
> >> >> > When I try to seize the schema and naming roles, I receive the gui
> >> >> > prompt
> >> >> > confirming I want to seize the roles from server localhost:389. The
> >> >> > DN
> >> >> > of
> >> >> > the object is the old server name.
> >> >> >
> >> >> > I click yes and I receive the message that the server knows about 2
> >> >> > roles,
> >> >> > however, the DN of the server object in both instances remains the
> >> >> > old
> >> >> > server
> >> >> > name.
> >> >> >
> >> >> > When trying to do the metadata cleanup, after selecting the
> >> >> > Default-First-Site-Name, when I list the servers, the DN is of the
> >> >> > old
> >> >> > server
> >> >> > name.
> >> >> >
> >> >> > After getting out and back in to dsmgt and doing a 'remove selected
> >> >> > server
> >> >> > "<full DN of the server>" on localhost:389
> >> >> >
> >> >> > I receieve the LDAP error: 0x5e(94 no result present in message.
> >> >> >
> >> >> > Unable to determine the domain hosted by the DC
> >> >> >
> >> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be deleted.)
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Ted
> >> >> >
> >> >> > "Lee Flight" wrote:
> >> >> >
> >> >> >> Hi
> >> >> >>
> >> >> >> seizing the roles and metadata cleanup should work in your
> >> >> >> situation.
> >> >> >> What problems are you seeing when you try?
> >> >> >>
> >> >> >> Lee Flight
> >> >> >>
> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >> >> >> >
> >> >> >> > Let me break this down further....
> >> >> >> >
> >> >> >> > A) when I do a DSDiag, I can see the instance is still trying to
> >> >> >> > refer
> >> >> >> > to
> >> >> >> > the old server name. How do I change the running instance to
> >> >> >> > stop
> >> >> >> > referring
> >> >> >> > to the old server name but change it to the new server name?
> >> >> >> >
> >> >> >> > B) Although I've suspended outbound/inboud replication, how do I
> >> >> >> > completely
> >> >> >> > remove all replicas (and cease replication altogether) so that I
> >> >> >> > can
> >> >> >> > seize
> >> >> >> > the roles and make the current instance the only instance?
> >> >> >> >
> >> >> >> > I would assume using metadata cleanup and seizing the naming and
> >> >> >> > schema
> >> >> >> > roles should take care of this for ADAM? Is that true?
> >> >> >> >
> >> >> >> > Thank you
> >> >> >> >
> >> >> >> > Ted
> >> >> >> >
> >> >> >> > "Ted Wagner" wrote:
> >> >> >> >
> >> >> >> >> I'm currently involved in a project where we had two ADAM
> >> >> >> >> instances
> >> >> >> >> set
> >> >> >> >> up...
> >> >> >> >> one on two unique servers. One was a replica of the other. Our
> >> >> >> >> new
> >> >> >> >> application that will be using ADAM will be using AzMan and we
> >> >> >> >> will
> >> >> >> >> be
> >> >> >> >> adding
> >> >> >> >> internal domain users to AzMan roles.
> >> >> >> >>
> >> >> >> >> The server name and service user is now different than the
> >> >> >> >> original.
> >> >> >> >> I'm
> >> >> >> >> using a service account in the domain that has been granted
> >> >> >> >> proper
> >> >> >> >> rights,
> >> >> >> >> local admin, local admins is in the adminstrators ADAM role,
> >> >> >> >> etc.
> >> >> >> >>
> >> >> >> >> The requirement was to leave the primary ADAM instance running
> >> >> >> >> in
> >> >> >> >> production, disable replication, move the replica instance
> >> >> >> >> internally
> >> >> >> >> to
> >> >> >> >> our
> >> >> >> >> domain.
> >> >> >> >>
> >> >> >> >> I changed the service user using dsdbutil, corrected the SCP
> >> >> >> >> errors
> >> >> >> >> with
> >> >> >> >> ADSIEdit in the domain.
> >> >> >> >>
> >> >> >> >> The Cisco firewall blocks all communication, so replication had
> >> >> >> >> to
> >> >> >> >> be
> >> >> >> >> suspended... which I did with repadmin
> >> >> >> >>
> >> >> >> >> I tried using metadata cleanup and seizing the naming and schema
> >> >> >> >> master
> >> >> >> >> roles. It appears that the instance of ADAM is not recognizing
> >> >> >> >> the
> >> >> >> >> new
> >> >> >> >> server
> >> >> >> >> name. When I list servers in msmgmt, it shows the original
> >> >> >> >> server
> >> >> >> >> name.
> >> >> >> >> It
> >> >> >> >> also appears that replication is still trying to take place.
> >> >> >> >>
> >> >> >> >> I'm unable to view one of the replicated partitions because
> >> >> >> >> ADSIedit
> >> >> >> >> gives
> >> >> >> >> me a referral error.
> >> >> >> >>
> >> >> >> >> Is a migration even possible like this? I've seen Lee Flight
> >> >> >> >> mention
> >> >> >> >> that
> >> >> >> >> a
> >> >> >> >> better approach would be to back up and then restore onto a
> >> >> >> >> clean
> >> >> >> >> server.
> >> >> >> >> But, can the server name even be changed in a situation where
> >> >> >> >> the
> >> >> >> >> replica's
> >> >> >> >> server name is changed and then the roles are seized?
> >> >> >> >>
> >> >> >> >> Thanks
> >> >> >> >>
> >> >> >> >> Ted
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156339 is a reply to message #156338] Mon, 15 June 2009 12:26 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi

so if that is now the only server object in the site you should be
OK to just rename that object using ADSIedit or ldp.exe, of
course do this with a test instance first.

It's worth bearing in
mind that this fixup is *not* required, things will run just fine as is,
as before this is just an embedding within a string it does not
"reference" the old server in any way it's just a name.

Lee Flight

"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:BE119321-E952-412E-863A-5D1585B3E9D9@microsoft.com...
> The DN in ADAM is:
>
> CN=ExServer01$Extranet,CN=Servers,CN=Default-First-Site-Name ,CN=Sites,CN=Configuration,CN={38E87918-118D-4790-868F-AF1B5 67AC051}
>
> However, the new server name is IntServer110.
>
> Ted
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> good to hear you went back to backup and restore it's
>> the right way. In my experience doing that fixes up the
>> server object names the
>>
>> ExtServer01$Extranet
>>
>> that you have below looks correct or is that not correct?
>> Can you post the full distinguishedName of the offending
>> object?
>>
>> Thanks
>> Lee Flight
>>
>> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> news:9E1B42C9-9740-45CB-8A69-E5F5E38B1ACD@microsoft.com...
>> > Since our primary is still in production, I followed the procedure for
>> > backing up and restoring ADAM onto another computer. That really IS
>> > the
>> > way
>> > to go. Takes less than 10 mintues to do the service account change,
>> > scp
>> > fix
>> > in AD, and the metadata cleanup.
>> >
>> > So, now I have a copy of the schema and naming master on a single
>> > server
>> > running in a single instance. I can connect to all the application
>> > partitions and read data just fine.
>> >
>> > I now am left with the "old" server name in the default-first-site-name
>> > container. So, my question is, how do I change that name to match the
>> > current server name?
>> >
>> > here is the repadmin output
>> >
>> > Default-First-Site-Name\ExtServer01$Extranet
>> > DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
>> > Site Options: (none)
>> > DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
>> > DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08
>> >
>> >
>> > ==== KCC CONNECTION OBJECTS
>> > ============================================
>> >
>> >
>> >
>> > "Lee Flight" wrote:
>> >
>> >> Hi,
>> >>
>> >> if I have understood the server renaming that you did then
>> >> I suspect that the object that embeds oldserver2 in the name
>> >> may be the current (renamed) server and perhaps that is why
>> >> your metadata cleanup attempt failed if you specified that server?
>> >>
>> >> Can we see the output from "list servers in site" from dsmgmt
>> >> connected to the (migrated) server you are attempting to cleanup
>> >> the replication connection on and also the output from:
>> >>
>> >> repadmin /showrepl /conn <server>:<port>
>> >>
>> >> run against that server.
>> >>
>> >> Thanks
>> >> Lee Flight
>> >>
>> >>
>> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
>> >> > Ah, ok, makes perfect sense. And, that is what happened with my
>> >> > metadata
>> >> > cleanup.
>> >> >
>> >> > So, if manually remove the
>> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
>> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT
>> >> > will
>> >> > fix
>> >> > up the replication? I've been looking through repadmin
>> >> > documentation
>> >> > and
>> >> > there's noting about using that for ceasing replication between two
>> >> > instances.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Ted
>> >> >
>> >> > "Lee Flight" wrote:
>> >> >
>> >> >> Hi
>> >> >>
>> >> >> the reason that you are seeing the "DN of the object is the old
>> >> >> server
>> >> >> name" is that the server object in the your sites container still
>> >> >> has the old server name embedded in it, so if you browse to the
>> >> >> configuration naming context
>> >> >> and then cn=sites
>> >> >> and then cn=<your site name or Default-First-Site-Name>
>> >> >> and then cn=Servers
>> >> >>
>> >> >> you will likely see a server object with the old server name
>> >> >> embedded
>> >> >> in it. This embedding is not a problem it's just a string, the FSMO
>> >> >> roles
>> >> >> that you have
>> >> >> seized will be referencing the NTDS Settings object beneath the
>> >> >> server
>> >> >> object so it sounds like your FSMO roles have been seized
>> >> >> correctly.
>> >> >>
>> >> >> On the metadata cleanup the DsRemoveDsServer error may be due
>> >> >> to orphaned NTDS settings objects under the server objects you are
>> >> >> attemtping to cleanup OR you may have the syntax wrong and be
>> >> >> attempting
>> >> >> to delete the server that you are currently connected to.
>> >> >>
>> >> >> If you are sure that your syntax is correct then
>> >> >> you might want to delete the server objects that are no longer
>> >> >> required
>> >> >> directly from the cn=Servers container to clean up your replication
>> >> >> connections but even that is not "required".
>> >> >>
>> >> >> As the instance is in production I would recommend that if you
>> >> >> do wish to attempt ant further clean-up e.g. renaming the current
>> >> >> server object or deleting obsolete servers directly that you do
>> >> >> that
>> >> >> in a test environment and of course always have a full backup.
>> >> >>
>> >> >> Lee Flight
>> >> >>
>> >> >>
>> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
>> >> >> > Hi Lee,
>> >> >> >
>> >> >> > When I try to seize the schema and naming roles, I receive the
>> >> >> > gui
>> >> >> > prompt
>> >> >> > confirming I want to seize the roles from server localhost:389.
>> >> >> > The
>> >> >> > DN
>> >> >> > of
>> >> >> > the object is the old server name.
>> >> >> >
>> >> >> > I click yes and I receive the message that the server knows about
>> >> >> > 2
>> >> >> > roles,
>> >> >> > however, the DN of the server object in both instances remains
>> >> >> > the
>> >> >> > old
>> >> >> > server
>> >> >> > name.
>> >> >> >
>> >> >> > When trying to do the metadata cleanup, after selecting the
>> >> >> > Default-First-Site-Name, when I list the servers, the DN is of
>> >> >> > the
>> >> >> > old
>> >> >> > server
>> >> >> > name.
>> >> >> >
>> >> >> > After getting out and back in to dsmgt and doing a 'remove
>> >> >> > selected
>> >> >> > server
>> >> >> > "<full DN of the server>" on localhost:389
>> >> >> >
>> >> >> > I receieve the LDAP error: 0x5e(94 no result present in message.
>> >> >> >
>> >> >> > Unable to determine the domain hosted by the DC
>> >> >> >
>> >> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be
>> >> >> > deleted.)
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > Ted
>> >> >> >
>> >> >> > "Lee Flight" wrote:
>> >> >> >
>> >> >> >> Hi
>> >> >> >>
>> >> >> >> seizing the roles and metadata cleanup should work in your
>> >> >> >> situation.
>> >> >> >> What problems are you seeing when you try?
>> >> >> >>
>> >> >> >> Lee Flight
>> >> >> >>
>> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in
>> >> >> >> message
>> >> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
>> >> >> >> >
>> >> >> >> > Let me break this down further....
>> >> >> >> >
>> >> >> >> > A) when I do a DSDiag, I can see the instance is still trying
>> >> >> >> > to
>> >> >> >> > refer
>> >> >> >> > to
>> >> >> >> > the old server name. How do I change the running instance to
>> >> >> >> > stop
>> >> >> >> > referring
>> >> >> >> > to the old server name but change it to the new server name?
>> >> >> >> >
>> >> >> >> > B) Although I've suspended outbound/inboud replication, how do
>> >> >> >> > I
>> >> >> >> > completely
>> >> >> >> > remove all replicas (and cease replication altogether) so that
>> >> >> >> > I
>> >> >> >> > can
>> >> >> >> > seize
>> >> >> >> > the roles and make the current instance the only instance?
>> >> >> >> >
>> >> >> >> > I would assume using metadata cleanup and seizing the naming
>> >> >> >> > and
>> >> >> >> > schema
>> >> >> >> > roles should take care of this for ADAM? Is that true?
>> >> >> >> >
>> >> >> >> > Thank you
>> >> >> >> >
>> >> >> >> > Ted
>> >> >> >> >
>> >> >> >> > "Ted Wagner" wrote:
>> >> >> >> >
>> >> >> >> >> I'm currently involved in a project where we had two ADAM
>> >> >> >> >> instances
>> >> >> >> >> set
>> >> >> >> >> up...
>> >> >> >> >> one on two unique servers. One was a replica of the other.
>> >> >> >> >> Our
>> >> >> >> >> new
>> >> >> >> >> application that will be using ADAM will be using AzMan and
>> >> >> >> >> we
>> >> >> >> >> will
>> >> >> >> >> be
>> >> >> >> >> adding
>> >> >> >> >> internal domain users to AzMan roles.
>> >> >> >> >>
>> >> >> >> >> The server name and service user is now different than the
>> >> >> >> >> original.
>> >> >> >> >> I'm
>> >> >> >> >> using a service account in the domain that has been granted
>> >> >> >> >> proper
>> >> >> >> >> rights,
>> >> >> >> >> local admin, local admins is in the adminstrators ADAM role,
>> >> >> >> >> etc.
>> >> >> >> >>
>> >> >> >> >> The requirement was to leave the primary ADAM instance
>> >> >> >> >> running
>> >> >> >> >> in
>> >> >> >> >> production, disable replication, move the replica instance
>> >> >> >> >> internally
>> >> >> >> >> to
>> >> >> >> >> our
>> >> >> >> >> domain.
>> >> >> >> >>
>> >> >> >> >> I changed the service user using dsdbutil, corrected the SCP
>> >> >> >> >> errors
>> >> >> >> >> with
>> >> >> >> >> ADSIEdit in the domain.
>> >> >> >> >>
>> >> >> >> >> The Cisco firewall blocks all communication, so replication
>> >> >> >> >> had
>> >> >> >> >> to
>> >> >> >> >> be
>> >> >> >> >> suspended... which I did with repadmin
>> >> >> >> >>
>> >> >> >> >> I tried using metadata cleanup and seizing the naming and
>> >> >> >> >> schema
>> >> >> >> >> master
>> >> >> >> >> roles. It appears that the instance of ADAM is not
>> >> >> >> >> recognizing
>> >> >> >> >> the
>> >> >> >> >> new
>> >> >> >> >> server
>> >> >> >> >> name. When I list servers in msmgmt, it shows the original
>> >> >> >> >> server
>> >> >> >> >> name.
>> >> >> >> >> It
>> >> >> >> >> also appears that replication is still trying to take place.
>> >> >> >> >>
>> >> >> >> >> I'm unable to view one of the replicated partitions because
>> >> >> >> >> ADSIedit
>> >> >> >> >> gives
>> >> >> >> >> me a referral error.
>> >> >> >> >>
>> >> >> >> >> Is a migration even possible like this? I've seen Lee Flight
>> >> >> >> >> mention
>> >> >> >> >> that
>> >> >> >> >> a
>> >> >> >> >> better approach would be to back up and then restore onto a
>> >> >> >> >> clean
>> >> >> >> >> server.
>> >> >> >> >> But, can the server name even be changed in a situation where
>> >> >> >> >> the
>> >> >> >> >> replica's
>> >> >> >> >> server name is changed and then the roles are seized?
>> >> >> >> >>
>> >> >> >> >> Thanks
>> >> >> >> >>
>> >> >> >> >> Ted
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156340 is a reply to message #156339] Mon, 15 June 2009 13:16 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Ah, ok. That's what I kind of gathered from another post you had and that
makes sense. I don't see any errors in the event log so it has run fine all
weekend.

So, I should be good to set up a new instance that will be the new replica.

I'll do that in test first.

Thanks for everything!

Ted

"Lee Flight" wrote:

> Hi
>
> so if that is now the only server object in the site you should be
> OK to just rename that object using ADSIedit or ldp.exe, of
> course do this with a test instance first.
>
> It's worth bearing in
> mind that this fixup is *not* required, things will run just fine as is,
> as before this is just an embedding within a string it does not
> "reference" the old server in any way it's just a name.
>
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:BE119321-E952-412E-863A-5D1585B3E9D9@microsoft.com...
> > The DN in ADAM is:
> >
> > CN=ExServer01$Extranet,CN=Servers,CN=Default-First-Site-Name ,CN=Sites,CN=Configuration,CN={38E87918-118D-4790-868F-AF1B5 67AC051}
> >
> > However, the new server name is IntServer110.
> >
> > Ted
> >
> > "Lee Flight" wrote:
> >
> >> Hi
> >>
> >> good to hear you went back to backup and restore it's
> >> the right way. In my experience doing that fixes up the
> >> server object names the
> >>
> >> ExtServer01$Extranet
> >>
> >> that you have below looks correct or is that not correct?
> >> Can you post the full distinguishedName of the offending
> >> object?
> >>
> >> Thanks
> >> Lee Flight
> >>
> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> news:9E1B42C9-9740-45CB-8A69-E5F5E38B1ACD@microsoft.com...
> >> > Since our primary is still in production, I followed the procedure for
> >> > backing up and restoring ADAM onto another computer. That really IS
> >> > the
> >> > way
> >> > to go. Takes less than 10 mintues to do the service account change,
> >> > scp
> >> > fix
> >> > in AD, and the metadata cleanup.
> >> >
> >> > So, now I have a copy of the schema and naming master on a single
> >> > server
> >> > running in a single instance. I can connect to all the application
> >> > partitions and read data just fine.
> >> >
> >> > I now am left with the "old" server name in the default-first-site-name
> >> > container. So, my question is, how do I change that name to match the
> >> > current server name?
> >> >
> >> > here is the repadmin output
> >> >
> >> > Default-First-Site-Name\ExtServer01$Extranet
> >> > DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
> >> > Site Options: (none)
> >> > DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
> >> > DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08
> >> >
> >> >
> >> > ==== KCC CONNECTION OBJECTS
> >> > ============================================
> >> >
> >> >
> >> >
> >> > "Lee Flight" wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> if I have understood the server renaming that you did then
> >> >> I suspect that the object that embeds oldserver2 in the name
> >> >> may be the current (renamed) server and perhaps that is why
> >> >> your metadata cleanup attempt failed if you specified that server?
> >> >>
> >> >> Can we see the output from "list servers in site" from dsmgmt
> >> >> connected to the (migrated) server you are attempting to cleanup
> >> >> the replication connection on and also the output from:
> >> >>
> >> >> repadmin /showrepl /conn <server>:<port>
> >> >>
> >> >> run against that server.
> >> >>
> >> >> Thanks
> >> >> Lee Flight
> >> >>
> >> >>
> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
> >> >> > Ah, ok, makes perfect sense. And, that is what happened with my
> >> >> > metadata
> >> >> > cleanup.
> >> >> >
> >> >> > So, if manually remove the
> >> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
> >> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT
> >> >> > will
> >> >> > fix
> >> >> > up the replication? I've been looking through repadmin
> >> >> > documentation
> >> >> > and
> >> >> > there's noting about using that for ceasing replication between two
> >> >> > instances.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Ted
> >> >> >
> >> >> > "Lee Flight" wrote:
> >> >> >
> >> >> >> Hi
> >> >> >>
> >> >> >> the reason that you are seeing the "DN of the object is the old
> >> >> >> server
> >> >> >> name" is that the server object in the your sites container still
> >> >> >> has the old server name embedded in it, so if you browse to the
> >> >> >> configuration naming context
> >> >> >> and then cn=sites
> >> >> >> and then cn=<your site name or Default-First-Site-Name>
> >> >> >> and then cn=Servers
> >> >> >>
> >> >> >> you will likely see a server object with the old server name
> >> >> >> embedded
> >> >> >> in it. This embedding is not a problem it's just a string, the FSMO
> >> >> >> roles
> >> >> >> that you have
> >> >> >> seized will be referencing the NTDS Settings object beneath the
> >> >> >> server
> >> >> >> object so it sounds like your FSMO roles have been seized
> >> >> >> correctly.
> >> >> >>
> >> >> >> On the metadata cleanup the DsRemoveDsServer error may be due
> >> >> >> to orphaned NTDS settings objects under the server objects you are
> >> >> >> attemtping to cleanup OR you may have the syntax wrong and be
> >> >> >> attempting
> >> >> >> to delete the server that you are currently connected to.
> >> >> >>
> >> >> >> If you are sure that your syntax is correct then
> >> >> >> you might want to delete the server objects that are no longer
> >> >> >> required
> >> >> >> directly from the cn=Servers container to clean up your replication
> >> >> >> connections but even that is not "required".
> >> >> >>
> >> >> >> As the instance is in production I would recommend that if you
> >> >> >> do wish to attempt ant further clean-up e.g. renaming the current
> >> >> >> server object or deleting obsolete servers directly that you do
> >> >> >> that
> >> >> >> in a test environment and of course always have a full backup.
> >> >> >>
> >> >> >> Lee Flight
> >> >> >>
> >> >> >>
> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
> >> >> >> > Hi Lee,
> >> >> >> >
> >> >> >> > When I try to seize the schema and naming roles, I receive the
> >> >> >> > gui
> >> >> >> > prompt
> >> >> >> > confirming I want to seize the roles from server localhost:389.
> >> >> >> > The
> >> >> >> > DN
> >> >> >> > of
> >> >> >> > the object is the old server name.
> >> >> >> >
> >> >> >> > I click yes and I receive the message that the server knows about
> >> >> >> > 2
> >> >> >> > roles,
> >> >> >> > however, the DN of the server object in both instances remains
> >> >> >> > the
> >> >> >> > old
> >> >> >> > server
> >> >> >> > name.
> >> >> >> >
> >> >> >> > When trying to do the metadata cleanup, after selecting the
> >> >> >> > Default-First-Site-Name, when I list the servers, the DN is of
> >> >> >> > the
> >> >> >> > old
> >> >> >> > server
> >> >> >> > name.
> >> >> >> >
> >> >> >> > After getting out and back in to dsmgt and doing a 'remove
> >> >> >> > selected
> >> >> >> > server
> >> >> >> > "<full DN of the server>" on localhost:389
> >> >> >> >
> >> >> >> > I receieve the LDAP error: 0x5e(94 no result present in message.
> >> >> >> >
> >> >> >> > Unable to determine the domain hosted by the DC
> >> >> >> >
> >> >> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be
> >> >> >> > deleted.)
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > Ted
> >> >> >> >
> >> >> >> > "Lee Flight" wrote:
> >> >> >> >
> >> >> >> >> Hi
> >> >> >> >>
> >> >> >> >> seizing the roles and metadata cleanup should work in your
> >> >> >> >> situation.
> >> >> >> >> What problems are you seeing when you try?
> >> >> >> >>
> >> >> >> >> Lee Flight
> >> >> >> >>
> >> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in
> >> >> >> >> message
> >> >> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >> >> >> >> >
> >> >> >> >> > Let me break this down further....
> >> >> >> >> >
> >> >> >> >> > A) when I do a DSDiag, I can see the instance is still trying
> >> >> >> >> > to
> >> >> >> >> > refer
> >> >> >> >> > to
> >> >> >> >> > the old server name. How do I change the running instance to
> >> >> >> >> > stop
> >> >> >> >> > referring
> >> >> >> >> > to the old server name but change it to the new server name?
> >> >> >> >> >
> >> >> >> >> > B) Although I've suspended outbound/inboud replication, how do
> >> >> >> >> > I
> >> >> >> >> > completely
> >> >> >> >> > remove all replicas (and cease replication altogether) so that
> >> >> >> >> > I
> >> >> >> >> > can
> >> >> >> >> > seize
> >> >> >> >> > the roles and make the current instance the only instance?
> >> >> >> >> >
> >> >> >> >> > I would assume using metadata cleanup and seizing the naming
> >> >> >> >> > and
> >> >> >> >> > schema
> >> >> >> >> > roles should take care of this for ADAM? Is that true?
> >> >> >> >> >
> >> >> >> >> > Thank you
> >> >> >> >> >
> >> >> >> >> > Ted
> >> >> >> >> >
> >> >> >> >> > "Ted Wagner" wrote:
> >> >> >> >> >
> >> >> >> >> >> I'm currently involved in a project where we had two ADAM
> >> >> >> >> >> instances
> >> >> >> >> >> set
> >> >> >> >> >> up...
> >> >> >> >> >> one on two unique servers. One was a replica of the other.
> >> >> >> >> >> Our
> >> >> >> >> >> new
> >> >> >> >> >> application that will be using ADAM will be using AzMan and
> >> >> >> >> >> we
> >> >> >> >> >> will
> >> >> >> >> >> be
> >> >> >> >> >> adding
> >> >> >> >> >> internal domain users to AzMan roles.
> >> >> >> >> >>
> >> >> >> >> >> The server name and service user is now different than the
> >> >> >> >> >> original.
> >> >> >> >> >> I'm
> >> >> >> >> >> using a service account in the domain that has been granted
> >> >> >> >> >> proper
> >> >> >> >> >> rights,
> >> >> >> >> >> local admin, local admins is in the adminstrators ADAM role,
> >> >> >> >> >> etc.
> >> >> >> >> >>
> >> >> >> >> >> The requirement was to leave the primary ADAM instance
> >> >> >> >> >> running
> >> >> >> >> >> in
> >> >> >> >> >> production, disable replication, move the replica instance
> >> >> >> >> >> internally
> >> >> >> >> >> to
> >> >> >> >> >> our
> >> >> >> >> >> domain.
> >> >> >> >> >>
> >> >> >> >> >> I changed the service user using dsdbutil, corrected the SCP
> >> >> >> >> >> errors
> >> >> >> >> >> with
> >> >> >> >> >> ADSIEdit in the domain.
> >> >> >> >> >>
> >> >> >> >> >> The Cisco firewall blocks all communication, so replication
> >> >> >> >> >> had
> >> >> >> >> >> to
> >> >> >> >> >> be
> >> >> >> >> >> suspended... which I did with repadmin
> >> >> >> >> >>
> >> >> >> >> >> I tried using metadata cleanup and seizing the naming and
> >> >> >> >> >> schema
> >> >> >> >> >> master
> >> >> >> >> >> roles. It appears that the instance of ADAM is not
> >> >> >> >> >> recognizing
> >> >> >> >> >> the
> >> >> >> >> >> new
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156392 is a reply to message #156339] Tue, 16 June 2009 10:49 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Lee,

Many thanks again. Renaming the CN in the server container does indeed work
just fine. You are right, it's not needed, it's just an attribute value at
that point. The critical value is the GUID.

I set up several tests with setting up new replication partners, works like
a champ. So, now I've documented the full set of steps (for DR purposes)
when migrating a workgroup instance of ADAM onto a server joined to a domain.

I will weigh in 100% on the side of doing a backup and then a restore of the
master instance. ALL of the steps would take less than 30 minutes for a
small ADAM instance and less than 10 once you've done it a few times.

Thanks again.

Ted
"Lee Flight" wrote:

> Hi
>
> so if that is now the only server object in the site you should be
> OK to just rename that object using ADSIedit or ldp.exe, of
> course do this with a test instance first.
>
> It's worth bearing in
> mind that this fixup is *not* required, things will run just fine as is,
> as before this is just an embedding within a string it does not
> "reference" the old server in any way it's just a name.
>
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:BE119321-E952-412E-863A-5D1585B3E9D9@microsoft.com...
> > The DN in ADAM is:
> >
> > CN=ExServer01$Extranet,CN=Servers,CN=Default-First-Site-Name ,CN=Sites,CN=Configuration,CN={38E87918-118D-4790-868F-AF1B5 67AC051}
> >
> > However, the new server name is IntServer110.
> >
> > Ted
> >
> > "Lee Flight" wrote:
> >
> >> Hi
> >>
> >> good to hear you went back to backup and restore it's
> >> the right way. In my experience doing that fixes up the
> >> server object names the
> >>
> >> ExtServer01$Extranet
> >>
> >> that you have below looks correct or is that not correct?
> >> Can you post the full distinguishedName of the offending
> >> object?
> >>
> >> Thanks
> >> Lee Flight
> >>
> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> news:9E1B42C9-9740-45CB-8A69-E5F5E38B1ACD@microsoft.com...
> >> > Since our primary is still in production, I followed the procedure for
> >> > backing up and restoring ADAM onto another computer. That really IS
> >> > the
> >> > way
> >> > to go. Takes less than 10 mintues to do the service account change,
> >> > scp
> >> > fix
> >> > in AD, and the metadata cleanup.
> >> >
> >> > So, now I have a copy of the schema and naming master on a single
> >> > server
> >> > running in a single instance. I can connect to all the application
> >> > partitions and read data just fine.
> >> >
> >> > I now am left with the "old" server name in the default-first-site-name
> >> > container. So, my question is, how do I change that name to match the
> >> > current server name?
> >> >
> >> > here is the repadmin output
> >> >
> >> > Default-First-Site-Name\ExtServer01$Extranet
> >> > DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
> >> > Site Options: (none)
> >> > DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
> >> > DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08
> >> >
> >> >
> >> > ==== KCC CONNECTION OBJECTS
> >> > ============================================
> >> >
> >> >
> >> >
> >> > "Lee Flight" wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> if I have understood the server renaming that you did then
> >> >> I suspect that the object that embeds oldserver2 in the name
> >> >> may be the current (renamed) server and perhaps that is why
> >> >> your metadata cleanup attempt failed if you specified that server?
> >> >>
> >> >> Can we see the output from "list servers in site" from dsmgmt
> >> >> connected to the (migrated) server you are attempting to cleanup
> >> >> the replication connection on and also the output from:
> >> >>
> >> >> repadmin /showrepl /conn <server>:<port>
> >> >>
> >> >> run against that server.
> >> >>
> >> >> Thanks
> >> >> Lee Flight
> >> >>
> >> >>
> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
> >> >> > Ah, ok, makes perfect sense. And, that is what happened with my
> >> >> > metadata
> >> >> > cleanup.
> >> >> >
> >> >> > So, if manually remove the
> >> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1 and
> >> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2 THAT
> >> >> > will
> >> >> > fix
> >> >> > up the replication? I've been looking through repadmin
> >> >> > documentation
> >> >> > and
> >> >> > there's noting about using that for ceasing replication between two
> >> >> > instances.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Ted
> >> >> >
> >> >> > "Lee Flight" wrote:
> >> >> >
> >> >> >> Hi
> >> >> >>
> >> >> >> the reason that you are seeing the "DN of the object is the old
> >> >> >> server
> >> >> >> name" is that the server object in the your sites container still
> >> >> >> has the old server name embedded in it, so if you browse to the
> >> >> >> configuration naming context
> >> >> >> and then cn=sites
> >> >> >> and then cn=<your site name or Default-First-Site-Name>
> >> >> >> and then cn=Servers
> >> >> >>
> >> >> >> you will likely see a server object with the old server name
> >> >> >> embedded
> >> >> >> in it. This embedding is not a problem it's just a string, the FSMO
> >> >> >> roles
> >> >> >> that you have
> >> >> >> seized will be referencing the NTDS Settings object beneath the
> >> >> >> server
> >> >> >> object so it sounds like your FSMO roles have been seized
> >> >> >> correctly.
> >> >> >>
> >> >> >> On the metadata cleanup the DsRemoveDsServer error may be due
> >> >> >> to orphaned NTDS settings objects under the server objects you are
> >> >> >> attemtping to cleanup OR you may have the syntax wrong and be
> >> >> >> attempting
> >> >> >> to delete the server that you are currently connected to.
> >> >> >>
> >> >> >> If you are sure that your syntax is correct then
> >> >> >> you might want to delete the server objects that are no longer
> >> >> >> required
> >> >> >> directly from the cn=Servers container to clean up your replication
> >> >> >> connections but even that is not "required".
> >> >> >>
> >> >> >> As the instance is in production I would recommend that if you
> >> >> >> do wish to attempt ant further clean-up e.g. renaming the current
> >> >> >> server object or deleting obsolete servers directly that you do
> >> >> >> that
> >> >> >> in a test environment and of course always have a full backup.
> >> >> >>
> >> >> >> Lee Flight
> >> >> >>
> >> >> >>
> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> >> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
> >> >> >> > Hi Lee,
> >> >> >> >
> >> >> >> > When I try to seize the schema and naming roles, I receive the
> >> >> >> > gui
> >> >> >> > prompt
> >> >> >> > confirming I want to seize the roles from server localhost:389.
> >> >> >> > The
> >> >> >> > DN
> >> >> >> > of
> >> >> >> > the object is the old server name.
> >> >> >> >
> >> >> >> > I click yes and I receive the message that the server knows about
> >> >> >> > 2
> >> >> >> > roles,
> >> >> >> > however, the DN of the server object in both instances remains
> >> >> >> > the
> >> >> >> > old
> >> >> >> > server
> >> >> >> > name.
> >> >> >> >
> >> >> >> > When trying to do the metadata cleanup, after selecting the
> >> >> >> > Default-First-Site-Name, when I list the servers, the DN is of
> >> >> >> > the
> >> >> >> > old
> >> >> >> > server
> >> >> >> > name.
> >> >> >> >
> >> >> >> > After getting out and back in to dsmgt and doing a 'remove
> >> >> >> > selected
> >> >> >> > server
> >> >> >> > "<full DN of the server>" on localhost:389
> >> >> >> >
> >> >> >> > I receieve the LDAP error: 0x5e(94 no result present in message.
> >> >> >> >
> >> >> >> > Unable to determine the domain hosted by the DC
> >> >> >> >
> >> >> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be
> >> >> >> > deleted.)
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > Ted
> >> >> >> >
> >> >> >> > "Lee Flight" wrote:
> >> >> >> >
> >> >> >> >> Hi
> >> >> >> >>
> >> >> >> >> seizing the roles and metadata cleanup should work in your
> >> >> >> >> situation.
> >> >> >> >> What problems are you seeing when you try?
> >> >> >> >>
> >> >> >> >> Lee Flight
> >> >> >> >>
> >> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in
> >> >> >> >> message
> >> >> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
> >> >> >> >> >
> >> >> >> >> > Let me break this down further....
> >> >> >> >> >
> >> >> >> >> > A) when I do a DSDiag, I can see the instance is still trying
> >> >> >> >> > to
> >> >> >> >> > refer
> >> >> >> >> > to
> >> >> >> >> > the old server name. How do I change the running instance to
> >> >> >> >> > stop
> >> >> >> >> > referring
> >> >> >> >> > to the old server name but change it to the new server name?
> >> >> >> >> >
> >> >> >> >> > B) Although I've suspended outbound/inboud replication, how do
> >> >> >> >> > I
> >> >> >> >> > completely
> >> >> >> >> > remove all replicas (and cease replication altogether) so that
> >> >> >> >> > I
> >> >> >> >> > can
> >> >> >> >> > seize
> >> >> >> >> > the roles and make the current instance the only instance?
> >> >> >> >> >
> >> >> >> >> > I would assume using metadata cleanup and seizing the naming
> >> >> >> >> > and
> >> >> >> >> > schema
> >> >> >> >> > roles should take care of this for ADAM? Is that true?
> >> >> >> >> >
> >> >> >> >> > Thank you
> >> >> >> >> >
> >> >> >> >> > Ted
> >> >> >> >> >
> >> >> >> >> > "Ted Wagner" wrote:
> >> >> >> >> >
> >> >> >> >> >> I'm currently involved in a project where we had two ADAM
> >> >> >> >> >> instances
> >> >> >> >> >> set
> >> >> >> >> >> up...
> >> >> >> >> >> one on two unique servers. One was a replica of the other.
> >> >> >> >> >> Our
> >> >> >> >> >> new
> >> >> >> >> >> application that will be using ADAM will be using AzMan and
> >> >> >> >> >> we
> >> >> >> >> >> will
> >> >> >> >> >> be
> >> >> >> >> >> adding
> >> >> >> >> >> internal domain users to AzMan roles.
> >> >> >> >> >>
> >> >> >> >> >> The server name and service user is now different than the
> >> >> >> >> >> original.
> >> >> >> >> >> I'm
> >> >> >> >> >> using a service account in the domain that has been granted
> >> >> >> >> >> proper
> >> >> >> >> >> rights,
> >> >> >> >> >> local admin, local admins is in the adminstrators ADAM role,
> >> >> >> >> >> etc.
> >> >> >> >> >>
> >> >> >> >> >> The requirement was to leave the primary ADAM instance
> >> >> >> >> >> running
> >> >> >> >> >> in
> >> >> >> >> >> production, disable replication, move the replica instance
> >> >> >> >> >> internally
> >> >> >> >> >> to
> >> >> >> >> >> our
> >> >> >> >> >> domain.
> >> >> >> >> >>
> >> >> >> >> >> I changed the service user using dsdbutil, corrected the SCP
> >> >> >> >> >> errors
> >> >> >> >> >> with
> >> >> >> >> >> ADSIEdit in the domain.
> >> >> >> >> >>
> >> >> >> >> >> The Cisco firewall blocks all communication, so replication
> >> >> >> >> >> had
> >> >> >> >> >> to
> >> >> >> >> >> be
> >> >> >> >> >> suspended... which I did with repadmin
> >> >> >> >> >>
> >> >> >> >> >> I tried using metadata cleanup and seizing the naming and
> >> >> >> >> >> schema
> >> >> >> >> >> master
> >> >> >> >> >> roles. It appears that the instance of ADAM is not
> >> >> >> >> >> recognizing
> >> >> >> >> >> the
> >> >> >> >> >> new
Re: ADAM - Migration of Replica from Workgroup to Domain question [message #156395 is a reply to message #156392] Tue, 16 June 2009 11:11 Go to previous message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Glad you have not got this working, thanks for following up
hopefully this thread will help others.

Lee Flight

"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:5F19C1F0-F07A-48F6-A965-2EEB59106A60@microsoft.com...
> Lee,
>
> Many thanks again. Renaming the CN in the server container does indeed
> work
> just fine. You are right, it's not needed, it's just an attribute value
> at
> that point. The critical value is the GUID.
>
> I set up several tests with setting up new replication partners, works
> like
> a champ. So, now I've documented the full set of steps (for DR purposes)
> when migrating a workgroup instance of ADAM onto a server joined to a
> domain.
>
> I will weigh in 100% on the side of doing a backup and then a restore of
> the
> master instance. ALL of the steps would take less than 30 minutes for a
> small ADAM instance and less than 10 once you've done it a few times.
>
> Thanks again.
>
> Ted
> "Lee Flight" wrote:
>
>> Hi
>>
>> so if that is now the only server object in the site you should be
>> OK to just rename that object using ADSIedit or ldp.exe, of
>> course do this with a test instance first.
>>
>> It's worth bearing in
>> mind that this fixup is *not* required, things will run just fine as is,
>> as before this is just an embedding within a string it does not
>> "reference" the old server in any way it's just a name.
>>
>> Lee Flight
>>
>> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> news:BE119321-E952-412E-863A-5D1585B3E9D9@microsoft.com...
>> > The DN in ADAM is:
>> >
>> > CN=ExServer01$Extranet,CN=Servers,CN=Default-First-Site-Name ,CN=Sites,CN=Configuration,CN={38E87918-118D-4790-868F-AF1B5 67AC051}
>> >
>> > However, the new server name is IntServer110.
>> >
>> > Ted
>> >
>> > "Lee Flight" wrote:
>> >
>> >> Hi
>> >>
>> >> good to hear you went back to backup and restore it's
>> >> the right way. In my experience doing that fixes up the
>> >> server object names the
>> >>
>> >> ExtServer01$Extranet
>> >>
>> >> that you have below looks correct or is that not correct?
>> >> Can you post the full distinguishedName of the offending
>> >> object?
>> >>
>> >> Thanks
>> >> Lee Flight
>> >>
>> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> news:9E1B42C9-9740-45CB-8A69-E5F5E38B1ACD@microsoft.com...
>> >> > Since our primary is still in production, I followed the procedure
>> >> > for
>> >> > backing up and restoring ADAM onto another computer. That really IS
>> >> > the
>> >> > way
>> >> > to go. Takes less than 10 mintues to do the service account change,
>> >> > scp
>> >> > fix
>> >> > in AD, and the metadata cleanup.
>> >> >
>> >> > So, now I have a copy of the schema and naming master on a single
>> >> > server
>> >> > running in a single instance. I can connect to all the application
>> >> > partitions and read data just fine.
>> >> >
>> >> > I now am left with the "old" server name in the
>> >> > default-first-site-name
>> >> > container. So, my question is, how do I change that name to match
>> >> > the
>> >> > current server name?
>> >> >
>> >> > here is the repadmin output
>> >> >
>> >> > Default-First-Site-Name\ExtServer01$Extranet
>> >> > DSA Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
>> >> > Site Options: (none)
>> >> > DSA object GUID: 25188d3d-68a3-42e3-9165-b2d048456f0d
>> >> > DSA invocationID: 3abca1f5-de9f-4efd-ad62-cf176c1f0d08
>> >> >
>> >> >
>> >> > ==== KCC CONNECTION OBJECTS
>> >> > ============================================
>> >> >
>> >> >
>> >> >
>> >> > "Lee Flight" wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> if I have understood the server renaming that you did then
>> >> >> I suspect that the object that embeds oldserver2 in the name
>> >> >> may be the current (renamed) server and perhaps that is why
>> >> >> your metadata cleanup attempt failed if you specified that server?
>> >> >>
>> >> >> Can we see the output from "list servers in site" from dsmgmt
>> >> >> connected to the (migrated) server you are attempting to cleanup
>> >> >> the replication connection on and also the output from:
>> >> >>
>> >> >> repadmin /showrepl /conn <server>:<port>
>> >> >>
>> >> >> run against that server.
>> >> >>
>> >> >> Thanks
>> >> >> Lee Flight
>> >> >>
>> >> >>
>> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> >> >> news:E0607A6F-BDF9-4FFE-8A6C-D13110247E83@microsoft.com...
>> >> >> > Ah, ok, makes perfect sense. And, that is what happened with my
>> >> >> > metadata
>> >> >> > cleanup.
>> >> >> >
>> >> >> > So, if manually remove the
>> >> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver1
>> >> >> > and
>> >> >> > CN=sites,CN=<Default-First-Site-Name>,CN=Servers,CN=oldserver2
>> >> >> > THAT
>> >> >> > will
>> >> >> > fix
>> >> >> > up the replication? I've been looking through repadmin
>> >> >> > documentation
>> >> >> > and
>> >> >> > there's noting about using that for ceasing replication between
>> >> >> > two
>> >> >> > instances.
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > Ted
>> >> >> >
>> >> >> > "Lee Flight" wrote:
>> >> >> >
>> >> >> >> Hi
>> >> >> >>
>> >> >> >> the reason that you are seeing the "DN of the object is the old
>> >> >> >> server
>> >> >> >> name" is that the server object in the your sites container
>> >> >> >> still
>> >> >> >> has the old server name embedded in it, so if you browse to the
>> >> >> >> configuration naming context
>> >> >> >> and then cn=sites
>> >> >> >> and then cn=<your site name or Default-First-Site-Name>
>> >> >> >> and then cn=Servers
>> >> >> >>
>> >> >> >> you will likely see a server object with the old server name
>> >> >> >> embedded
>> >> >> >> in it. This embedding is not a problem it's just a string, the
>> >> >> >> FSMO
>> >> >> >> roles
>> >> >> >> that you have
>> >> >> >> seized will be referencing the NTDS Settings object beneath the
>> >> >> >> server
>> >> >> >> object so it sounds like your FSMO roles have been seized
>> >> >> >> correctly.
>> >> >> >>
>> >> >> >> On the metadata cleanup the DsRemoveDsServer error may be due
>> >> >> >> to orphaned NTDS settings objects under the server objects you
>> >> >> >> are
>> >> >> >> attemtping to cleanup OR you may have the syntax wrong and be
>> >> >> >> attempting
>> >> >> >> to delete the server that you are currently connected to.
>> >> >> >>
>> >> >> >> If you are sure that your syntax is correct then
>> >> >> >> you might want to delete the server objects that are no longer
>> >> >> >> required
>> >> >> >> directly from the cn=Servers container to clean up your
>> >> >> >> replication
>> >> >> >> connections but even that is not "required".
>> >> >> >>
>> >> >> >> As the instance is in production I would recommend that if you
>> >> >> >> do wish to attempt ant further clean-up e.g. renaming the
>> >> >> >> current
>> >> >> >> server object or deleting obsolete servers directly that you do
>> >> >> >> that
>> >> >> >> in a test environment and of course always have a full backup.
>> >> >> >>
>> >> >> >> Lee Flight
>> >> >> >>
>> >> >> >>
>> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in
>> >> >> >> message
>> >> >> >> news:15F9AAA6-FD08-4557-80AC-7243E90AAD90@microsoft.com...
>> >> >> >> > Hi Lee,
>> >> >> >> >
>> >> >> >> > When I try to seize the schema and naming roles, I receive the
>> >> >> >> > gui
>> >> >> >> > prompt
>> >> >> >> > confirming I want to seize the roles from server
>> >> >> >> > localhost:389.
>> >> >> >> > The
>> >> >> >> > DN
>> >> >> >> > of
>> >> >> >> > the object is the old server name.
>> >> >> >> >
>> >> >> >> > I click yes and I receive the message that the server knows
>> >> >> >> > about
>> >> >> >> > 2
>> >> >> >> > roles,
>> >> >> >> > however, the DN of the server object in both instances remains
>> >> >> >> > the
>> >> >> >> > old
>> >> >> >> > server
>> >> >> >> > name.
>> >> >> >> >
>> >> >> >> > When trying to do the metadata cleanup, after selecting the
>> >> >> >> > Default-First-Site-Name, when I list the servers, the DN is of
>> >> >> >> > the
>> >> >> >> > old
>> >> >> >> > server
>> >> >> >> > name.
>> >> >> >> >
>> >> >> >> > After getting out and back in to dsmgt and doing a 'remove
>> >> >> >> > selected
>> >> >> >> > server
>> >> >> >> > "<full DN of the server>" on localhost:389
>> >> >> >> >
>> >> >> >> > I receieve the LDAP error: 0x5e(94 no result present in
>> >> >> >> > message.
>> >> >> >> >
>> >> >> >> > Unable to determine the domain hosted by the DC
>> >> >> >> >
>> >> >> >> > DsRemoveDsServer W error 0x2094(The DSA object cannot be
>> >> >> >> > deleted.)
>> >> >> >> >
>> >> >> >> > Thanks
>> >> >> >> >
>> >> >> >> > Ted
>> >> >> >> >
>> >> >> >> > "Lee Flight" wrote:
>> >> >> >> >
>> >> >> >> >> Hi
>> >> >> >> >>
>> >> >> >> >> seizing the roles and metadata cleanup should work in your
>> >> >> >> >> situation.
>> >> >> >> >> What problems are you seeing when you try?
>> >> >> >> >>
>> >> >> >> >> Lee Flight
>> >> >> >> >>
>> >> >> >> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in
>> >> >> >> >> message
>> >> >> >> >> news:39CA3390-ED9D-4F27-A64B-9AE0F2DECAD6@microsoft.com...
>> >> >> >> >> >
>> >> >> >> >> > Let me break this down further....
>> >> >> >> >> >
>> >> >> >> >> > A) when I do a DSDiag, I can see the instance is still
>> >> >> >> >> > trying
>> >> >> >> >> > to
>> >> >> >> >> > refer
>> >> >> >> >> > to
>> >> >> >> >> > the old server name. How do I change the running instance
>> >> >> >> >> > to
>> >> >> >> >> > stop
>> >> >> >> >> > referring
>> >> >> >> >> > to the old server name but change it to the new server
>> >> >> >> >> > name?
>> >> >> >> >> >
>> >> >> >> >> > B) Although I've suspended outbound/inboud replication, how
>> >> >> >> >> > do
>> >> >> >> >> > I
>> >> >> >> >> > completely
>> >> >> >> >> > remove all replicas (and cease replication altogether) so
>> >> >> >> >> > that
>> >> >> >> >> > I
>> >> >> >> >> > can
>> >> >> >> >> > seize
>> >> >> >> >> > the roles and make the current instance the only instance?
>> >> >> >> >> >
>> >> >> >> >> > I would assume using metadata cleanup and seizing the
>> >> >> >> >> > naming
>> >> >> >> >> > and
>> >> >> >> >> > schema
>> >> >> >> >> > roles should take care of this for ADAM? Is that true?
>> >> >> >> >> >
>> >> >> >> >> > Thank you
>> >> >> >> >> >
>> >> >> >> >> > Ted
>> >> >> >> >> >
>> >> >> >> >> > "Ted Wagner" wrote:
>> >> >> >> >> >
>> >> >> >> >> >> I'm currently involved in a project where we had two ADAM
>> >> >> >> >> >> instances
>> >> >> >> >> >> set
>> >> >> >> >> >> up...
>> >> >> >> >> >> one on two unique servers. One was a replica of the
>> >> >> >> >> >> other.
>> >> >> >> >> >> Our
>> >> >> >> >> >> new
>> >> >> >> >> >> application that will be using ADAM will be using AzMan
>> >> >> >> >> >> and
>> >> >> >> >> >> we
>> >> >> >> >> >> will
>> >> >> >> >> >> be
>> >> >> >> >> >> adding
>> >> >> >> >> >> internal domain users to AzMan roles.
>> >> >> >> >> >>
>> >> >> >> >> >> The server name and service user is now different than the
>> >> >> >> >> >> original.
>> >> >> >> >> >> I'm
>> >> >> >> >> >> using a service account in the domain that has been
>> >> >> >> >> >> granted
>> >> >> >> >> >> proper
>> >> >> >> >> >> rights,
>> >> >> >> >> >> local admin, local admins is in the adminstrators ADAM
>> >> >> >> >> >> role,
>> >> >> >> >> >> etc.
>> >> >> >> >> >>
>> >> >> >> >> >> The requirement was to leave the primary ADAM instance
>> >> >> >> >> >> running
>> >> >> >> >> >> in
>> >> >> >> >> >> production, disable replication, move the replica instance
>> >> >> >> >> >> internally
>> >> >> >> >> >> to
>> >> >> >> >> >> our
>> >> >> >> >> >> domain.
>> >> >> >> >> >>
>> >> >> >> >> >> I changed the service user using dsdbutil, corrected the
>> >> >> >> >> >> SCP
>> >> >> >> >> >> errors
>> >> >> >> >> >> with
>> >> >> >> >> >> ADSIEdit in the domain.
>> >> >> >> >> >>
>> >> >> >> >> >> The Cisco firewall blocks all communication, so
>> >> >> >> >> >> replication
>> >> >> >> >> >> had
>> >> >> >> >> >> to
>> >> >> >> >> >> be
>> >> >> >> >> >> suspended... which I did with repadmin
>> >> >> >> >> >>
>> >> >> >> >> >> I tried using metadata cleanup and seizing the naming and
>> >> >> >> >> >> schema
>> >> >> >> >> >> master
>> >> >> >> >> >> roles. It appears that the instance of ADAM is not
>> >> >> >> >> >> recognizing
>> >> >> >> >> >> the
>> >> >> >> >> >> new
Previous Topic:GP errors
Next Topic:See what is in a computer's printers folder? (Confirm deployment)
Goto Forum:
  


Current Time: Fri Oct 20 02:54:40 EDT 2017

Total time taken to generate the page: 0.06030 seconds
.:: Contact :: Home ::Sitemap::.

Powered by: FUDforum 3.0.0RC2.
Copyright ©2001-2009 FUDforum Bulletin Board Software