How to re-join an NT domain without losing user profile data/setti

I've NEVER seen this answered completely and correctly. I hope it can be
here. It is an important topic for network administrators like myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the proper way to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then rejoin it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first using a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile List/[user's sid].
But, this doesn't seem correct. Especially since MS Outlook prompts for the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools from one
workstations, but had not much luck. Should I be using the netdom.exe tool
from the server (the NT version)? Is this tool still available now that the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on it for
me.

Much thanks! -- JS

A lot depends on what you mean by "replaced". If you promoted a BDC to PDC
then you're good and shouldn't have to do anything. However, it sounds as
if you created a new domain with the same name because something happened to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has exactly the
same name as another, they are still distinctly different. Each domain has
a domain SID that uniquely identifies it, and that SID is randomly generated
when the domain is created. That SID is also associated with the user
profiles for the domain accounts. So, when you join the workstations to the
new domain (and it IS a new domain even if the name is exactly the same as
it was), the system recognizes that it is a new domain and creates a new
profile directory for it since the profiles contain information derived from
the domain.

So, the "proper" way to do this is to either have a BDC that you can promote
or have a backup strategy that will let you recover. Creating a whole new
domain is not recovering, it is starting over from scratch and comes with
all the pain and work that entails. There IS a heavily manual process you
can try now that you're in this position (see below), but it is not from
painless or automatic.

I don't have any older domain clients around right now to confirm for sure,
but with XP, disjoining and rejoining the domain does not create new
profiles. I've even disjoined a computer from a (Windows 2000) domain,
changed its name, rejoined the same domain, and come right back to my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the new domain,
it does not migrate the user profile. There are a separate set of tools for
migrating user profiles from an NT4 domain to a Windows 2000 or 2003 domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out the Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334). One thing
you might try from there is to modify the steps in the EXTRACTING A USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small environment.
To try in your case, you would postpone step 5 until after step 6. After
copying the profile structure in step 6, you would rename the original
profile to something else, so that when you do step 5, the profile is
created with the correct profile path. I haven't ever tried it, but it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is no
System control panel on Windows XP. To get to the profile copy interface on
XP, right click on My Computer, select Properties, go to the Advanced tab
and click on the "Settings" button under User Profiles. Also, the article
doesn't say it straight out, but you shouldn't be logged into the account
for which you are copying the profile, even if it IS an Administrator on the
machine.

Hope this helps shed some light on why you're seeing what you're seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
I've NEVER seen this answered completely and correctly. I hope it can be
here. It is an important topic for network administrators like myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the proper way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then rejoin
it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first using a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook prompts for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools from
one
workstations, but had not much luck. Should I be using the netdom.exe tool
from the server (the NT version)? Is this tool still available now that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on it
for
me.

Much thanks! -- JS

Thanks for the comprehensive explanations. However, I still have some
questions and I want to clarify parts of my original post:

First, I did make a BDC and promote it. However, this didn't preserve the
trust relationships as I intended. However, I think this was because I setup
the new server as a PDC by mistake. Therefore, I had used the trick of
changing the registry key HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo from
03000000 to 02000000. Then I joined the domain with it as BDC and then
promoted it. It seemed to work fine (all user and computer accounts
tranferred, etc), except that as each WINXP PRO workstation logged in an
EVENT CODE 5513 was logged in the SYSTEM event log with the description:

The computer COMPUTERNAME tried to connect to the server DOMAIN_SERVER using
the trust relationship established by the DOMAIN_NAME domain. However, the
computer lost the correct security identifier (SID) when the domain was
reconfigured. Reestablish the trust relationship.

To recreate the trust relationship, I removed the PC from the domain and
re-joined the domain. However, when logging into the XP PRO workstation as
USERNAME, the user's local profile path (the settings for various
application, desktop settings and my document redirections, etc) had changed
from C:\Documents and Settings\USERNAME to C:\Documents and
Settings\USERNAME.DOMAIN. No matter what I tried, I was unable to get XP PRO
to user C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN.

