Co-Existance Of NT4 & 2K Profiles

[Gary Newton]

I am currently migrating from NT4 to 2K, have deployed AD
and have just started to rollout some 2K clients.
I am finding that the NT4 profiles do not work right on
the 2K clients and our workforce is mobile so users are
working on both clients while this migration occurs.

Is there any way of setting up the user account in the AD
to use a different profile path according to whether they
logon to a NT4 or 2K client?

I have tried a system variable in the profile path and
created the corresponding variable on the client but when
the profile is saved back to the server it creates a
folder \\profile_path\profile.%variable% and not
\\profile_path\profile.%variable_value% as expected.

Anybody point me in the right direction?

 

[Gerry Hickman]

I am currently migrating from NT4 to 2K, have deployed AD
and have just started to rollout some 2K clients.
I am finding that the NT4 profiles do not work right on
the 2K clients

You have to ensure users are educated to only log onto the O/S they've
been assigned. Each user will be told they're either on Win2k or NT4,
they must not log onto a box running the other O/S.

If user X has a desktop and a laptop, both must be updated at the same time.

 

[Guest]

-----Original Message-----


You have to ensure users are educated to only log onto the O/S they've
been assigned. Each user will be told they're either on Win2k or NT4,
they must not log onto a box running the other O/S.

If user X has a desktop and a laptop, both must be updated at the same time.

Unfortunately not as simple as that, we have a mobile
workforce with staff moving around the county all during
each working day. We also provide a 24/7 service as a
business. With the number of clients to upgrade it is
impossible to not face the situation where a 2000 user
will be faced with logging on to a NT client.

I appreciate your thoughts, but what I am looking for is
a technical solution that will minimise support and
administration overheads during the migration without
placing the onus upon the user base.

Gary Newton

 

[Gerry Hickman]

I appreciate your thoughts, but what I am looking for is
a technical solution that will minimise support and
administration overheads during the migration without
placing the onus upon the user base.

My advice is still the same. You are setting yourself up for future
grief by allowing upgraded users to log back into NT4 systems. It's not
that hard to make sure this doesn't happen.

If you tell me the EXACT details of the problems you are experiencing
and exactly what your server setup is in relation to profiles, and what
NTFS you've got on both breeds of client and server, I'll try to help.

 

[Guest]

-----Original Message-----


My advice is still the same. You are setting yourself up for future
grief by allowing upgraded users to log back into NT4 systems. It's not
that hard to make sure this doesn't happen.

If you tell me the EXACT details of the problems you are experiencing
and exactly what your server setup is in relation to profiles, and what
NTFS you've got on both breeds of client and server, I'll try to help.

I agree in an ideal situation it should be possible to
train users to use only specified computers but the
roaming workforce, sheer logisitics of locations and
number of clients to upgrade mean that it is likely there
wil be an occassion where some user is faced with nothing
but NT4 clients.
We have Windows 2000 servers hosting roaming profiles.
We currently have NT4 client desktops everywhere but are
due to migrate to Windows 2000 shortly.
NT4 NTFS and Windows 2000 NTFS in place according to OS.
What I want is a solution to support the migration.
The main problems and that we apply NT4 polices and
romaing profiles and will be moving to Windows 2000
polices and romaing profiles. We provide a high level of
client lockdown for the user through policies (no desktop
icons, no run, etc) and we find when a user with 2000
policies and profile logos on to a 2000 client all is fine
but when that user goes to a NT4 client the polices only
partially apply and the security is compromised.

 

[Gerry Hickman]

The main problems and that we apply NT4 polices and
romaing profiles and will be moving to Windows 2000
polices and romaing profiles. We provide a high level of
client lockdown for the user through policies (no desktop
icons, no run, etc) and we find when a user with 2000
policies and profile logos on to a 2000 client all is fine
but when that user goes to a NT4 client the polices only
partially apply and the security is compromised.

My guess is that the registry keys manipulated by NT policies are not
the same as those of Windows 2000. You could check by looking at the ADM
files of each (if you can find them).

I'm not aware of any official Microsoft guidance on this which is why I
opted for the "do not log onto NT machines" policy when I did my own
migration. The potential mess it could cause in HKCU does not bear
thinking about.

One thing not many people know, is that even after the migration, your
shiny new profiles will still have horrible legacy stuff in their HKCU
hives from old software, and bits of NT4. I ended up cleaning most of
them manually, as I didn't know any other way to do it. In an ideal
world, you'd clean them and then compact them, otherwise the files
within which they reside will be too big (over 1Mb in some cases); again
I'm not sure how to do this.