This thread is a compilation of 'best practices' on
how to migrate from SMS 1.2 to SMS 2.0. It's aim is to help those organisations
faced with this task plan the best way to achieve their goals by learning from
the experiences of others that have already undertaken this process.
This thread is organised alphabetically by contributors
surname.
Joseph Eager:
We have just finished up moving our domestic SMS structure
from 1.2 to SP2. We de-installed the SMS 1.2 clients completely first. Then we
removed all the 1.2 site servers as our hierarchy was changing, then built our
SMS 2.0 server hierarchy and then did client installs in several waves. The
worst part was our field network where some of the WAN connections were
painfully slow.
We found SMSnuke to be the best at removing the 1.2
client. Worked fine for us. If I were to do it again, I think I might use 1.2 to
distribute the SMS 2.0 pre-install files (SLOWNET, SNBOOT, BOOT32WN and CLICORE), before removing the SMS 1.2 client.
Tim Flower:
We used the 12cliclean (modified) that has been floating around for a while
to remove the 1.2 client from 95 and NT workstations where users have admin
rights. This is done via a Kix login script. We liked this method because we
were able to predict exactly what would occur on the 1.2 client at login -
something we couldn't do 100% of the time if SMS did it on it's own. We also
wrote our migration plan under SP1, which was not as clean as it is now.
Although we rolled to production with SP2, we kept our rollout plan which
included the 1.2 de-install. As soon as the 12cliclean was completed, we kicked
off SMSMAN from the users local SMSLogon share, with Heartbeat discovery enabled
to complete the process.
For NT workstations that did not have admin rights, we
created an advert that would go to all SMS 2.0 PC's that inventoried the 1.2
client software. The first advert the new SMS 2.0 NT PC received was the 1.2
client de-install. This was probably overkill, but it worked nicely in most
cases.
Finally, we added an IPF to the Kix login script that, for
clients that already migrated to the 2.0 client, would check and remove the 'HKEY_CURENT_USER\run\smsrun32.exe' command. We found that PC's with multiple profiles
that had the client removed under one profile, would error out under another
profile because this key was only removed for the user who was logged in during
the de-install.
Cliff Hobbs [MVP SMS]:
When we did our migration from 1.2 to 2.0 we took the 'get rid of 1.2
first before installing 2.0' route and didn't have too many problems.
To delete SMS 1.2 from the servers we:
- Deleted the site from
the 1.2 admin console and then left things to settle down for at least 24
hours.
- Then on the server
disable all of the SMS 1.2 services.
- Then delete the
'MS' directory from the root of any drives.
- Stopped sharing the
'SMS' directory before deleting it (again it's present in the root
of the directory).
- Deleted the
'SMS' hive from
'HKLM\Software\Microsoft'
- Rebooted the server
To delete 1.2 from the
client we:
- Looked for
the 'MS' directory in the root of each drive.
- Opened 'CLI_NT.LOG'
using Notepad in '?:\MS\SMS\LOGS'
- Noted the server name
from where the files were originally installed.
- Mapped a network drive
to '\\server_installed_from\SMS_SHR'
- Run 'DEINSTALL.BAT' from the newly mapped drive.
- Rebooted the server.
- Disabled all of the
SMS 1.2 services.
- Deleted the
'MS' directory from the root of any drives.
- Searched for
'SMS.INI'.
If it was found, delete it.
- Delete 'WUSER32.EXE'
(the SMS 1.2 Remote Control agent), if present (this file is normally kept
in C:\WINNT)
- Delete the following
registry keys
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS
HKEY_LOCAL_MACHINE\System\Current_Control_Set\Services\Wuser32
HKEY_LOCAL_MACHINE\System\Current_Control_Set\Services\Invcli32
- Reboot the server
again to clear and SMS 1.2 components from memory.
From experience, we've
found that manually deleting the 'WUSER32' file helps the
SMS 2.0 Remote Control installation
no end.
Michael Mott:
Would a general consensus be then to allow the 1.2 client to update on NT
systems and not on 9.x systems? Or the other way around. I have seen the upgrade
work fine in both cases, but everything always works well in the lab!
Of the removal tools, I have seen cases where not all the
directories get removed, but maybe it is not necessary. Some folks have talked
about removal of the client portions of SMS in the 'load=' section on 9x, but what
about the calls in the autoexec.bat? How about the smsrun32 section of the
registry for NT?
Rob Olson:
We migrated over 7000+ clients from 1.2 to 2.0 we
did 'not' de-install them. We simply removed the lines from the load
statement in the 'system.ini' file I think it was. We simply wanted to avoid the
users getting the error of the SMS 1.2 client not being able to detect its SMS
logon server - I'm sure you're familiar with that error. Once we did this via
sending a package with our current 1.2 build things went just fine. We also
removed the logon script before we sent out the package so SMS wouldn't repair
itself. You could also perform this via your logon script, to disable the
clients.
SMS 2.0 completely migrated the clients from 1.2 to 2.0
with no hassles! In fact you can watch the logs as it does it. We felt more
comfortable letting SMS 2.0 doing the migration rather than us doing it and
having it throw out errors or interfere with production and having our help desk
swamped.
We did a parallel migration of dropping the clients off
the 1.2 server and then placing them right into the 2.0 server. I might mention
we kept 50+ branches on 1.2 because they are supported via their Novell server
as an SMS site server and we are not running client32. So we are running 1.2 and
2.0 side by side and all is hunkie dorie.
Jean-Claude Sente:
We are currently moving our 1.2 site to 2.0 SP2. 1500 PC,
single site. We have chosen the remove 1.2 approach as our current 1.2 site was
so buggy.
Configuration : 4 Servers running Win2k Server with SMS 2
SP2
1 Site Server
1 Licence Metering Server
2 Distributions points/CAP Server
Discovery Method Network Discovery
Logon Discovery without any logon scripts modifications
Heartbeat
All Clients are manually installed.
Clients are a 'nice' mix of Win9x, Win nT4, Win 2k with Novell Clients loaded !
We wrote an 'upgrade' pack including:
- SMS 1.2 Client Removal
- WMI 1.5
- DMI for all Compaq clients
- DCOM 1.3 For win95x clients
- K9 NTP Time synchronizer for all clients
- SMSMAN
and hired 3 people for a month to install the pack using
'Adidas Net.'
Installation is running smoothly without nearly any problems.
The 'upgrade pack' is a Wise installer package installing
all of the components. The whole execution time is about 5 minutes on a Pentium
III processor. It's about 16 MB when compiled and running from a network share.
K9 is the client component of Tardis (NTP Server), this client is just listening
to NTP broadcast, there is an NT service or a 9x client running in the
background. Tardis costs about $1900 for a unlimited site license. Check for
Tardis on any Tucows Site.
Mark Sykes:
Yes Dave Trupkin's comments on Remote Control were a problem but only if you
migrated the clients. You had to reboot and logon a couple of times before the
RC component was completely installed. It was some what of a pain. The
12cliclean works nicely but it's all in how you want to do your work. You can
either do nothing on the front end, migrate the client and let the RC component
install after a couple of boots, or you can do a heavy front end with the
12cliclean and make the client installation a fresh one which will be smooth and
seamless.
Dave Trupkin:
We had (and are still having) weird remote control
problems on the clients where we allowed SMS 2.0 to perform the removal. The SMS
2.0 Remote Control client will start at boot time and stay active through the
first user logon. Then, when the first user who logs on to the machine logs off,
the Remote Control client will stop. It can be manually restarted when we want
to control the machine but will stop again when the next user logs off.
Microsoft support said it sounded like the service was running in a user context
instead of the local system account, but that isn't the case.
Brian Wilson:
I am not sure why everyone gets so excited about removing
the SMS 1.2 client first. In our labs before we went to production we found that
when using Network Discovery and Remote NT Client Installation two parts of
clicore actually remove the 1x client (i.e. 'migrat1x.exe' starts automatically
when the 1.2 client is detected). I can see the need for non-NT machines, but it
seems overkill for NT. As far as Tardis goes, it's a small footprint product and
very reliable. highly recommended.
|
