Keep data, new OS&Apps: BUT how-to honor copied-in user profiles?
MBParker
fresh computer), or the computer is lost or destroyed, so we want or
have to start them fresh. However of course we want to keep our data
(as user profiles). But, for the terribly common individual computer
(not on a domain), how to get Windows to honor/register user profiles
(copied in from, say, our backup copy, or off our prior computer)?
Short of restoring everything (which then restores the old/corrupted
OS & apps), all of the best hacks I've seen loose all users'
passwords, plus loose every user's internal ID (SID) stating who can
access what.
In more detail, here is a common computer problem (which eventually
happens to every computer owner every year or two):
* You have a common self-administered personal computer (which is NOT
on say a Windows domain with roaming user profiles, nor featuring high-
paid IT staff to help you),
* And either:
- your OS and/or apps become irreparably corrupt (happens about
every year of use of Microsoft Windows XP),
- or, due to theft, damage, or age, you just want to move to a new
computer which already has an OS & apps compatible with your data
(plus custom drivers customized to the machine), all of which is
working (likely even factory-recommended) and you don't want to mess
with
* How do you easily restore JUST YOUR DATA from any backup program
(which appropriately saves user internal user IDs (SIDs and NTFS
ACLs))?
* ESPECIALLY if you have a few users on the computer, which may have
some folders carefully set up for private sharing? Or have private
data on other secure (NTFS) drives? Or simply don't want their
passwords reset?
I have posted this problem before (as back in 2004: "EMC Insignia
Forum OS slowly corrupted (or PC transplant) how restore only users &
data (incl. logins & reg settings)" ( http://forums.dantz.com/
ubbthreads/showflat.php?
Cat=0&Board=multiserver&Number=47611&Searchpage=1&Main=47611&Words=&topic=1&Search=true#Post47611 )
I've seen a few hacks to try to solve the this (at least the fresh
Apps/OS -- see the end of this post) but they all use the messy,
tedious, incomplete, and risky solution of creating (often manually)
fresh new accounts on the new OS (one for each incoming user) then
trying to patch each of these logins to work (hopefully) with the old
data, and patching all of the old data to work with the new login (and
usually forgetting any shared private data which needs double- or more
patching as well). As could be inferred, if having to issue new
passwords for everyone weren't bad enough, the chief problem is that a
new account creates a whole new user ID # (SID), which then requires
you to replace replace (for every user) the thousands of uses of the
old ID with the new one so the user doesn't loose access to anything
(a job which is rarely done right). While, yes, you can USUALLY
assume everything under a user's profile is only & fully accessible by
that person (if they haven't customized the security, such as turning
off write access to things they don't want to accidentally write on
again), this doesn't begin to cover if users have set up privately
shared folders (who can access must be manually restored) plus totally
misses backups which have recorded SIDs (who owns the files); besides
the fact that a new SID for each user for no good reason is just plain
ugly.
Indeed, if Microsoft expects us to do create new user IDs, maybe while
we're at it, whenever Windows becomes corrupt, we should also give
each user a new Social Security number. Hey, that would be fine -
"all" we have to do is do a global-search-and-replace on all its uses,
then the new social security number should work just like the old?
Right? No, terrible idea!
For proper recordkeeping & security settings not getting trashed for
no reason:
* IF THE SAME PERSON, MAKE THE SAME USER ID! One user should have
one permanent user id -- Make reasonable efforts not trash it, please!
* ELSE KEEP WITH THE USER A RECORD OF PRIOR IDs or other IDs for that
user so all past uses don't need to be patched (In the Microsoft
world, use "SID History" on individual workstations, too))
So naturally the clean & simple solution? On the clean/new OS & apps,
just
(1) restore the key user data (and including its file/ACL securities)
back into the new OS, including full user profiles in their normal
location, (can be done easily with say
- built-in xcopy (as: xcopy /E/V/H/R/X/I/D /F /L Q:\Documents and
Settings" "C:\Documents and Settings")
- builtin ntbackup using the options to restore just the user data
(as above) and with its NTFS permissions and ownership
- or using Dantz Retrospect (since it correctly does incremental
backups with snapshots and single-instance file-storage) similarly
configured
- or your favorite backup correctly restoring just the data with its
ACL securities
(2) then **** (somehow) tell the OS to recognize/honor/
register/"import" the copied-in user (profiles) as its own (I put
"import" in quotes because the user profiles are already there & ready
to use, the OS simply just has to acknowledge it.)
The problem is how to do #2:
(A) Possibly on a Macintosh, it would "just happen" as it should.
Whenever the login panel was about to be displayed, the OS would be
smart enough to first check its user profiles folder ("Documents and
Settings" on WinXP) for any profiles which had been added and register
them. Sadly, this doesn't happen on latest Windows XP (sp2).
(B) Perhaps in Windows it could work almost the same way way it now
honors roaming profiles & logins, but instead of looking to a domain
server for the user data &, it might be smart enough to check it's own
back yard (its own user profile folder ("Documents and Settings")
where they are supposed to be).
(C) Most all all the data for Windows to do this already in the
user's profile (namely the registry at <ProfileFolder>\NTUser.Dat).
In here I've found the original SID & username. To restore passwords
they must be extracted from operating-system wide file (which could
also be backed up), although this is tricky to get to. Contact me and
I'll tell you the exact locations. Data might also be stored in
Active Directory (LDAP) but I tend to think not if the computer isn't
on a domain.
(D) Setting this data on the incoming operating system would simply
involve, for each user, poking in few registry entries into
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\ProfileList\<SID>\ (as ProfileImagePath) plus maybe 1 or two
locations I've run across. Also copying over the hashed password
(which might require a special OS call since this is in protected
storage). Or, if say it's impossible for a 3rd party programmer to
carry over the passwords, a new user account can be created for each
user but maybe then the prior SID could be added to its SID History
list (see LDAP property sIDHistory) so the user would still have
access to all its prior resources without having update any of their
(possibly never ending) SIDs (that is if sIDHistory is available for
computers not in a domain). Contact me for more leads here.
(D) All in all, what is needed is a simple utility (as Windows
Script) to do this:
(1) When directed (or automatically) locate new user profiles copied
to the user profile folder ("Documents and Settings")
(2) Extract from each new profile the username, password, and user
ID # (SID) of the user, prompting for this info when unclear.
(3) register all this info into the OS, so the next time the OS
presents a login panel or looks up users, these new ones will be
available.
It seems Microsoft should have built this in (see A & B above).
Indeed it would be trivial for Microsoft to code: in fact, who ever
coded Microsoft's fre ADMT (Active Directory Migration Tool, which
only runs on Windows Server) could probably code this "Individual
Workstation Migration Tool" (IWMT) in about 1 hour flat. And in the
meantime, I would love it if some enterprising 3-rd party programmer
would whip up a free or inexpensive (under $25) utility.
Does such a utility exist? If not, can some Windows programmer
(familiar with OS & profile layout & registration) please write this?
Thanks, -Mike B. Parker
► MIT CS Grad, Army Medical Computing Officer, IT Consultant, and
Social & Software Architect
► Now Designing http://ww.CommuniDB.com ―“Your Community Database”™
(Web 2.0)
► Resumé at http://www.Cytex.com
=============================
PRIOR HACKS TO SOLVE THIS all involve creating a new user account
(thus new SID and password) for each user, which as well as being
often manual (per user for the administrator) also annoy the user &
administrator (issing new passwords) plus (most seriously) mess up any
shared private storage (with hand-crafted NTFS ACLs).
Here are all I've found:
(1) "How to Reinstall Windows Without Losing Your Data" ( http://
pcworld.about.com/magazine/2109p156id111652.htm ): creates a fresh new
user for each user, then copies over all profile data (via "xcopy c:
\oldstuff\*.* "c:\documents and settings" /s /h /r /c". The xcopy is
clever on two accounts. While new users are still created (new SID &
password - bad), and must be created individually (semi-bad):
(a) The data copy can be done in bulk (a minor savings)
(b) Because the profile folder already exists for each user, and ACL
is NOT copied, the ACL defaults to that of the destination user
(2) "How to copy data from a corrupted user profile to a new
profile" (http://support.microsoft.com/kb/811151 aka
http://support.microsoft.com/default.aspx?scid=kb;en-us;811151) :
create a new user then copy over its profile data except NTUser.
{dat{,|.log},ini} (the registry - don't copy to rid the corruption))
(3) "Wes' Puzzling Blog Moving XP User Profile" ( http://
weblogs.asp.net/whaggard/archive/2005/02/09/370189.aspx ), saying it's
quoting "Move User Profiles" (http://www.windowsitpro.com/Windows/
Article/ArticleID/39192/39192.html), creates a new user (step 3) then
patch it to point to the existing profile data (step 4), add file
permissions (assuming all Full) so new user/SID can access old data
(step 5), plus internal Registry permission on the user registry
NTUser.dat (step 6 & 7 - the above methods skip this step, perhaps
because there the new user becomes the new owner and the registry is
smart enough to default that the file owner has full access).
You could further fix these hacks (for the shared private storage) by
carefully doing SubInACL (see http://www.google.com/search?q=SubInACL
and perhaps my post
http://groups.google.com/group/microsoft.public.win2000.file_system/browse_thread/thread/3192d23a02fced80/13c76e06dce389e0?lnk=st&q=&rnum=23#13c76e06dce389e0
): use SubInACL to substitute out the old SIDs (if you've been careful
to save them) with the new SIDs (assuming you can find all of them (as
all the hard drives are online, and backup data restored), or remember
to do so as it later becomes online), but obviously this is quite
messy. Very simply, just don't create a new SID! (or add the prior
SID to the user's SID History).