Finally, I had to log in as the domain administrator (not local domain
administrator) and add the domain user DOMAIN\USERNAME to the directory
C:\Documents and Settings\Username (note that the ACL had a numeric entry
representing the SID that the very same domain user had once been assigned).
Then I had to change the registry entry HKLM/Software/MicroSoft/Windows
NT/Current Version/Profile List/[user's_sid]/ProfileImagePath to represent
the path C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN. Even after doing this, I mentioned that Outlook
still prompted for the email password. Probably having to do with the .PWL
files (if that is still where windows stores stuff like that -- haven't check
lately).

I have also had this happen in a D/R situation where hardware changed and
the D/R recovery was unable to recover the system volume and registry of the
PDC and therefore it had to be rebuilt. When trying to join each workstation
to the new PDC, they all had similar problems with the profile path. It just
occurs to me there must be an easier way to perform this recovery.

I'm not sure the guide To Windows NT 4.0 Profiles and Policies is
applicable, because my problem seems to be with the profile that is stored on
the XP PRO box, and its relationship to the sid in the user manager on the
domain (but I'll reread it to check).

And, I will check this guide you mentioned, because I haven't seen it befo
EXTRACTING A USER PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the guide.

I hope this clarifies my dilemma and can lead to further insights. Thanks
again for your post Matt.

_ JS


"Matt DuBois [MSFT]" wrote:

A lot depends on what you mean by "replaced". If you promoted a BDC to PDC
then you're good and shouldn't have to do anything. However, it sounds as
if you created a new domain with the same name because something happened to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has exactly the
same name as another, they are still distinctly different. Each domain has
a domain SID that uniquely identifies it, and that SID is randomly generated
when the domain is created. That SID is also associated with the user
profiles for the domain accounts. So, when you join the workstations to the
new domain (and it IS a new domain even if the name is exactly the same as
it was), the system recognizes that it is a new domain and creates a new
profile directory for it since the profiles contain information derived from
the domain.

So, the "proper" way to do this is to either have a BDC that you can promote
or have a backup strategy that will let you recover. Creating a whole new
domain is not recovering, it is starting over from scratch and comes with
all the pain and work that entails. There IS a heavily manual process you
can try now that you're in this position (see below), but it is not from
painless or automatic.

I don't have any older domain clients around right now to confirm for sure,
but with XP, disjoining and rejoining the domain does not create new
profiles. I've even disjoined a computer from a (Windows 2000) domain,
changed its name, rejoined the same domain, and come right back to my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the new domain,
it does not migrate the user profile. There are a separate set of tools for
migrating user profiles from an NT4 domain to a Windows 2000 or 2003 domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out the Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334). One thing
you might try from there is to modify the steps in the EXTRACTING A USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small environment.
To try in your case, you would postpone step 5 until after step 6. After
copying the profile structure in step 6, you would rename the original
profile to something else, so that when you do step 5, the profile is
created with the correct profile path. I haven't ever tried it, but it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is no
System control panel on Windows XP. To get to the profile copy interface on
XP, right click on My Computer, select Properties, go to the Advanced tab
and click on the "Settings" button under User Profiles. Also, the article
doesn't say it straight out, but you shouldn't be logged into the account
for which you are copying the profile, even if it IS an Administrator on the
machine.

Hope this helps shed some light on why you're seeing what you're seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
I've NEVER seen this answered completely and correctly. I hope it can be
here. It is an important topic for network administrators like myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the proper way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then rejoin
it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first using a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook prompts for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools from
one
workstations, but had not much luck. Should I be using the netdom.exe tool
from the server (the NT version)? Is this tool still available now that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on it
for
me.

Much thanks! -- JS

You are right, the way you installed did cause the trust relationships not
to be preserved. The Event Code 5513 you see tells you that the domain SID
changed. The trick you used is unsupported for a reason, and what you are
seeing is that reason. It may look like it works, but it is not the same as
doing it right from the start.

Your prior experience where you had to rebuild because you couldn't restore
your backup is also exactly the same thing. You created a new domain with
the same name, but the SID, of course, was different.

If you install the OS as a BDC of the old domain from the start, then the
domain SID will be preserved and you won't have this sort of trouble.

The steps you had to take are also expected. The SIDs of the users changed
also (remember that a full user SID is made up of a combination of the user
SID and the domain SID) when the domain SID changed. So, even though the
name of the user was the same, the SIDs were different, so the user did not
have access to the profile directory. Permissions aren't assigned by user
name, though they are shown that way because it is more human readable, they
are assigned by SID.

There are actually a bunch of reasons Outlook might prompt. My guess is
that it did so for a similar reason as the profile directories - mismatched
SIDs. If you are using a domain joined Exchange server, you may have some
trouble brewing. Like the workstations, that server has probably lost ITS
trust relationship too. Not to mention that the mailbox permissions are
probably set for the old accounts and not the new ones. You're likely to
have some trouble with that down the road. If you are not very familiar
with Exchange, you may either want to contact PSS and explain your setup and
make sure everything is OK, or get a consultant to check things out instead.
The last thing you want is for everything to blow up a little down the road,
just when you think all the fallout is over.

Go ahead and check the document out. It is relevant even with XP because on
an NT 4 domain, XP uses NT 4 style domain policies. The profile stuff has
also not changed that much, and its a pretty good description of profiles
and what's in them.

--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Thanks for the comprehensive explanations. However, I still have some
questions and I want to clarify parts of my original post:

First, I did make a BDC and promote it. However, this didn't preserve the
trust relationships as I intended. However, I think this was because I
setup
the new server as a PDC by mistake. Therefore, I had used the trick of
changing the registry key HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo from
03000000 to 02000000. Then I joined the domain with it as BDC and then
promoted it. It seemed to work fine (all user and computer accounts
tranferred, etc), except that as each WINXP PRO workstation logged in an
EVENT CODE 5513 was logged in the SYSTEM event log with the description:

The computer COMPUTERNAME tried to connect to the server DOMAIN_SERVER
using
the trust relationship established by the DOMAIN_NAME domain. However, the
computer lost the correct security identifier (SID) when the domain was
reconfigured. Reestablish the trust relationship.

To recreate the trust relationship, I removed the PC from the domain and
re-joined the domain. However, when logging into the XP PRO workstation as
USERNAME, the user's local profile path (the settings for various
application, desktop settings and my document redirections, etc) had
changed
from C:\Documents and Settings\USERNAME to C:\Documents and
Settings\USERNAME.DOMAIN. No matter what I tried, I was unable to get XP
PRO
to user C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN.

