[Samba] Re: Migrating W2K Workstation to Samba Domain

[Jonathan Johnson]

I'm sorry, I can't help you with the issue of forcing Samba to use local
profiles. I should be able to help you, but at the moment I'm rusty on
that and I have a headache. But what I CAN help you with, once you get
over the issue of roaming vs. local profiles, is how to make sure the
users get their old profiles.

In this example, let us consider the user account fred.

The issue is that when you move the workstation to the new Samba domain,
Windows will attempt to create a new profile for the user fred, because
the user's SID will have changed (unless you have used 'net rpc vampire'
to extract the SIDs from the AD domain). Windows doesn't know you by
your name (fred), it knows you by your SID (big long ugly string of
characters), just like the bank does. So fred logs in to the Samba
domain, and all his settings, desktop, documents, etc. are GONE. What is
the poor, embattled administrator to do?

The answer lies in the registry, a few keys that associate a SID with a
user profile directory. Here's how to fix it.

After joining the workstation to the new domain, login as fred. A new
profile folder will be created, something like \Documents and
Settings\fred.newdomain (note that Fred's old profile was something like
\Documents and Settings\fred). Hint: you can determine the profile
folder by right-clicking the Start button and clicking Explore (not
Explore All). Now log out.

Log in to the workstation with an account that has local administrative
rights. It helps if this account also has domain admin rights, but it
absolutely must have local admin rights.

Find Fred's original profile folder, and apply permissions to it such
that the user fred in the new domain has full rights to it. (You should
see existing permissions of OLDDOMAIN\fred has full rights. You need to
add NEWDOMAIN\fred.) Make sure you apply these rights to all child
objects. Do the same for any other folders on this workstation that fred
might've been given specific rights to. (You can skip this step if the
filesystem is FAT32.)

Now open the registry editor (regedt32 on Windows 2000 or earlier;
regedit ONLY in XP.). Under the HKEY_USERS hive, load the hive
\Documents and Settings\fred\ntuser.dat. Note that this is fred's
original profile registry hive. Similarly to how you just assigned
rights to the profile folder, assign the rights to fred's registry hive.
AFTER ASSIGNING RIGHTS, YOU MUST UNLOAD THE HIVE OR RESTART THE
WORKSTATION or else Fred won't be able to log on.

Go to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList. Under this key, you will see several keys
named for the user SIDs for profiles on this machine. Locate the key
corresponding to fred's SID in the NEW domain. Change the value for
ProfileImagePath to reflect the path to fred's original profile*.*

Close the registry editor. Assign any other rights, such as local
administrator, to fred's new domain account. REBOOT THE WORKSTATION.

Log in as fred, to the new domain. You should get fred's original
desktop and have access to his documents.

WARNING: changes made in the registry editor are immediate. There is no
undo. Use caution.

~Jon Johnson
Sutinen Consulting, Inc.
www.sutinen.com
(360) 270-9317 cell



Michael Urban wrote:

>My message dated: Mon, 12 Dec 2005 10:16:14 EST
>  
>
>>I am replacing a W2K AD server with a Samba server.  The server has
>>a single W2K Workstation client, in a public area and used by a dozen
>>or so different users.  When I join the workstation to the Samba domain,
>>it complains that it cannot load a roaming profile (in the W2K AD domain,
>>it used local profiles), and it does not create a new local profile,
>>instead using a temporary profile.
>>
>>Obviously a permission problem somewhere.  What is the exact problem,
>>and what is the solution?
>>    
>>
>
>
>I am still at sea on this.  To clarify things a bit more, users of
>this workstation (under the W2K server) have local profiles, not
>floating profiles.  I would like to let them continue to have local
>profiles, even if it proves impossible to let them use their old
>ones due to permission problems.  However, even removing their
>directories from "C:\Documents and Settings" does not help - Windows
>does not create a new one for them (as all the documentation I have
>read led me to believe it would).o
>
>logon path=
>logon home=
>
>does not seem to affect this situation.  It still seems to try
>to get a floating profile, fails, and then makes a local profile
>in TEMP.
>
>Hasn't anyone performed this sort of migration before?  What
>other information can I provide (or try to glean from log files)
>to get this sorted out?
>
>  
>