SBS client setup : new user profile ?
Herman Bernaerts
The installation of the server went ok, until now.
When creating a new user at the server and running the client setup diskette
on a workstation, a NEW USER PROFILE has been created.
All the settings of the desktop, favorites, internet options, etc... have
been cleared !!!!
The workstation is WinNT 4.0.
Is there a way to go back to the previous profile ?
Is there a way to do the client setup manually (installing the Exchange
client manually,.etc..)
Jeff Middleton
You appear to have properly diagnosed this, not there isn't an option.
I've posted a few things on this recently, here's an older one that may help
you in the process, but not the result, your stuck with it.
<snip>
You must have an NT workstation there, right?
By using the same name for domain and server name, you have solved some
issues for getting exchange and SQL to work, as well as drive mappings for
the clients. However, there is not way you could have avoided the issue you
have remaining. It's not serious, but it is confusing.
NT workstation use SIDs (security IDs) with exact numbers matching the
domain controller for the network PDC. When you install SBS from scratch, a
new set of SIDs is created. These SIDs have nothing to do with the name of
the computer or domain. Therefore, no matter what you named your new setup,
your SIDs would be different.
Now, the name in the domain blank may be identical, but the computers can
tell that the new PDC is not the same computer because the SIDs don't match.
Your resolution is simple. You must go to each NT computer from the old
network in the Network settings and manually remove the computer from the
domain. With this done, you can now either run the setup disk on this
computer, or reintroduce the computer to the new PDC by again joining the
domain. If you are changing from SBS 4.0 to SBS 4.5 in the process, I would
go the route of the setup disk. If you are not changing versions, then the
domain join process should resolve this.
CAUTION! There is one other very important thing to know. When you do this
process, you will lose all the current desktops, mail profiles and
personalization of all users on all the NT workstations. Those desktops are
tied to the SIDs of the old users established on the old PDC. You will find
that when you log in with the exact same username as before on the same
computer, but in the new domain, you will get a clean desktop and user
configuration. You will want to save any such information before changing
over to the new PDC. Because you have the same domain name for both PDCs,
the only way to get back to the old desktop will be to remove the computer
from the domain again, remove it from the network, and reconnect it to the
old PDC, add it back into that PDC domain, then log back in. As long as the
old server remains 'available' you could do this, but you will not likely
want to make a practice of it. I mention it only in case you desperately
need to reverse course temporarily to get something and don't know how.
<snip>
............then to a different followup topic, the question was posted
could you 'blend information' from an old profile to a new one.....
<snip>
This tends to become a very messy process. :)
Let me explain what doesn't work first, the back to what does.
One cannot copy the entire profile folder or rename it. The profile folder
itself has SIDs that don't work because they are local to the machine, not
the domain. (...dissolve to previous discussion....'A SID actually has a
complex number that is made up of the combination of the SID part (from the
SAM providing the account management, either the local machine or the
domain) plus a RID part which is the Relative ID that make the user unique
within the global SID part. In other words, the SID+RID is commonly called
a SID, but it's actually the combination of the two, one that's the security
provider, the other that is the user part...') You can't simply acquire the
profile entry this way because it's a system folder, not a user folder (at
least I've never heard of how to do this) and since it's controlled by a
different SAM (the domain vs. the local workstation SAM) just acquiring the
profile with a rename is hosed. Changing the name of a profile in NT
doesn't help cause the OS looks at the SID, not the folder name. Under
Win9x, however, the name of the folder is all it takes.
BTW: (Bonus points: This is why one can reuse a workstation from one SBS to
another with the same desktop by using the same username. Win9x just looks
at the name. You can even duplicate the profile folder, rename it, and
establish a new personality. When you copy the contents, you are actually
copying, among other things, an entire copy of that user's registry .DAT
files. With this knowledge, it is sometimes possible to recover a corrupted
Win95 installation for a particular user by duplicating another user's
profile into the previous user's folder, or creating one with the same name)
What does work?
Just about anything under the profile folder can be moved or copied, but
there remains an ownership and permission issue to resolve. The files below
the Profile folder can be moved, then the user can take ownership of the
files as appropriate while logged in as the 'new' SID identity. However,
one must carefully observe that not all files are owned by the user
themselves, some are owned by the Administrator and are given writes for
access. Other files point as shortcut links to original files that are
located elsewhere. In some instances, the link file may be accessible, but
the file it point's to is not because THAT file is owned by a different user
(the administrator or the previous user SID) and is not available to just
anyone. This can create a 'thread' of permissions that one must follow in
order to resolve why a program does not launch or function correctly. To
make it more complicated, NT even allows registry entries to have permission
controls that can enter into this process. In the long run, it can be more
complicated than it is worth to pursue.
As for the favorites and cookies, the most critical to save, these can
pretty well just be sucked over to the new profile. One may need to take
ownership, but it doesn't get much more complicated than that.
Lastly, as I mentioned before, if the programs are not installed in the
preferred manner, that is by the local Administrator in every case, then you
can come up with some extraordinarily complex combinations of files, menu
entries, and registry settings that will confound the most creative attempts
to migrate. I have faced situations in the past where a machine that had
been running standalone eventually was just volunteered to be reloaded
because it was just too complicated to sort out and it seemed all the
programs had some sort of problem. This is rare, but it can happen if the
previous use was a bit chaotic and involved many install and uninstalls.
<snip>
These are neither exactly on your topic, but there's some valueable stuff if
you find the context to your problem.
Herman Bernaerts <herman.b...@vereycken.be> wrote in message
news:7vuptk$i0s$1...@news3.Belgium.EU.net...