Finally, I had to log in as the domain administrator (not local domain
administrator) and add the domain user DOMAIN\USERNAME to the directory
C:\Documents and Settings\Username (note that the ACL had a numeric entry
representing the SID that the very same domain user had once been
assigned).
Then I had to change the registry entry HKLM/Software/MicroSoft/Windows
NT/Current Version/Profile List/[user's_sid]/ProfileImagePath to represent
the path C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN. Even after doing this, I mentioned that Outlook
still prompted for the email password. Probably having to do with the .PWL
files (if that is still where windows stores stuff like that -- haven't
check
lately).

I have also had this happen in a D/R situation where hardware changed and
the D/R recovery was unable to recover the system volume and registry of
the
PDC and therefore it had to be rebuilt. When trying to join each
workstation
to the new PDC, they all had similar problems with the profile path. It
just
occurs to me there must be an easier way to perform this recovery.

I'm not sure the guide To Windows NT 4.0 Profiles and Policies is
applicable, because my problem seems to be with the profile that is stored
on
the XP PRO box, and its relationship to the sid in the user manager on the
domain (but I'll reread it to check).

And, I will check this guide you mentioned, because I haven't seen it
befo
EXTRACTING A USER PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section
in part 3 of the guide.

I hope this clarifies my dilemma and can lead to further insights. Thanks
again for your post Matt.

_ JS


"Matt DuBois [MSFT]" wrote:

A lot depends on what you mean by "replaced". If you promoted a BDC to
PDC
then you're good and shouldn't have to do anything. However, it sounds
as
if you created a new domain with the same name because something happened
to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has exactly
the
same name as another, they are still distinctly different. Each domain
has
a domain SID that uniquely identifies it, and that SID is randomly
generated
when the domain is created. That SID is also associated with the user
profiles for the domain accounts. So, when you join the workstations to
the
new domain (and it IS a new domain even if the name is exactly the same
as
it was), the system recognizes that it is a new domain and creates a new
profile directory for it since the profiles contain information derived
from
the domain.

So, the "proper" way to do this is to either have a BDC that you can
promote
or have a backup strategy that will let you recover. Creating a whole
new
domain is not recovering, it is starting over from scratch and comes with
all the pain and work that entails. There IS a heavily manual process
you
can try now that you're in this position (see below), but it is not from
painless or automatic.

I don't have any older domain clients around right now to confirm for
sure,
but with XP, disjoining and rejoining the domain does not create new
profiles. I've even disjoined a computer from a (Windows 2000) domain,
changed its name, rejoined the same domain, and come right back to my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the new
domain,
it does not migrate the user profile. There are a separate set of tools
for
migrating user profiles from an NT4 domain to a Windows 2000 or 2003
domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out the
Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334). One
thing
you might try from there is to modify the steps in the EXTRACTING A USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the
guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small environment.
To try in your case, you would postpone step 5 until after step 6. After
copying the profile structure in step 6, you would rename the original
profile to something else, so that when you do step 5, the profile is
created with the correct profile path. I haven't ever tried it, but it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is no
System control panel on Windows XP. To get to the profile copy interface
on
XP, right click on My Computer, select Properties, go to the Advanced tab
and click on the "Settings" button under User Profiles. Also, the
article
doesn't say it straight out, but you shouldn't be logged into the account
for which you are copying the profile, even if it IS an Administrator on
the
machine.

Hope this helps shed some light on why you're seeing what you're seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
I've NEVER seen this answered completely and correctly. I hope it can
be
here. It is an important topic for network administrators like myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the proper
way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then
rejoin
it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first using
a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook prompts for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools
from
one
workstations, but had not much luck. Should I be using the netdom.exe
tool
from the server (the NT version)? Is this tool still available now that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on it
for
me.

Much thanks! -- JS

Matt,

Your explanation about promoting the BDC to PDC after the improper
installation is understandable. For our next installation, we'll be certain
to start the installation correctly as a BDC for that domain. If we do that
properly, can we add the BDC, synchronize the domain, promote the BDC to PDC
and then rename the new PDC so that it is has the same name as the PDC we are
replacing?

Am I correct that the process to rename the newly promoted PDC is to simply
change the computer name, then to delete the old record in the server manager
for the previous PDC and re-add the new PDC (that now will have the same name
as the old PDC) as a BDC, but it will automatically be added as a PDC? Is
there a reboot in the middle of this process--after changing the name of the
new PDC, but before deleting the old PDC record and re-adding the new record
in server manager?

Also, I understand sometimes there can still be unforseen problems with this
process. If it happens and I have to start from scratch (or in the case of a
complete D/R where the system cannot be recovered for whatever reason), is
there a way to use the getsid tool and another tool (forget the name) to
replace old SIDs with new SIDs on the nt machine so that I can match the SIDs
of the computer accounts, NT PDC, and user accounts to what they were before?

BTW, regarding Exchange Server, thankfully I am using an internally
administered UNIX SENDMAIL server instead.

Thanks for your help -- JS


"Matt DuBois [MSFT]" wrote:

You are right, the way you installed did cause the trust relationships not
to be preserved. The Event Code 5513 you see tells you that the domain SID
changed. The trick you used is unsupported for a reason, and what you are
seeing is that reason. It may look like it works, but it is not the same as
doing it right from the start.

Your prior experience where you had to rebuild because you couldn't restore
your backup is also exactly the same thing. You created a new domain with
the same name, but the SID, of course, was different.

If you install the OS as a BDC of the old domain from the start, then the
domain SID will be preserved and you won't have this sort of trouble.

The steps you had to take are also expected. The SIDs of the users changed
also (remember that a full user SID is made up of a combination of the user
SID and the domain SID) when the domain SID changed. So, even though the
name of the user was the same, the SIDs were different, so the user did not
have access to the profile directory. Permissions aren't assigned by user
name, though they are shown that way because it is more human readable, they
are assigned by SID.

There are actually a bunch of reasons Outlook might prompt. My guess is
that it did so for a similar reason as the profile directories - mismatched
SIDs. If you are using a domain joined Exchange server, you may have some
trouble brewing. Like the workstations, that server has probably lost ITS
trust relationship too. Not to mention that the mailbox permissions are
probably set for the old accounts and not the new ones. You're likely to
have some trouble with that down the road. If you are not very familiar
with Exchange, you may either want to contact PSS and explain your setup and
make sure everything is OK, or get a consultant to check things out instead.
The last thing you want is for everything to blow up a little down the road,
just when you think all the fallout is over.

Go ahead and check the document out. It is relevant even with XP because on
an NT 4 domain, XP uses NT 4 style domain policies. The profile stuff has
also not changed that much, and its a pretty good description of profiles
and what's in them.

--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Thanks for the comprehensive explanations. However, I still have some
questions and I want to clarify parts of my original post:

First, I did make a BDC and promote it. However, this didn't preserve the
trust relationships as I intended. However, I think this was because I
setup
the new server as a PDC by mistake. Therefore, I had used the trick of
changing the registry key HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo from
03000000 to 02000000. Then I joined the domain with it as BDC and then
promoted it. It seemed to work fine (all user and computer accounts
tranferred, etc), except that as each WINXP PRO workstation logged in an
EVENT CODE 5513 was logged in the SYSTEM event log with the description:

The computer COMPUTERNAME tried to connect to the server DOMAIN_SERVER
using
the trust relationship established by the DOMAIN_NAME domain. However, the
computer lost the correct security identifier (SID) when the domain was
reconfigured. Reestablish the trust relationship.

To recreate the trust relationship, I removed the PC from the domain and
re-joined the domain. However, when logging into the XP PRO workstation as
USERNAME, the user's local profile path (the settings for various
application, desktop settings and my document redirections, etc) had
changed
from C:\Documents and Settings\USERNAME to C:\Documents and
Settings\USERNAME.DOMAIN. No matter what I tried, I was unable to get XP
PRO
to user C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN.

Finally, I had to log in as the domain administrator (not local domain
administrator) and add the domain user DOMAIN\USERNAME to the directory
C:\Documents and Settings\Username (note that the ACL had a numeric entry
representing the SID that the very same domain user had once been
assigned).
Then I had to change the registry entry HKLM/Software/MicroSoft/Windows
NT/Current Version/Profile List/[user's_sid]/ProfileImagePath to represent
the path C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN. Even after doing this, I mentioned that Outlook
still prompted for the email password. Probably having to do with the .PWL
files (if that is still where windows stores stuff like that -- haven't
check
lately).

I have also had this happen in a D/R situation where hardware changed and
the D/R recovery was unable to recover the system volume and registry of
the
PDC and therefore it had to be rebuilt. When trying to join each
workstation
to the new PDC, they all had similar problems with the profile path. It
just
occurs to me there must be an easier way to perform this recovery.

I'm not sure the guide To Windows NT 4.0 Profiles and Policies is
applicable, because my problem seems to be with the profile that is stored
on
the XP PRO box, and its relationship to the sid in the user manager on the
domain (but I'll reread it to check).

And, I will check this guide you mentioned, because I haven't seen it
befo
EXTRACTING A USER PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section
in part 3 of the guide.

I hope this clarifies my dilemma and can lead to further insights. Thanks
again for your post Matt.

_ JS


"Matt DuBois [MSFT]" wrote:

A lot depends on what you mean by "replaced". If you promoted a BDC to
PDC
then you're good and shouldn't have to do anything. However, it sounds
as
if you created a new domain with the same name because something happened
to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has exactly
the
same name as another, they are still distinctly different. Each domain
has
a domain SID that uniquely identifies it, and that SID is randomly
generated
when the domain is created. That SID is also associated with the user
profiles for the domain accounts. So, when you join the workstations to
the
new domain (and it IS a new domain even if the name is exactly the same
as
it was), the system recognizes that it is a new domain and creates a new
profile directory for it since the profiles contain information derived
from
the domain.

So, the "proper" way to do this is to either have a BDC that you can
promote
or have a backup strategy that will let you recover. Creating a whole
new
domain is not recovering, it is starting over from scratch and comes with
all the pain and work that entails. There IS a heavily manual process
you
can try now that you're in this position (see below), but it is not from
painless or automatic.

I don't have any older domain clients around right now to confirm for
sure,
but with XP, disjoining and rejoining the domain does not create new
profiles. I've even disjoined a computer from a (Windows 2000) domain,
changed its name, rejoined the same domain, and come right back to my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the new
domain,
it does not migrate the user profile. There are a separate set of tools
for
migrating user profiles from an NT4 domain to a Windows 2000 or 2003
domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out the
Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334). One
thing
you might try from there is to modify the steps in the EXTRACTING A USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the
guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small environment.
To try in your case, you would postpone step 5 until after step 6. After
copying the profile structure in step 6, you would rename the original
profile to something else, so that when you do step 5, the profile is
created with the correct profile path. I haven't ever tried it, but it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is no
System control panel on Windows XP. To get to the profile copy interface
on
XP, right click on My Computer, select Properties, go to the Advanced tab
and click on the "Settings" button under User Profiles. Also, the
article
doesn't say it straight out, but you shouldn't be logged into the account
for which you are copying the profile, even if it IS an Administrator on
the
machine.

Hope this helps shed some light on why you're seeing what you're seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
I've NEVER seen this answered completely and correctly. I hope it can
be
here. It is an important topic for network administrators like myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the proper
way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then
rejoin
it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first using
a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook prompts for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools
from
one
workstations, but had not much luck. Should I be using the netdom.exe
tool
from the server (the NT version)? Is this tool still available now that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on it
for
me.

Much thanks! -- JS

Unfortunately, you can't specify the SIDs, which is one reason backups are
so critical, especially of domain controllers.

Your other question isn't quite clear, so I want to make sure I understand
what you're trying to accomplish. What I THINK you're after is this:

A) You want the name of the PDC to be the same as it was originally once all
the dust is settled, even though it is a different physical machine.
B) You want the former PDC to be a BDC with the same name as the original
BDC.

