Upgrading PDC

[Dave.Stevenson at durham.ac.uk]

CAUTION

I can relate to this. Same thing, had a 1 year old Samba PDC operating then tried
upgrade. Profiles will NOT work with new PDC. Seems something to do with 
SID's generated, fraid I dont know enough to relate details but suffice to say
that it is necessary to remove all roaming profile registry settings
(NTUSER.DAT) and generate new ones to avoid the "unknown user" and
registry setting permission denied business.

Caused mucho raised blood pressure here, compounded by the fact that many users
also had locally (cached) profiles.

I developed a solution using registry files to store user's settings.A web based
form  allows users to set up simplified preferences for common programs from
a series of template registry (and INI ) files all bound together with a couple
of perl scripts on an intranet server.

Then I deleted all users NTUSER.DAT files from their profiles (as they logged off)
When they logged on again they were presented with a form to setup preferences.
A UNIX perl script generates a .reg file and a number of INI/JS files in a public
directory. A second script is invoked on the local workstation (by button press)
that runs as the user to install the reg settings etc.

It's dirty but it works. Took almost two/three weeks for all users to filter through 
the reset process.

An alternative that would dump existing registry settings, INI and JS files would be trivial
to produce and would offer a safety net for those users whose profiles keep reverting
to default User or Default User(network) due to various network, MS, etc quirks.

Happy to share experiences and scripts if you want em 

There must be an easier way ( changing SID?? ) I know it's possible to change workstation
SID's (NewSID program) but dont know enough to say If same is possible for
user ID's . I recall that there may be something in the NT server resource kit??

  
> We've been using a version of the PDC code for...  blimey, must be nearly a
> year and a half now, with over 200 satisfied users.  Now we're gunning to
> upgrade to a much more recent version, so that we can take advantage of all
> of the new-fangled features such as networked administrator accounts.
> 
> Anyway, upon testing a recent copy of the HEAD branch, it all worked fine,
> apart from one teensy problem.  Accounts would log in, download their
> roaming profile, and categorically refuse to load in the registry settings
> for that user.  So the logon.bat which maps their drives complains that
> changes could not be saved, and they don't get their nice colours, fonts, et
> cetera.
> 
> Is this because of a change in the way Samba is coded, or is it a known
> issue with a simple solution?  Having to tell 200+ users that they'll lose
> their registry when we upgrade is not something I'm looking forwards to,
> obviously.  :)
> 
> 

> Norman R. McBride                               http://www.city.ac.uk/~norm/
> Computing Services, City University, England          norm at city.ac.uk (MIME)
>  
> "...the extreme case best illustrates the norm..."              Stephen King
>