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
:
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.
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
before:
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
:
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.aspx?scid=KB;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.
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