For clarity, Server01 will be the original PDC and Server02 will be the
original BDC.
(Steps assume Server01 is offline - hardware failure, etc).

1) Promote Server02 to PDC
2) Bring Server01 back online (if possible) and demote it (see
http://support.microsoft.com/default...b;en-us;167248)
3) Rename Server01 to a temporary name (follow
http://support.microsoft.com/default...b;en-us;150298 - remember
its a BDC now)
4) Rename Server02 to the name you want the PDC to have (using the same
rename article)
5) Rename Server01 to the name you want the BDC to have (using the same
rename article)

If Server01 will be rebuilt instead of just switched around, replace steps 2
and 3 with "Delete the computer account for Server01", and replace step 5
with "Rebuild Server01 with the desired name".

Is that what you were after?



--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Matt,

Your explanation about promoting the BDC to PDC after the improper
installation is understandable. For our next installation, we'll be
certain
to start the installation correctly as a BDC for that domain. If we do
that
properly, can we add the BDC, synchronize the domain, promote the BDC to
PDC
and then rename the new PDC so that it is has the same name as the PDC we
are
replacing?

Am I correct that the process to rename the newly promoted PDC is to
simply
change the computer name, then to delete the old record in the server
manager
for the previous PDC and re-add the new PDC (that now will have the same
name
as the old PDC) as a BDC, but it will automatically be added as a PDC? Is
there a reboot in the middle of this process--after changing the name of
the
new PDC, but before deleting the old PDC record and re-adding the new
record
in server manager?

Also, I understand sometimes there can still be unforseen problems with
this
process. If it happens and I have to start from scratch (or in the case of
a
complete D/R where the system cannot be recovered for whatever reason), is
there a way to use the getsid tool and another tool (forget the name) to
replace old SIDs with new SIDs on the nt machine so that I can match the
SIDs
of the computer accounts, NT PDC, and user accounts to what they were
before?

BTW, regarding Exchange Server, thankfully I am using an internally
administered UNIX SENDMAIL server instead.

Thanks for your help -- JS


"Matt DuBois [MSFT]" wrote:

You are right, the way you installed did cause the trust relationships
not
to be preserved. The Event Code 5513 you see tells you that the domain
SID
changed. The trick you used is unsupported for a reason, and what you
are
seeing is that reason. It may look like it works, but it is not the same
as
doing it right from the start.

Your prior experience where you had to rebuild because you couldn't
restore
your backup is also exactly the same thing. You created a new domain with
the same name, but the SID, of course, was different.

If you install the OS as a BDC of the old domain from the start, then the
domain SID will be preserved and you won't have this sort of trouble.

The steps you had to take are also expected. The SIDs of the users
changed
also (remember that a full user SID is made up of a combination of the
user
SID and the domain SID) when the domain SID changed. So, even though the
name of the user was the same, the SIDs were different, so the user did
not
have access to the profile directory. Permissions aren't assigned by
user
name, though they are shown that way because it is more human readable,
they
are assigned by SID.

There are actually a bunch of reasons Outlook might prompt. My guess is
that it did so for a similar reason as the profile directories -
mismatched
SIDs. If you are using a domain joined Exchange server, you may have
some
trouble brewing. Like the workstations, that server has probably lost
ITS
trust relationship too. Not to mention that the mailbox permissions are
probably set for the old accounts and not the new ones. You're likely to
have some trouble with that down the road. If you are not very familiar
with Exchange, you may either want to contact PSS and explain your setup
and
make sure everything is OK, or get a consultant to check things out
instead.
The last thing you want is for everything to blow up a little down the
road,
just when you think all the fallout is over.

Go ahead and check the document out. It is relevant even with XP because
on
an NT 4 domain, XP uses NT 4 style domain policies. The profile stuff
has
also not changed that much, and its a pretty good description of profiles
and what's in them.

--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Thanks for the comprehensive explanations. However, I still have some
questions and I want to clarify parts of my original post:

First, I did make a BDC and promote it. However, this didn't preserve
the
trust relationships as I intended. However, I think this was because I
setup
the new server as a PDC by mistake. Therefore, I had used the trick of
changing the registry key HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo
from
03000000 to 02000000. Then I joined the domain with it as BDC and then
promoted it. It seemed to work fine (all user and computer accounts
tranferred, etc), except that as each WINXP PRO workstation logged in
an
EVENT CODE 5513 was logged in the SYSTEM event log with the
description:

The computer COMPUTERNAME tried to connect to the server DOMAIN_SERVER
using
the trust relationship established by the DOMAIN_NAME domain. However,
the
computer lost the correct security identifier (SID) when the domain was
reconfigured. Reestablish the trust relationship.

To recreate the trust relationship, I removed the PC from the domain
and
re-joined the domain. However, when logging into the XP PRO workstation
as
USERNAME, the user's local profile path (the settings for various
application, desktop settings and my document redirections, etc) had
changed
from C:\Documents and Settings\USERNAME to C:\Documents and
Settings\USERNAME.DOMAIN. No matter what I tried, I was unable to get
XP
PRO
to user C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN.

