samba - Nov 2009 - Fwd: Vista laptop in Samba 3.3.4 domain suddenly trying to use roaming profiles?

Paul, Thank you very much for your information. I, too, had noticed that the
ProfilePath and CentralPath values could be altered to point to the proper
local path, and that technique at least fixed the immediate problem.
Unfortunately, further review of my setup has revealed a very frustrating
migration issue that I had not yet realized. The issue is very subtle and
very frustrating, but I believe is at the core of my problem. The problem
is, actually, multifaceted. Its personally frustrating because I thought I
had a good understanding of the steps I needed to take to make this
migration smooth. Not so. I really stumbled on this one. As I looked in the
ProfileList registry key, I noticed several SID entries, but it wasn't until
some very late-night thinking that I realized I had a problem - they were
SID for users from two different domains!! The first domain SID was that of
my 2.2.8a domain, which I *thought* I had migrated properly to my new 3.3.4
setup. I thought I had copied the secrets.tdb from the old domain to the new
one, but something went awry. Fetching the domain SID from the server
revealed the fact that the new SID differed from the previous SID. *That*
bit of research led me to still another problem... I built my new Samba
3.3.4 domain off a fresh install of Slackware 13.0. Slack includes Samba,
but I thought during the install I had told the setup *not* to include
Samba, because I knew had to download and install 3.3.4 in the hopes of
supporting Windows 7 clients in my domain. Unfortunately, I apparently did
*not* exclude Samba, because I discovered that the stock Samba install for
Slackware was very much present in /usr/bin, but the standard configure
script for Samba placed it in /usr/local/samba. I had copied my secrets.tdb
to the wrong location. I copied my passwd and smbpasswd files correctly (I
specified the location of the latter in smb.conf), so Samba could
*authenticate* my users, but they all had SID's relative to what ended up as
the *new* Samba domain on the new box - NOT my "migrated" domain. Add
to
that the fact that I did *not* read that I should maintain the hostname to
the new, migrated server until *after* I had finished the install, and you
have a tour-de-force of a screwed up install. This laptop that was giving me
trouble was earlier giving me troubles about "trust relationship"
having
failed, which I thought was due to a lack of synchronization between my PDC
and the laptop due to the laptop not having been used in about a week. I
ended up removing and readding that machine to the domain, and now all its
user SID's are based on the "new" domain. Now that I realize
what's
happened, in order to preserve the other five boxes on my domain, I may have
to rewrite the domain SID to that of the original (which should have
happened in the first place), and re-migrate the profiles on this one
laptop. Argh. Oh, well, I do this for self-education as much as anything, so
perhaps I've learned something in the process :(

-David

>
> Paul, Thank you very much for your information. I, too, had noticed that
> the ProfilePath and CentralPath values could be altered to point to the
> proper local path, and that technique at least fixed the immediate problem.
> Unfortunately, further review of my setup has revealed a very frustrating
> migration issue that I had not yet realized. The issue is very subtle and
> very frustrating, but I believe is at the core of my problem. The problem
> is, actually, multifaceted. Its personally frustrating because I thought I
> had a good understanding of the steps I needed to take to make this
> migration smooth. Not so. I really stumbled on this one. As I looked in the
> ProfileList registry key, I noticed several SID entries, but it wasn't
until
> some very late-night thinking that I realized I had a problem - they were
> SID for users from two different domains!! The first domain SID was that of
> my 2.2.8a domain, which I *thought* I had migrated properly to my new 3.3.4
> setup. I thought I had copied the secrets.tdb from the old domain to the
new
> one, but something went awry. Fetching the domain SID from the server
> revealed the fact that the new SID differed from the previous SID. *That*
> bit of research led me to still another problem... I built my new Samba
> 3.3.4 domain off a fresh install of Slackware 13.0. Slack includes Samba,
> but I thought during the install I had told the setup *not* to include
> Samba, because I knew had to download and install 3.3.4 in the hopes of
> supporting Windows 7 clients in my domain. Unfortunately, I apparently did
> *not* exclude Samba, because I discovered that the stock Samba install for
> Slackware was very much present in /usr/bin, but the standard configure
> script for Samba placed it in /usr/local/samba. I had copied my secrets.tdb
> to the wrong location. I copied my passwd and smbpasswd files correctly (I
> specified the location of the latter in smb.conf), so Samba could
> *authenticate* my users, but they all had SID's relative to what ended
up as
> the *new* Samba domain on the new box - NOT my "migrated" domain.
Add to
> that the fact that I did *not* read that I should maintain the hostname to
> the new, migrated server until *after* I had finished the install, and you
> have a tour-de-force of a screwed up install. This laptop that was giving
me
> trouble was earlier giving me troubles about "trust relationship"
having
> failed, which I thought was due to a lack of synchronization between my PDC
> and the laptop due to the laptop not having been used in about a week. I
> ended up removing and readding that machine to the domain, and now all its
> user SID's are based on the "new" domain. Now that I realize
what's
> happened, in order to preserve the other five boxes on my domain, I may
have
> to rewrite the domain SID to that of the original (which should have
> happened in the first place), and re-migrate the profiles on this one
> laptop. Argh. Oh, well, I do this for self-education as much as anything,
so
> perhaps I've learned something in the process :(
>
> -David
>
>