Profile migration upon change of SID doesn't work and causes problems with Vista.

  • Thread starter Thread starter Carl Farrington
  • Start date Start date
C

Carl Farrington

For a long time, many years, I have been manually migrating user's profiles
if/when their SID changes, for example an unknowledgable person might setup
the user as a local user and not join the computer to the domain, so I will
join the computer to the domain and migrate the user's existing profile
over, or when replacing a server where a new domain will be created and
everybody in the organisation gets new SIDs (although I accept that Jeff's
'swing' migration seems to be a better way of doing this with SBS), or when
moving a non-domain user from one computer to another.

To do this migration I update ProfileImagePath in the registry and point it
back at the original profile folder, I correct the NTFS permissions on that
folder, and I manually load that user's NTUSER.DAT into the registry and
give the new user full permissions including all child objects. I then
unload the registry and either reboot or logoff/on, and all is well with the
exception of the Protected Storage System (network and web/email passwords).
I have not figured out the PSS thing yet, and instead I use a PSS viewer to
dump all the passwords beforehand. I suspect PSS is encrypted against the
user's SID or something like that.

Anyway, this all works fine on NT/2000/XP apart from the above exception
which I can and have lived with.

It does *not* work on Vista though. The symptoms afterwards (from memory)
are:
Internet Explorer broken - Phishing filter doesn't work. Tools -> Internet
Options doesn't work, although Internet control-panel works via the
control-panel.
Windows Defender reports problems and doesn't start.
Network Connections are reported to be broken/unavailable or something (I
can't remember exactly).
Various other oddities and instabilities.

I found that when applying the registry permissions on the user's hive I was
told that some keys could not be updated, and I have not been able to get
around this. Perhaps this is the cause? I do not know which keys are
inaccessible, but I should imagine as usual that the Protected Storage
System Provider will only be accesible by SYSTEM, but this didn't matter in
XP as a new key was created under there upon logging on with the new SID.
My plan is to try running regedit as SYSTEM (via use of the task scheduler's
/interactive switch) and see if this enables me to override all registry
permissions, and then see if this makes any difference to the actual
problem. Re-writing all registry permissions isn't a good plan so I'd really
like to know exactly what is/was inaccessible.

Does anybody know what's going on? Is it really simple? Am I simply missing
some NTFS ACLs somewhere?
This Vista thing is very odd. It's so cumbersome and awkward to administer.
Folders that aren't really folders, folders that I can't copy to from the
network (I have to copy to the desktop first), and more.. No real "Run As"
option if UAC is turned off. Thankfully I send most of my customers to Dell
now for their machines, and they still give the option to buy with XP. I
would still appreciate some assistance with this profile prolem though since
it's inevitable that I will be dealing with Vista more frequently as time
goes on.

Thanks for your time,

Carl
 
<BIG CAVEAT>
Changing SIDs is unsupported. It is extremely likely that you will get
strange results when you do it since it has never been tested and was not
supposed to be done.
</BIG CAVEAT>

The reason you are running into the error is very likely because there are
portions of their registry hive that users themselves do not have full
control over.

It seems like a much better option would be to try to avoid the SID change
altogether. While there are tools that can let you do it, it is much better
to avoid it. Instead of doing that, see if you can't just migrate profiles
and documents. I have used Roaming Profiles for this. I just copy the user's
existing profile to some network share, give the user permissions to it, and
set the user account to use that profile.

It should never be necessary to replace domains when swapping DCs. Jeff's
swing method is neat, but really no different than what big IT has been doing
for years. What he did, which is genius, is figure out how to do it on SBS. I
did my first "swing" migration on non-SBS in 1996, from NT 3.51 to 4.0, long
before I had ever heard of the term "swing," at least in that context. If you
do that you won't have the SID problems. If you use roaming profiles and
redirected user folders, you can even wipe a client with virtually no effect
at all.
 
Jesper said:
It should never be necessary to replace domains when swapping DCs. Jeff's
swing method is neat, but really no different than what big IT has been
doing
for years. What he did, which is genius, is figure out how to do it on
SBS. I
did my first "swing" migration on non-SBS in 1996, from NT 3.51 to 4.0,
long
before I had ever heard of the term "swing," at least in that context. If
you
do that you won't have the SID problems. If you use roaming profiles and
redirected user folders, you can even wipe a client with virtually no
effect
at all.
---
Click to expand...
I've never had any problems doing it pre-Vista. I've not actually read the
proper swing stuff yet (haven't paid), so I don't even know what it is that
he does. I understand perfectly well how a server should be replaced in a
non-SBS environment - replicating AD & transferring roles etc, but I didn't
like the idea that the server's name would be different. I suppose that's
the point of 'swinging' - you replicate to a temporary DC first (a VM on
your laptop for example) and then swing it back to the new server which can
have the original server's name. I'll have to pay the $180 to find out how
to do it with SBS :)

Getting back to the SID & profile issue. The larger problem for me is going
to be moving users onto new Vista computers (e.g. laptops) in a non-domain
environment for example single individuals and peer-to-peer networks. I
really could do with finding out what parts of the registry can't be
accessed.

It looks like these guys have scripted the procedure, which could be handy,
but more importantly they seem to think their script works for vista too:
http://forensit.com/profwiz/FAQs.htm

Thanks for your advice Jesper, I will certainly try to avoid using a profile
with a foreign SID where possible.
 
have the original server's name. I'll have to pay the $180 to find out how
to do it with SBS :)
Click to expand...

Do it. Jeff's solution is elegant. :-)
Getting back to the SID & profile issue. The larger problem for me is going
to be moving users onto new Vista computers (e.g. laptops) in a non-domain
environment for example single individuals and peer-to-peer networks. I
really could do with finding out what parts of the registry can't be
accessed.
Click to expand...

You can of course scour the ACLs on the registry using subinacl. It can be
scripted to dump out all the ACLs and then you can analyze that. But there is
a much simpler option: use Windows Easy Transfer. (Start:Accessories:System
Tools). Make an easy transfer disk on the Vista machine, take it to the XP
box and create the backup, return to the Vista machine and apply the
settings. It's a much easier option and it is designed to solve the exact
problem you are trying to solve.
 
Jesper said:
Do it. Jeff's solution is elegant. :-)


You can of course scour the ACLs on the registry using subinacl. It can be
scripted to dump out all the ACLs and then you can analyze that. But there
is
a much simpler option: use Windows Easy Transfer.
(Start:Accessories:System
Tools). Make an easy transfer disk on the Vista machine, take it to the XP
box and create the backup, return to the Vista machine and apply the
settings. It's a much easier option and it is designed to solve the exact
problem you are trying to solve.
Click to expand...

It would be even better if Easy Transfer would let me point at a second hard
disk and transfer from there (I would use a USB2<->IDE cable), or perhaps
over the network via the c$ admin share. Then I'm not wasting time copying
the data to an intermediate media. I'll certainly have a look at it though.
Thanks again.
 
It would be even better if Easy Transfer would let me point at a second hard
disk and transfer from there (I would use a USB2<->IDE cable), or perhaps
over the network via the c$ admin share. Then I'm not wasting time copying
the data to an intermediate media. I'll certainly have a look at it though.
Click to expand...

You can use removable media. That's what I do.
 
Back
Top