Finally, I had to log in as the domain administrator (not local domain
administrator) and add the domain user DOMAIN\USERNAME to the directory
C:\Documents and Settings\Username (note that the ACL had a numeric
entry
representing the SID that the very same domain user had once been
assigned).
Then I had to change the registry entry HKLM/Software/MicroSoft/Windows
NT/Current Version/Profile List/[user's_sid]/ProfileImagePath to
represent
the path C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN. Even after doing this, I mentioned that
Outlook
still prompted for the email password. Probably having to do with the
.PWL
files (if that is still where windows stores stuff like that -- haven't
check
lately).

I have also had this happen in a D/R situation where hardware changed
and
the D/R recovery was unable to recover the system volume and registry
of
the
PDC and therefore it had to be rebuilt. When trying to join each
workstation
to the new PDC, they all had similar problems with the profile path. It
just
occurs to me there must be an easier way to perform this recovery.

I'm not sure the guide To Windows NT 4.0 Profiles and Policies is
applicable, because my problem seems to be with the profile that is
stored
on
the XP PRO box, and its relationship to the sid in the user manager on
the
domain (but I'll reread it to check).

And, I will check this guide you mentioned, because I haven't seen it
befo
EXTRACTING A USER PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE
section
in part 3 of the guide.

I hope this clarifies my dilemma and can lead to further insights.
Thanks
again for your post Matt.

_ JS


"Matt DuBois [MSFT]" wrote:

A lot depends on what you mean by "replaced". If you promoted a BDC
to
PDC
then you're good and shouldn't have to do anything. However, it
sounds
as
if you created a new domain with the same name because something
happened
to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has
exactly
the
same name as another, they are still distinctly different. Each
domain
has
a domain SID that uniquely identifies it, and that SID is randomly
generated
when the domain is created. That SID is also associated with the user
profiles for the domain accounts. So, when you join the workstations
to
the
new domain (and it IS a new domain even if the name is exactly the
same
as
it was), the system recognizes that it is a new domain and creates a
new
profile directory for it since the profiles contain information
derived
from
the domain.

So, the "proper" way to do this is to either have a BDC that you can
promote
or have a backup strategy that will let you recover. Creating a whole
new
domain is not recovering, it is starting over from scratch and comes
with
all the pain and work that entails. There IS a heavily manual process
you
can try now that you're in this position (see below), but it is not
from
painless or automatic.

I don't have any older domain clients around right now to confirm for
sure,
but with XP, disjoining and rejoining the domain does not create new
profiles. I've even disjoined a computer from a (Windows 2000)
domain,
changed its name, rejoined the same domain, and come right back to my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the new
domain,
it does not migrate the user profile. There are a separate set of
tools
for
migrating user profiles from an NT4 domain to a Windows 2000 or 2003
domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out the
Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334). One
thing
you might try from there is to modify the steps in the EXTRACTING A
USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the
guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small
environment.
To try in your case, you would postpone step 5 until after step 6.
After
copying the profile structure in step 6, you would rename the original
profile to something else, so that when you do step 5, the profile is
created with the correct profile path. I haven't ever tried it, but
it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is no
System control panel on Windows XP. To get to the profile copy
interface
on
XP, right click on My Computer, select Properties, go to the Advanced
tab
and click on the "Settings" button under User Profiles. Also, the
article
doesn't say it straight out, but you shouldn't be logged into the
account
for which you are copying the profile, even if it IS an Administrator
on
the
machine.

Hope this helps shed some light on why you're seeing what you're
seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no
rights.


"J_Schneider" wrote in message
...
I've NEVER seen this answered completely and correctly. I hope it
can
be
here. It is an important topic for network administrators like
myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the
proper
way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then
rejoin
it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first
using
a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile
List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook prompts
for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools
from
one
workstations, but had not much luck. Should I be using the
netdom.exe
tool
from the server (the NT version)? Is this tool still available now
that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on
it
for
me.

Much thanks! -- JS

Matt,

The problem I've had with backups of PDCs is when the config of the system
hardware and system volume changes. ie. Assume we have a PDC that has is a
much older server and has a 50 pin SCSI hard drive on an older Adaptec 2940
controller. Now the new drive is an ultra 160 (or u320) on a 29160
controller. Or worse, assume the system volume was a FT volume (software
raid-1) because it was setup by someone before we took control of the IT
department. Trying to use a backup to get NT going as it was before can be
most painful. That is the case we have dealt with on more than one occassion.
That is why I am searching for a way to swap SIDs and get things the way they
once were.

On the other question that was unclear, you did interpret it correctly,
except that the old PDC (SERVER01) will be taken offline in a planned
replacement. The BDC (SERVER02) has been built from scratch for the sole
purpose of replacing SERVER01.

Therefore, I assume the steps a

1) Bring the BDC (SERVER02) onto the working domain and synchronize with the
PDC (SERVER01).
2) Demote SERVER01 (following
http://support.microsoft.com/default...b;en-us;167248)
3) Rename Server01 to a temporary name (follow
http://support.microsoft.com/default...b;en-us;150298 - remember
it's a BDC now)
4) Rename Server02 to the name you want the PDC to have (using the same
rename article)
5) Rename Server01 to the name you want the BDC to have (using the same
rename article)

(Or should I skip step 2, 3 & 5 and just take SERVER01 off the network
instead?)

Thanks,

John


"Matt DuBois [MSFT]" wrote:

Unfortunately, you can't specify the SIDs, which is one reason backups are
so critical, especially of domain controllers.

Your other question isn't quite clear, so I want to make sure I understand
what you're trying to accomplish. What I THINK you're after is this:

A) You want the name of the PDC to be the same as it was originally once all
the dust is settled, even though it is a different physical machine.
B) You want the former PDC to be a BDC with the same name as the original
BDC.

For clarity, Server01 will be the original PDC and Server02 will be the
original BDC.
(Steps assume Server01 is offline - hardware failure, etc).

1) Promote Server02 to PDC
2) Bring Server01 back online (if possible) and demote it (see
http://support.microsoft.com/default...b;en-us;167248)
3) Rename Server01 to a temporary name (follow
http://support.microsoft.com/default...b;en-us;150298 - remember
its a BDC now)
4) Rename Server02 to the name you want the PDC to have (using the same
rename article)
5) Rename Server01 to the name you want the BDC to have (using the same
rename article)

If Server01 will be rebuilt instead of just switched around, replace steps 2
and 3 with "Delete the computer account for Server01", and replace step 5
with "Rebuild Server01 with the desired name".

Is that what you were after?



--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Matt,

Your explanation about promoting the BDC to PDC after the improper
installation is understandable. For our next installation, we'll be
certain
to start the installation correctly as a BDC for that domain. If we do
that
properly, can we add the BDC, synchronize the domain, promote the BDC to
PDC
and then rename the new PDC so that it is has the same name as the PDC we
are
replacing?

Am I correct that the process to rename the newly promoted PDC is to
simply
change the computer name, then to delete the old record in the server
manager
for the previous PDC and re-add the new PDC (that now will have the same
name
as the old PDC) as a BDC, but it will automatically be added as a PDC? Is
there a reboot in the middle of this process--after changing the name of
the
new PDC, but before deleting the old PDC record and re-adding the new
record
in server manager?

Also, I understand sometimes there can still be unforseen problems with
this
process. If it happens and I have to start from scratch (or in the case of
a
complete D/R where the system cannot be recovered for whatever reason), is
there a way to use the getsid tool and another tool (forget the name) to
replace old SIDs with new SIDs on the nt machine so that I can match the
SIDs
of the computer accounts, NT PDC, and user accounts to what they were
before?

BTW, regarding Exchange Server, thankfully I am using an internally
administered UNIX SENDMAIL server instead.

Thanks for your help -- JS


"Matt DuBois [MSFT]" wrote:

You are right, the way you installed did cause the trust relationships
not
to be preserved. The Event Code 5513 you see tells you that the domain
SID
changed. The trick you used is unsupported for a reason, and what you
are
seeing is that reason. It may look like it works, but it is not the same
as
doing it right from the start.

Your prior experience where you had to rebuild because you couldn't
restore
your backup is also exactly the same thing. You created a new domain with
the same name, but the SID, of course, was different.

If you install the OS as a BDC of the old domain from the start, then the
domain SID will be preserved and you won't have this sort of trouble.

The steps you had to take are also expected. The SIDs of the users
changed
also (remember that a full user SID is made up of a combination of the
user
SID and the domain SID) when the domain SID changed. So, even though the
name of the user was the same, the SIDs were different, so the user did
not
have access to the profile directory. Permissions aren't assigned by
user
name, though they are shown that way because it is more human readable,
they
are assigned by SID.

There are actually a bunch of reasons Outlook might prompt. My guess is
that it did so for a similar reason as the profile directories -
mismatched
SIDs. If you are using a domain joined Exchange server, you may have
some
trouble brewing. Like the workstations, that server has probably lost
ITS
trust relationship too. Not to mention that the mailbox permissions are
probably set for the old accounts and not the new ones. You're likely to
have some trouble with that down the road. If you are not very familiar
with Exchange, you may either want to contact PSS and explain your setup
and
make sure everything is OK, or get a consultant to check things out
instead.
The last thing you want is for everything to blow up a little down the
road,
just when you think all the fallout is over.

Go ahead and check the document out. It is relevant even with XP because
on
an NT 4 domain, XP uses NT 4 style domain policies. The profile stuff
has
also not changed that much, and its a pretty good description of profiles
and what's in them.

--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Thanks for the comprehensive explanations. However, I still have some
questions and I want to clarify parts of my original post:

First, I did make a BDC and promote it. However, this didn't preserve
the
trust relationships as I intended. However, I think this was because I
setup
the new server as a PDC by mistake. Therefore, I had used the trick of
changing the registry key HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo
from
03000000 to 02000000. Then I joined the domain with it as BDC and then
promoted it. It seemed to work fine (all user and computer accounts
tranferred, etc), except that as each WINXP PRO workstation logged in
an
EVENT CODE 5513 was logged in the SYSTEM event log with the
description:

The computer COMPUTERNAME tried to connect to the server DOMAIN_SERVER
using
the trust relationship established by the DOMAIN_NAME domain. However,
the
computer lost the correct security identifier (SID) when the domain was
reconfigured. Reestablish the trust relationship.

To recreate the trust relationship, I removed the PC from the domain
and
re-joined the domain. However, when logging into the XP PRO workstation
as
USERNAME, the user's local profile path (the settings for various
application, desktop settings and my document redirections, etc) had
changed
from C:\Documents and Settings\USERNAME to C:\Documents and
Settings\USERNAME.DOMAIN. No matter what I tried, I was unable to get
XP
PRO
to user C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN.

Finally, I had to log in as the domain administrator (not local domain
administrator) and add the domain user DOMAIN\USERNAME to the directory
C:\Documents and Settings\Username (note that the ACL had a numeric
entry
representing the SID that the very same domain user had once been
assigned).
Then I had to change the registry entry HKLM/Software/MicroSoft/Windows
NT/Current Version/Profile List/[user's_sid]/ProfileImagePath to
represent
the path C:\Documents and Settings\USERNAME instead of C:\Documents and
Settings\USERNAME.DOMAIN. Even after doing this, I mentioned that
Outlook
still prompted for the email password. Probably having to do with the
.PWL
files (if that is still where windows stores stuff like that -- haven't
check
lately).

I have also had this happen in a D/R situation where hardware changed
and
the D/R recovery was unable to recover the system volume and registry
of
the
PDC and therefore it had to be rebuilt. When trying to join each
workstation
to the new PDC, they all had similar problems with the profile path. It
just
occurs to me there must be an easier way to perform this recovery.

I'm not sure the guide To Windows NT 4.0 Profiles and Policies is
applicable, because my problem seems to be with the profile that is
stored
on
the XP PRO box, and its relationship to the sid in the user manager on
the
domain (but I'll reread it to check).

And, I will check this guide you mentioned, because I haven't seen it
befo
EXTRACTING A USER PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE
section
in part 3 of the guide.

I hope this clarifies my dilemma and can lead to further insights.
Thanks
again for your post Matt.

_ JS


"Matt DuBois [MSFT]" wrote:

A lot depends on what you mean by "replaced". If you promoted a BDC
to
PDC
then you're good and shouldn't have to do anything. However, it
sounds
as
if you created a new domain with the same name because something
happened
to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has
exactly
the
same name as another, they are still distinctly different. Each
domain
has
a domain SID that uniquely identifies it, and that SID is randomly
generated
when the domain is created. That SID is also associated with the user
profiles for the domain accounts. So, when you join the workstations
to
the
new domain (and it IS a new domain even if the name is exactly the
same
as
it was), the system recognizes that it is a new domain and creates a
new
profile directory for it since the profiles contain information
derived
from
the domain.

So, the "proper" way to do this is to either have a BDC that you can
promote
or have a backup strategy that will let you recover. Creating a whole
new
domain is not recovering, it is starting over from scratch and comes
with
all the pain and work that entails. There IS a heavily manual process
you
can try now that you're in this position (see below), but it is not
from
painless or automatic.

I don't have any older domain clients around right now to confirm for
sure,
but with XP, disjoining and rejoining the domain does not create new
profiles. I've even disjoined a computer from a (Windows 2000)
domain,
changed its name, rejoined the same domain, and come right back to my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the new
domain,
it does not migrate the user profile. There are a separate set of
tools
for
migrating user profiles from an NT4 domain to a Windows 2000 or 2003
domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out the
Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334). One
thing
you might try from there is to modify the steps in the EXTRACTING A
USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of the
guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small
environment.
To try in your case, you would postpone step 5 until after step 6.
After
copying the profile structure in step 6, you would rename the original
profile to something else, so that when you do step 5, the profile is
created with the correct profile path. I haven't ever tried it, but
it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is no
System control panel on Windows XP. To get to the profile copy
interface
on
XP, right click on My Computer, select Properties, go to the Advanced
tab
and click on the "Settings" button under User Profiles. Also, the
article
doesn't say it straight out, but you shouldn't be logged into the
account
for which you are copying the profile, even if it IS an Administrator
on
the
machine.

Hope this helps shed some light on why you're seeing what you're
seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no
rights.


"J_Schneider" wrote in message
...
I've NEVER seen this answered completely and correctly. I hope it
can
be
here. It is an important topic for network administrators like
myself:

I've recently replaced and NT4 PDC. The trust relationships with the
workstations were broken and have to be recreated. What is the
proper
way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then
rejoin
it
the user will have a new locally cached profile_path created called
username.domain (or username.domain.000 if the username was first
using
a
profile_path of username).

I've gotten around this somewhat by resetting security on the user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile
List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook prompts
for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support tools
from
one
workstations, but had not much luck. Should I be using the
netdom.exe
tool
from the server (the NT version)? Is this tool still available now
that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find a
definitive answer to. Thanks a ton to the genius who shed's light on
it
for
me.

Much thanks! -- JS

In the case where you're doing the replacement proactively and both servers
are online, then you won't need to explicitly demote SERVER01. The act of
promoting SERVER02 to PDC should automatically demote SERVER01 to BDC.
Then, you can proceed with the rename as described.

I can definitely feel your pain with the non-identical hardware. There IS a
workaround if you have some advanced warning.
http://support.microsoft.com/kb/130928 explains how you can restore a backup
onto other hardware. It IS unsupported, but if you can get the backup
temporarily onto another machine, it buys you time to do an install onto the
real replacement machine, do the synch and then promote the real replacement
and retire the temporary one. Even if you don't have warning to pre-load
the SCSI driver as described in the article, you can probably still get away
with it as long as the temporary machine is IDE only, since NT 4 should have
that driver regardless.

The other solution that some customers have done, is that they'll make a
file server or a server that is operating well under capacity and make it a
BDC. That way, there is no need to try and restore a backup of the domain
stuff. . .you just promote the BDC while you build a replacement PDC.
Granted this requires a lot more planning on NT 4 since you can't make any
machine a PDC or BDC after the OS has been installed, but it seems to work
well for the customers I know that have done it with Windows 2000 and 2003.

On a slightly different note . . . are you guys aware that NT 4 is going out
of support soon? If you haven't started planning a migration, you probably
want to start thinking about it. Once NT 4 is out of support, it will no
longer be possible to get even security patches for it. Also, the little
things like being able to turn any server into a DC on the fly without a
re-installation makes setting machines up MUCH easier. The issue you had
with accidentally installing the replacement as a PDC for a new domain would
probably have never happened with Windows 2000 or 2003 since the selection
UI is done better. Since making a domain controller is a seperate step
after the OS is installed, you don't accidentally choose the wrong option
when you are trying to get the OS onto the server in a hurry.

--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Matt,

The problem I've had with backups of PDCs is when the config of the system
hardware and system volume changes. ie. Assume we have a PDC that has is a
much older server and has a 50 pin SCSI hard drive on an older Adaptec
2940
controller. Now the new drive is an ultra 160 (or u320) on a 29160
controller. Or worse, assume the system volume was a FT volume (software
raid-1) because it was setup by someone before we took control of the IT
department. Trying to use a backup to get NT going as it was before can be
most painful. That is the case we have dealt with on more than one
occassion.
That is why I am searching for a way to swap SIDs and get things the way
they
once were.

On the other question that was unclear, you did interpret it correctly,
except that the old PDC (SERVER01) will be taken offline in a planned
replacement. The BDC (SERVER02) has been built from scratch for the sole
purpose of replacing SERVER01.

Therefore, I assume the steps a

1) Bring the BDC (SERVER02) onto the working domain and synchronize with
the
PDC (SERVER01).
2) Demote SERVER01 (following
http://support.microsoft.com/default...b;en-us;167248)
3) Rename Server01 to a temporary name (follow
http://support.microsoft.com/default...b;en-us;150298 - remember
it's a BDC now)
4) Rename Server02 to the name you want the PDC to have (using the same
rename article)
5) Rename Server01 to the name you want the BDC to have (using the same
rename article)

(Or should I skip step 2, 3 & 5 and just take SERVER01 off the network
instead?)

Thanks,

John


"Matt DuBois [MSFT]" wrote:

Unfortunately, you can't specify the SIDs, which is one reason backups
are
so critical, especially of domain controllers.

Your other question isn't quite clear, so I want to make sure I
understand
what you're trying to accomplish. What I THINK you're after is this:

A) You want the name of the PDC to be the same as it was originally once
all
the dust is settled, even though it is a different physical machine.
B) You want the former PDC to be a BDC with the same name as the original
BDC.

For clarity, Server01 will be the original PDC and Server02 will be the
original BDC.
(Steps assume Server01 is offline - hardware failure, etc).

1) Promote Server02 to PDC
2) Bring Server01 back online (if possible) and demote it (see
http://support.microsoft.com/default...b;en-us;167248)
3) Rename Server01 to a temporary name (follow
http://support.microsoft.com/default...b;en-us;150298 - remember
its a BDC now)
4) Rename Server02 to the name you want the PDC to have (using the same
rename article)
5) Rename Server01 to the name you want the BDC to have (using the same
rename article)

If Server01 will be rebuilt instead of just switched around, replace
steps 2
and 3 with "Delete the computer account for Server01", and replace step 5
with "Rebuild Server01 with the desired name".

Is that what you were after?



--
This posting is provided AS IS with no warranties, and confers no rights.


"J_Schneider" wrote in message
...
Matt,

Your explanation about promoting the BDC to PDC after the improper
installation is understandable. For our next installation, we'll be
certain
to start the installation correctly as a BDC for that domain. If we do
that
properly, can we add the BDC, synchronize the domain, promote the BDC
to
PDC
and then rename the new PDC so that it is has the same name as the PDC
we
are
replacing?

Am I correct that the process to rename the newly promoted PDC is to
simply
change the computer name, then to delete the old record in the server
manager
for the previous PDC and re-add the new PDC (that now will have the
same
name
as the old PDC) as a BDC, but it will automatically be added as a PDC?
Is
there a reboot in the middle of this process--after changing the name
of
the
new PDC, but before deleting the old PDC record and re-adding the new
record
in server manager?

Also, I understand sometimes there can still be unforseen problems with
this
process. If it happens and I have to start from scratch (or in the case
of
a
complete D/R where the system cannot be recovered for whatever reason),
is
there a way to use the getsid tool and another tool (forget the name)
to
replace old SIDs with new SIDs on the nt machine so that I can match
the
SIDs
of the computer accounts, NT PDC, and user accounts to what they were
before?

BTW, regarding Exchange Server, thankfully I am using an internally
administered UNIX SENDMAIL server instead.

Thanks for your help -- JS


"Matt DuBois [MSFT]" wrote:

You are right, the way you installed did cause the trust relationships
not
to be preserved. The Event Code 5513 you see tells you that the
domain
SID
changed. The trick you used is unsupported for a reason, and what you
are
seeing is that reason. It may look like it works, but it is not the
same
as
doing it right from the start.

Your prior experience where you had to rebuild because you couldn't
restore
your backup is also exactly the same thing. You created a new domain
with
the same name, but the SID, of course, was different.

If you install the OS as a BDC of the old domain from the start, then
the
domain SID will be preserved and you won't have this sort of trouble.

The steps you had to take are also expected. The SIDs of the users
changed
also (remember that a full user SID is made up of a combination of the
user
SID and the domain SID) when the domain SID changed. So, even though
the
name of the user was the same, the SIDs were different, so the user
did
not
have access to the profile directory. Permissions aren't assigned by
user
name, though they are shown that way because it is more human
readable,
they
are assigned by SID.

There are actually a bunch of reasons Outlook might prompt. My guess
is
that it did so for a similar reason as the profile directories -
mismatched
SIDs. If you are using a domain joined Exchange server, you may have
some
trouble brewing. Like the workstations, that server has probably lost
ITS
trust relationship too. Not to mention that the mailbox permissions
are
probably set for the old accounts and not the new ones. You're likely
to
have some trouble with that down the road. If you are not very
familiar
with Exchange, you may either want to contact PSS and explain your
setup
and
make sure everything is OK, or get a consultant to check things out
instead.
The last thing you want is for everything to blow up a little down the
road,
just when you think all the fallout is over.

Go ahead and check the document out. It is relevant even with XP
because
on
an NT 4 domain, XP uses NT 4 style domain policies. The profile stuff
has
also not changed that much, and its a pretty good description of
profiles
and what's in them.

--
This posting is provided AS IS with no warranties, and confers no
rights.


"J_Schneider" wrote in message
...
Thanks for the comprehensive explanations. However, I still have
some
questions and I want to clarify parts of my original post:

First, I did make a BDC and promote it. However, this didn't
preserve
the
trust relationships as I intended. However, I think this was because
I
setup
the new server as a PDC by mistake. Therefore, I had used the trick
of
changing the registry key
HKEY_LOCAL_MACHINE\Security\Policy\PolSrvRo
from
03000000 to 02000000. Then I joined the domain with it as BDC and
then
promoted it. It seemed to work fine (all user and computer accounts
tranferred, etc), except that as each WINXP PRO workstation logged
in
an
EVENT CODE 5513 was logged in the SYSTEM event log with the
description:

The computer COMPUTERNAME tried to connect to the server
DOMAIN_SERVER
using
the trust relationship established by the DOMAIN_NAME domain.
However,
the
computer lost the correct security identifier (SID) when the domain
was
reconfigured. Reestablish the trust relationship.

To recreate the trust relationship, I removed the PC from the domain
and
re-joined the domain. However, when logging into the XP PRO
workstation
as
USERNAME, the user's local profile path (the settings for various
application, desktop settings and my document redirections, etc) had
changed
from C:\Documents and Settings\USERNAME to C:\Documents and
Settings\USERNAME.DOMAIN. No matter what I tried, I was unable to
get
XP
PRO
to user C:\Documents and Settings\USERNAME instead of C:\Documents
and
Settings\USERNAME.DOMAIN.

Finally, I had to log in as the domain administrator (not local
domain
administrator) and add the domain user DOMAIN\USERNAME to the
directory
C:\Documents and Settings\Username (note that the ACL had a numeric
entry
representing the SID that the very same domain user had once been
assigned).
Then I had to change the registry entry
HKLM/Software/MicroSoft/Windows
NT/Current Version/Profile List/[user's_sid]/ProfileImagePath to
represent
the path C:\Documents and Settings\USERNAME instead of C:\Documents
and
Settings\USERNAME.DOMAIN. Even after doing this, I mentioned that
Outlook
still prompted for the email password. Probably having to do with
the
.PWL
files (if that is still where windows stores stuff like that --
haven't
check
lately).

I have also had this happen in a D/R situation where hardware
changed
and
the D/R recovery was unable to recover the system volume and
registry
of
the
PDC and therefore it had to be rebuilt. When trying to join each
workstation
to the new PDC, they all had similar problems with the profile path.
It
just
occurs to me there must be an easier way to perform this recovery.

I'm not sure the guide To Windows NT 4.0 Profiles and Policies is
applicable, because my problem seems to be with the profile that is
stored
on
the XP PRO box, and its relationship to the sid in the user manager
on
the
domain (but I'll reread it to check).

And, I will check this guide you mentioned, because I haven't seen
it
befo
EXTRACTING A USER PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE
section
in part 3 of the guide.

I hope this clarifies my dilemma and can lead to further insights.
Thanks
again for your post Matt.

_ JS


"Matt DuBois [MSFT]" wrote:

A lot depends on what you mean by "replaced". If you promoted a
BDC
to
PDC
then you're good and shouldn't have to do anything. However, it
sounds
as
if you created a new domain with the same name because something
happened
to
the old PDC, and you couldn't restore a backup for whatever reason.

The important thing to know here is that even if one domain has
exactly
the
same name as another, they are still distinctly different. Each
domain
has
a domain SID that uniquely identifies it, and that SID is randomly
generated
when the domain is created. That SID is also associated with the
user
profiles for the domain accounts. So, when you join the
workstations
to
the
new domain (and it IS a new domain even if the name is exactly the
same
as
it was), the system recognizes that it is a new domain and creates
a
new
profile directory for it since the profiles contain information
derived
from
the domain.

So, the "proper" way to do this is to either have a BDC that you
can
promote
or have a backup strategy that will let you recover. Creating a
whole
new
domain is not recovering, it is starting over from scratch and
comes
with
all the pain and work that entails. There IS a heavily manual
process
you
can try now that you're in this position (see below), but it is not
from
painless or automatic.

I don't have any older domain clients around right now to confirm
for
sure,
but with XP, disjoining and rejoining the domain does not create
new
profiles. I've even disjoined a computer from a (Windows 2000)
domain,
changed its name, rejoined the same domain, and come right back to
my
profile when I logged back into my domain account afterwards.

The netdom command you mention only migrates the computer to the
new
domain,
it does not migrate the user profile. There are a separate set of
tools
for
migrating user profiles from an NT4 domain to a Windows 2000 or
2003
domain,
but those don't apply here since the "new" domain is still NT4.

If you want to learn more about NT 4.0 profiles, you can check out
the
Guide
To Windows NT 4.0 Profiles and Policies
(http://support.microsoft.com/default...B;EN-US;161334).
One
thing
you might try from there is to modify the steps in the EXTRACTING A
USER
PROFILE FOR USE ON ANOTHER DOMAIN OR MACHINE section in part 3 of
the
guide.
That is a tremendously manual process and does not scale to lots of
machines - but might be workable for you if you have a small
environment.
To try in your case, you would postpone step 5 until after step 6.
After
copying the profile structure in step 6, you would rename the
original
profile to something else, so that when you do step 5, the profile
is
created with the correct profile path. I haven't ever tried it,
but
it
looks as if it should work for you.

Since you mentioned Windows XP in your post, you'll notice there is
no
System control panel on Windows XP. To get to the profile copy
interface
on
XP, right click on My Computer, select Properties, go to the
Advanced
tab
and click on the "Settings" button under User Profiles. Also, the
article
doesn't say it straight out, but you shouldn't be logged into the
account
for which you are copying the profile, even if it IS an
Administrator
on
the
machine.

Hope this helps shed some light on why you're seeing what you're
seeing.

-Matt
--
This posting is provided AS IS with no warranties, and confers no
rights.


"J_Schneider" wrote in
message
...
I've NEVER seen this answered completely and correctly. I hope it
can
be
here. It is an important topic for network administrators like
myself:

I've recently replaced and NT4 PDC. The trust relationships with
the
workstations were broken and have to be recreated. What is the
proper
way
to
do this so that the user's profile and profile_path are retained?

From my experience, if you remove the PC from the domain and then
rejoin
it
the user will have a new locally cached profile_path created
called
username.domain (or username.domain.000 if the username was first
using
a
profile_path of username).

I've gotten around this somewhat by resetting security on the
user's
previous profile path and then editing the registry key under
HKLM/Software/MicroSoft/Windows NT/Current Version/Profile
List/[user's
sid].
But, this doesn't seem correct. Especially since MS Outlook
prompts
for
the
user's email account password the next time it is launched.

I've also played with the NETDOM.exe tool from the XP support
tools
from
one
workstations, but had not much luck. Should I be using the
netdom.exe
tool
from the server (the NT version)? Is this tool still available
now
that
the
NT Resource Kit has been discontinued?

Help! This is a very troublesome issue that I cannot seem to find
a
definitive answer to. Thanks a ton to the genius who shed's light
on
it
for
me.

Much thanks! -- JS