Grab our RSS feeds Follow us on Twitter Join our Facebook Group Connect with us on LinkedIn, Powered by You.
you are not logged in





Site Services

Community Forums

Discussion Lists

Article Search


Web Blogs


Live Support

myITforum TV

Take a Poll

Monthly Drawing

myITforum Network

User Group Directory

Our Partners

About Us





Industry News:

  Home : Articles : SMS 2.x print | email | | Forums |   print | email | | Blogs |   print | email | | Wiki |   print | email | | FAQs |   print | email | Article Search  
SMS 2.0 SP4 Deployment Stories

Bookmark and Share

By: Rod Trent
Posted On: 1/18/2003

Thinking about deploying service pack 4 for SMS 2.0? Read through the stories of the folks that have already done it.

If you have your own SP4 story you would like to share, email it to me at: By letting us know how your SP4 implementation went, you can help out other SMS admins around the world.

John Potter February 10, 2003

Here's one that might be useful for someone (who like me) has *tried* to disable software metering: When upgrading, I got the dreaded message of "Fatal Error Setup cannot upgrade the SMS database, Contact your SQL Administrator." I read through the smssetup.log and found these lines at the bottom:

<02-06-2003 17:49:11> Registering connects for SMSserv, sa, SMS_LicDB <02-06-2003 17:49:11> Registered the types <02-06-2003 17:49:12> Could not get connection of type SMS ACCESS

I tried truncating the status message logs and transaction log to no avail. Then I remembered that I had disabled software metering several months earlier by altering the file, running setup again, and then removing the License Metering database. Hoping that the upgrade script was choking on the license metering update, I took a blank software metering database from a test server, detached it, copied to the production server, then attached it using the old production name referenced in the log (SMS_LicDB). When I ran setup again, everything worked smoothly.

Having that useless database on my server kind of bugs me, but I am reluctant to try any more sleight of hand to remove it! Maybe I'll get a chance to remove it when we upgrade to SMS 2003.

Janice Ovecka February 8, 2003

Don’t know if you’re still collecting stories about SMS SP 4, but here’s our story:

We have one site with just under 500 clients, using NT 4.0 server and SQL 7.0. Thanks to all the good info on myitforum, we thought we were well prepared. The install breezed right through the database setup and file copying until almost to the very end. Then we got a fatal error that said that setup could not create the SMSProvider account. After working with domain accounts and groups, etc., we finally came across a TechNet article that mentioned password complexity within the domain. We disabled our complexity policies and the install proceeded without a hitch.

We had a problem post-deployment with Matrox drivers and Windows NT 4.0 on a handful of clients. We renamed the idisntkm.dll and haven’t had a chance to find another workaround yet.

Thanks for the great forum!

Susan Morris January 19, 2003

1. Back in July of 2002, I upgraded or primary site to SMS SP4. I ran into a couple of problems
a. During the installation, I received the error "Fatal Error Setup cannot upgrade the SMS database, Contact your SQL Administrator." This error occurred where the upgrade was trying to upgrade the SQL Tables. At this point the D:\SMS\Bin\i386 files have been removed which we didn't know until we rebooted to see if that fixed the problem as SQL looked fine to us. The SMS services (SMS_Executive, SMS_SQL_Monitor, SMS_Site_Component_Manager) fail to start cause the files have been deleted. I called Microsoft and had to manually add the OSPlatform data to the SQL table due to some NULL values that was causing the installation to fail. I was finally able to get the server upgraded successfully after that late on Friday afternoon.

b. Well, Monday morning came around and it was not a good Monday. Over 500 of our workstations came up with a BSOD due to a conflict with the Matrox G400 and G450 video driver we were using. I had to stop the site and rollback to SMS SP3 by direction of upper management and get the site stable again. We removed and reinstalled all of the logon points, CAP's, Distribution points, and clients.

2. We manually upgraded all of our desktop computers to the latest Matrox video driver. We also ran ChkDsk on all of our desktops in case there was any file corruption on the system partition.

3. Last night (1/16/2003) I upgraded our SMS SP3 site once again. I thoroughly reviewed the SMS SP4 Deployment Stories website on

a. During the day I ran an SMS backup and an OS backup.
b. I rebooted all of the SMS related servers.
c. I ran defrag on all my partitions and ChkDsk to ensure there wasn't any drive corruption.
d. I verified all of the SMS account passwords.
e. I made a backup of all of my custom files (sms_def.mof, smsbkup.ctl, machinfo.bat, sitectl.ct0, and smsls.bat)
f. Ran DBCC CHECKBD on all my databases.
g. When showtime came, I inserted my SMS SP4 CD and ran setup.exe /serveraccount: /serverpassword: /clientaccount: /clientpassword: /dontstartsitecomp.

h. I replaced my custom files.
i. I started up the SMS _SITE_COMPONENT_MANAGER.
j. I upgraded my admin console and created an installation share for the helpdesk to upgrade their console as well.

k. I checked on the server and had no critical errors. I then proceeded to upgrade my secondary sites from the admin console using the "Upgrade Secondary Site Wizard". I then went home.

l. This morning, all is well. I am up to 1200 successfully upgraded clients. Woo-Hoo!

Thanks to everyone for their input to the website. It was invaluable to me in this painstaking process.

Scott Ewing October 3, 2002

Our upgrade from SMS 2.0 SP 2 to SP 4 went smoothly.

Our SMS 2.0 hierarchy consists of 6 primary sites and 50 secondary sites. We have about 15,500 client systems running mostly Windows NT 4 Workstation on DELL and IBM hardware. 3 site servers are running Windows 2000 Server and SQL Server 2000 and 3 are running Windows NT 4 Server and SQL Server 7. The servers are on Compaq, DELL and IBM hardware.

Before deploying SP 4 we reviewed the SMS 2.0 SP4 Deployment Stories on and the Microsoft white paper "Deploying SMS Service packs".

We copied the SP4 install code to each primary site servers C drive ahead of time and used remote control tools to run the setup on each server. We did see the long pause during each SQL database upgrade. The size of each primary site database shrunk by between 25 and 50 percent due to the fix that removes the old status messages that had not been deleted correctly. Our central site database is now about 4.5GB. I had missed setting the SQL locks to 0 (i.e. unlimited) on one of the sites so the upgrade failed with the Fatal SQL Error message. A check of the SQL logs revealed the problem. 4 of the secondary sites failed to upgrade. A check of the SMSSETUP log on the C drive of each server showed that the decompression of the SP4 package sent from the parent site had failed. We restarted those 4 servers and reinitiated the upgrade from the parent site. All 4 sites upgraded OK on the second try.

We began the upgrade on a Friday night and as expected about 70% of the client systems upgraded within 23 hours of the site servers being upgraded due to the CCIM cycle on the NT 4 Workstation clients.

We want to express our thanks to all the people who posted their SP 4 upgrade stories on myITforum. They really helped us prepare for a successful deployment.
Ernest Edwards September 25, 2002

Rod, we ran into some serious trouble deploying SMS Serive Pack 4, called Microsoft, found out some interesting items. I would like to share this valuable knowledge. They advised:
1) Ensuring the temp db in SQL Server is at least 20% the size of your SMS database.
2) Have locks set to unlimited (run sp_configure from query analyzer).
3) Run a Site Reset before the update. This will expose any possible problems beforehand.
4) If the SP4 files are on the same drive as SMS, you will need to map out a drive and run the service pack from the mapped drive.

I also prepared ahead of time by:
5) Made a copy of the \SMS\bin\i386 folder
6) Exported all SMS service entries in the registry from our central server. More on this in a minute.
7) Ran the Site backup job, then moved that directory.

As strange as item 4 sounds, He stated it could cause a serious problem.

Fortunally we found out about the temp db issue while doing one of our United Kingdom sites. He said a lot of Admins make this mistake. Our central site is about 1Gb, but the temp db was at the default of 8Mb. It plowed through the update in about 10 minutes on our central site.

As a precaution, I made a copy of the SMS service information in the registry (Item 5). After the SMS_SITE_COMPONENT_MANAGER service was deleted and the installation failed, this backup was worth it's weight in gold. We were able to copy the file to the machine, run the file, and we were back in the game. All of our server loads are identical. Standarization was the key to success in this case.

Once these corrections were made everything load fine. We have 6 primaries, and they all loaded ok.
Ed Aldrich August 8, 2002

OK... we did the deed last night, and here's our story (and we're STICKING to it!)...

Initially I'd planned on doing the HRP immediately after SP4, but due to some issues reported with Win9x clients I decided to pass on the HRP dealio....

I did two primary sites simultaneously using Term Server sessions to both servers from my desk.

So, here's what I did in a nutshell, using my own common sense (what there is of it), and the excellent guidelines included in the README and the Operations Guide included in the SP:

  1. Disabled my W2K/SP2 program so none would attempt to run it while I was upgrading

  2. Checked on SQL growth abilities (AutoGrow is ON here)

  3. Renamed my existing SMSBACKUP folder to SMSBACKUP_SP3_8_07_02

  4. created a new SMSBACKUP folder

  5. ran SMS_Site_Backup service to get a "fresh" copy of current state

  6. rebooted the server

  7. stopped the SMS services (Site_Component_Manager and SMS_Executive)

  8. made copies of my key, and customized, files in a folder OUTSIDE the SMS tree structure (smsbkup.ctl; sms_def.mof; machinfo.bat; sitectl.cto; and smsls.bat)

  9. double checked my records to be sure I had correct (current!) ID and PW for my Server and Client Connection Account (I have three Client Connection Accounts... I used the first - the one in use if you will - of the three). I'm going to specify these on the SETUP command line shortly.

  10. ran DBCC commands to verify SQL integrity

  11. Using START/RUN I then browsed to and ran SETUP /SERVERACCOUNT <domain\account_name> /SERVERPASSWORD <password> /CLIENTACCOUNT <domain\account_name> /CLIENTPASSWORD <password> /DONTSTARTSITECOMP

  12. I proceeded to get an error complaining that this was an invalid filename (or words to that effect)... The GUI clearly didn't' like the huge command line!

  13. dropped to a DOS prompt in a CMD window and repeated the command from the ..\i386 folder in the SP4 directory and launched Setup just fine

  14. Joy-clicked my way thru the few screens and "Let 'er RIP!" at the <FINISH> button; The entire process was complete on both servers within a few minutes

  15. Proceeded to replace all my custom files from #8, above, or at least verify that all that SHOULD be there, was...

  16. Created R/O share of the SP4 folder for the HelpDesk gang to run console upgrades the next day

  17. Fired up SMS Services

  18. re-enabled my Win2K/SP2 program

  19. Ran SMSBACKUP service again

  20. ran Console Upgrade on my workstation & fired it up

  21. Saw a few burps in the status summarizers, but nothing of significance
    went home!

Now - the single biggest lesson learned was that I should have placed a copy of the SP4 bits somewhere other than on the SMS server. The next day, the HelpDesk gang was ballistic, because the site server was running at 80% utilization with a TON of disk I/O, so it took forever for them to get the console installed...

Now, nearly 20hrs after the upgrade was completed, the CPU is still running high (SMS_Exec thread is a solid 40% in Task Manager; server is still running at 80% or better, but the disk I/O has settled down pretty well. Note also that this server is the ONLY CAP for nearly 3,000 clients!

Thanks to a friendly reminder from a fellow Admin, I used my DASHBOARD feature in Web Reporting to monitor the client migration, watching the SP3 count go down, while the SP4 count went up... at this point, I already have 2,400 clients reporting in at the SP4 level.

Oh yes! The Status Summarizers have been current all day, AND they are STILL GREEN!! What's up with THAT!?!?
Steve Thompson August, 6, 2002

Here's another for the SP-4 upgrade "stories", I read through the postings and have not seen this one...

We have sites that share logon points with a senior site that manages the logon points. Monday, 8/5 we upgraded 3 of our sites (top/down) with Sp-4. All is well.

On 8/5 we discover that *new* clients in our down level sites will not install SMS 2.0 components at all. Microsoft confirmed that this is "by design", starting with SP-2. Rather than allow a client to possibly get "mis-matched" client components (logon points are at a higher version, CAPs are at a lower version), clients are simply not assigned. Specific error can be seen in the attached logs (wn_logon.log):
Site <sitecode> is at a lower version (2.00.1493.3188) - it will be skipped for assignment

We were pointed to a KB article that describes this feature:;en-us;Q262677

Moral of the story, we moved up our deployment schedule to complete the rollout sooner than scheduled.
Ivan Lindenfeld July 29, 2002

From the myITforum SMS Email Discussion List.

Our installation went very smoothly. Clients have been a little slow to roll out since one of our 3 CAPs acts like the daddy CAP and wants to answer most requests for a CAP. This was the case prior to the upgrade as well, but SP upgrades keep CAPs quite busy. The clients are still set at the default CAP search setting which is "randomize."

Our database shrunk down quite nicely due to the Delete Aged Status Messages bugfix.

I do have one small problem that I just discovered. Discovery Data Manager is having a helluva time copying data into my SQL database. It will work and suck up all the DDR's then stop and complain about the SQL server not being available. Concurrently other SMS components write to the SQL server just fine, including Colleciton Evaluator, Offer Manager, etc. SQL is on a separate server and is SQL 7 SP4.
Jan Bloch Hansen July 26, 2002

The Story :
Infrastructure: 70 locations, 512 kb lines, 1 Site Compaq NT4 SQL6.5, 4 cap's....2200+ NT4 PC's

SP4 installation went fine, allthough the site was patched with a pre SP2, so the version number was x.x.x.2009 an not x.x.x.2013, as it should be, I saw after the upgrade...

About 1500 PC's were upgraded to sp4 under 4 days, and is still upgrading... (lots of people are on holiday)

BUT... new client installations went wrong with the error : SMS FAQ: #$#$#$#$#$ ERROR: The Client Service is not authorised to run this application! (5), in the CLISVC.LOG on the client.

The fix on Myitforum : did not do the trick - sorry ;-)

And almost everything on Microsoft Technet Q270912 :;EN-US;Q270912&LN=EN-US&SD=tech&FR=0& was unhelpful, except in the bottom of the document, M$ wrote :

  1. To regenerate the files and allow the CIDM service to rewrite the CRC values for these files, begin by stopping all Systems Management Server Services on the site server, including the SMS_Executive, SMS_Site_Component_Manager, and SMS_SQL_Monitor services.

  2. Rename the Cli_inst.cfg and Clibase.cfg files on the site server under the SMS\Inboxes\clidata.src folder.

  3. Restart all of the services on the Systems Management Server site server.

  4. Because these files will not be re-created on their own, a change to a referenced system component will need to be made. A small check like adding a new Client Connection Account will cause these files to be regenerated.

  5. Monitor the site's CAPs and SMSLOGON shares to see when the Cli_inst.cfg and Clibase.cfg files get updated.

  6. Once these files are updated, restart and monitor a client to verify that it is able to start the failing component.

NOTE: If at any point during the preceding steps, you do not get a successful test, this is likely where the problem originates.

Oliver Mohr July 17, 2002

a company I worked for some month ago went into real trouble with SP4. After installing the SP approx. 250 machines ran into bluescreen. It turned out that they all had Matrox graphic adapters and Remote Control Agent installed. Microsoft (Germany, Hamburg) confirmed one week later that there could be a problem with Remote Control Agent and some Matrox graphic adapters together with SP4. They advised to test all Matrox adapters with SP4 before rollout. MS says the problem can be fixed by using a different grapics driver.
Steve Lancaster July 17, 2002

Another story for ya

1 x Primary, 4 x Secondaries, all running NT4 with kilostream links from primary to secondaries. SQL 7 on primary.

Ran setup with /dontstartsitecomp switch. After upgrading primary, I copied the customisations from sms_def.mof and tagged them on the end of the new sp4 sms_def.mof, before starting the sms services. This worked fine.

Upgraded secondaries using site upgrade wizard in the console, one at a time. They took a few hours but all upgraded fine.

Clients are upgrading fine too.

The only problem was that the primary setup bombed out with a Fatal Error whilst upgrading SQL database.
The max number of locks had been exceeded (which is 10000 by default).
After much scratching or heads, we realised the account doing the upgrade did not have sufficient rights.
Re ran the upgrade with the sa account and hey presto, it ran fine.

Apart from that, it has been a doddle.
Stephen Lyon July 16, 2002

Two primary, 17 secondary sites, in 19 cities on 4 continents. Upgrading from SMS 2.0 SP2 on WinNT 4.0 SP6a servers.

Did my primary sites on Saturday (senior/central site first) and then did all the secondary sites on Monday. Installed them all manually - with the source files all copied to the servers themselves, then remoting into them.

Went with hardly a glitch. Only ones of note:

1. Five secondary sites balked on the install when trying to shut down some of the SMS Services. Canceled the install, and manually stopped the services from Control Panel, then restarted the install again. Problems solved.

2. One secondary site stopped responding with "Can't update the registry" errors in Component_Status_Summarizer. Also the SMS clients on the site server deinstalled, and the SMS services balked when trying to restart them (did not restart automatically). Fixed this with a server reboot (but Services still would not restart) so I ran a site reset, and another reboot
- which got it all running again. Forced reinstall of the clients on the server. Has worked fine since then (36 hours now).

No new problems for over 24 hours of close monitoring. Better still, errors about some supposedly corrupt Collections and failures to process about 5% of any given days of s/w and h/w inventories have "magically" gone away.

I am a happy camper.
Al Corsi July 16, 2002

Hi, Rod - something to add to the SP4 deployment stories - Al Corsi

We're in a shared domain with a few SMS sites..... once the senior site was updated to SP4, we had to upgrade (PCs started reporting in CCIM32.LOG that the CAP wasn't as up-to-date as the client core components).

Anyhow, here's our config: single NT4 site server running SQL 6.5 with well over 500 clients

As others mentioned, we had problems with SQL (fatal error updating the SQL database). Based on the last few messages posted in SMSSETUP.LOG, KB article Q268238 led our SQL DBA to the fix: he truncated the status message tables and dumped the database transaction log

Update finished once the database was corrected.
Alex Koifmam July 11, 2002

This is my story about sp4 deploying (it was a sweet dream of all admins :)...

I did it yesterday and till now everything looks fine.

Well, I have very simple configuration:
Compaq Proliant 1600 (500 MHz) with 512 Mb memory; Win NT4 sp6a 128 bit; SQL 7 sp4 (I upgraded from sp2 to sp4 a few weeks ago - no trubles at all); SMS2 sp2. I have only one primary site with 6 different subnets and about 400 clents.

About 2 months ago I downloaded from MS (Ithink) site the "sms20sp4ENU.exe" file. It took about 5 minutes to unzip it. After unzipping I run "autorun.exe" and it takes 10 (ten) minutes to the end of upgrading the site.

Thats all folks !
Adrian Hall July 10, 2002

Today we upgraded SMS 2.0 with SP4 from SP3. Dell 2300 Dual PII 350, NT 4.0 SP6a, Primary site and 3 Secondary sites. We encountered the following error

Fatal Error

Setup cannot upgrade the SMS database, Contact your SQL Administrator. (Boy was that a helpful error message!)

This error occurred where the upgrade was trying to upgrade the SQL Tables. At this point the D:\SMS\Bin\i386 files have been removed which we didn't know until we rebooted to see if that fixed the problem as SQL looked fine to us. The SMS services (SMS_Executive, SMS_SQL_Monitor,
SMS_Site_Component_Manager) fail to start cause the files have been deleted. I had to copy the files from our secondary site to get the services started which are required to restart the upgrade. After this everything upgraded fine. Sent the upgrade out to the secondary sites and waiting.

We are currently waiting for the dust to settle to see what the effect of the upgrade is on our 2 problems (SMSCliToknAcct& account lockout and Mandatory package logoff not timing out).
Janis Keim July 8, 2002

I just got done upgrading to sp4 and hit a couple snags along the way. The first one wasn't really a snag, but just a heads up that others have experienced. If you have modified your sms_def.mof file, be sure to copy it to a safe place prior to upgrading.

The real snag I hit was with a Secondary Site that just plain refused to upgrade. I must have tried to upgrade it a dozen times before I finally got it to work. Keep in mind, however, that my other secondary site upgraded without a hitch. This one particular site just wanted to be difficult. I'm fairly confident that it was happening due to the fact that I have to change the SMSService account password every month, which means the site was experiencing problems before I ever opted to upgrade. I finally got it figured out by using the PREINST command. Also nice to know that you can "Reset a Secondary Site" from those sp4 files too. Of course, I might be the only one who didn't know you could do that.

One other thing worth mentioning is that on one of my Secondary Sites, I had configured a "special group" for remote control access. Not only did the upgrade to sp4 wipe out this recently configured group, but it also wiped out the WMI permisssions on my primary site for that same group. Didn't realize what had happened until I got a bunch of calls about not being able to access the site database. The upgrade left the group in the Permitted Viewers area, but nuked it from the Security Settings and WMI perms on the site server.

Other than that, the upgrade went ok. Site server upgraded in about 30 minutes, one secondary site took 10 minutes, and that difficult secondary site took about a week to get back to normal......................whatever normal is for the SMS world. :-)
Craig Shaw July 3, 2002

Install took less than half an hour an went smooth as pie. The first few clients have updated, and all is looking very good. This has got to be the best upgrade I've ever tried (so far, anyway).
Mike Mott July 3, 2002

1 Site, 2 caps, 8 smslogon shares(BDC's)

Downloaded sp4 to site server.

Run sp4 upgrade from Terminal Service console.

Upgrade lasted 10 mins at most.

No errors.

3600 clients updated within 24 hours.

Used Web reports to watch client progress.
David Clarke July 2, 2002

After successfully testing SP4 in our Model Office suite (tested Central, Primary and Secondary site deployment) we started the real upgrade yesterday.

As expected, the upgrade sat at the "Initializing SQL databases" stage for some time (the database is 12Gb), but after 20 minutes it then failed with "Systems Management Server cannot continue because of the following error. Set up cannot upgrade the SMS Database. Contact your SQL Admin."

As has been noted elsewhere, most of the executables and dll's had been removed by this stage, so we copied them back from a working Primary.

Our guess is that either the SQL database had run out of locks prior to the upgrade (a problem we have had on some of the Primary sites but not the Central), or, more likely, there was some conflict with the Web Reporting (the Central Site hosts IIS).

We stopped SQL and IIS and tried SP4 again.
This time it took over two and a half hours to work through the SQL upgrade before completing successfully.

When we upgrade the primary sites, we are thinking of stopping SQL and SMS Exec before starting the upgrade so everything is in a clean state at the start.

One benefit we've noticed of SP4 relates to Q306315 "SMS: deleted Aged Status Messages Can leave Orphaned Database Entries". We ran the SQL queries referred to in the article and found our Central Site had over three million orphaned entries. After applying SP4 the used space on the database dropped by 25% down to 9Gb.
John Griffin June 21, 2002


Primaries all dual PIII Compaq Proliants with 1GIG RAM

Central Site
3 Primaries
around 40 secondaries
6000+ clients

2 Lab deployments by separate SMS admins OK.

Real Thing:

Extracted SP4 to Central site and began upgrade. Everything proceeded well until setup got to "Initializing SQL databases" then process hung for about 2 hours. Fellow SMS admin suggested canceling setup and rebooting.(Insert remark about hindsight here) On restart Central site reported several service control errors starting SMS. Looked in Drive:\SMS\bin\i386 and found all pertinent .exes .dlls etc removed from here and the subfolders. This caused the site component manager missing error noted in your SP4 stories. In an attempt to fool SMS we then copied the contents of this folder(DONT FORGET THE SUBFOLDERS) from a functioning primary. We then tried a site reset with SP3 and the sms exec restarted, however the admin console would not connect. So a site upgrade with SP3 was chosen and the site returned to the living.( There was much rejoicing). Currently we have a call into Microsoft Premier support to nail down the cause of the initial failure.

Credit must go to my Intrepid colleagues, you know who you are.
Andrew Mason June 20, 2002

Firstly thanks for the great site, it has been a big help over the last few months since I joined!!

My SP4 upgrade has a happy ending, but if there is one thing I did learn it is never use untested source files!!!. My upgrade went something like this:

  • Download SP
  • Extract SP in test lab ( files not put on CD - they dye is cast )
  • Upgrade server in test lab - no problem
  • Cut CD for live upgrade ( different source files - I'm asking for trouble )
  • Upgrade Server ( I found it )
  • Cancell upgrade
  • Extract SP onto server
  • Re-run Setup
  • Pray
  • Pray some more
  • Setup Completes Successfully
  • Open Admin Console
  • Everything is okay
  • Give thanks

The problem was when I burnt the SP on to CD not all the files got copied across, I know I should have checked. Primary server needed the services restarted, and i had to restart 3 secondary sites because they fail to stop the SMS_EXECUTIVE but they all recovered.

1 issues - although I can grant access to the admin console through Global groups I am having problems with remote control permissions!!
Mike Linkey June 12, 2002

Here is what we did for our successful Upgrade:

1. CYA!!! Backup entire server
2. Burn SP to CD....
3. Start Setup with the /dontstartsitecomp
4. Click Next, Next, Next, Next, Finish!
5. Pray nothing bites it!
6. Stare out the Window at the Sunny day wonder why I am doing this instead of being at the Water park! 7. Come out of Daze to notice Setup completed successfully! 8. Copy back custom SMS_DEF.MOF info. 9. Verify that the Web Reporting Treedata.xml file is still cool! 10. Reboot for good measure 11. Check site status....All is well...Remote Caps installing 12. Pat myself on the back for Job well done since no one was watching!

This is in a nutshell the way our SMS SP4 upgrade went. Clients are currently updating as they are rebooted or hit their 23hr cycle! All in all a good clean install!
Jo Verbrugghe June 4, 2002

After we deployed SP4, we noticed high CPU usage.

Further investigation indicated that tlist.exe took almost 50%. I found article Q261184 (Tlist Causes Backup to Hang), which gives the impression that it's only a problem until SP2.

Basically, they recommend to use Pulist.exe instead of Tlist.exe (also part of the NT4 Resource Kit), and adjust the batchfile machinfo.bat.

When I looked up machinfo in the extracted files in SP4, under \smssetup\bin\i386, I noticed these lines :

REM Systems Management Server (SMS) version 2.0 with Service Pack 1
set sms_machinfo_filedate=The batch file was last updated May 30, 1999

Thus, SP4 overwrote our adjusted machinfo.bat with an older version (with calls to Tlist.exe), hence the high CPU usage and hung backups.

Since we replaced Tlist.exe with Pulist.exe, no more problems occured.
Alex Bransky June 3, 2002

I just installed it with no problems at all. Here is my configuration:

Windows NT 4.0 Server, SP6a
P2 450 Mhz
256 MB RAM
2 Gigs free on C: drive
10 Gigs free on D: drive (which contains SMS files)
Microsoft Web Reports installed and running
SQL Server 7 on same machine, 440 MB SMS database
3 logon points (all NT 4.0 Servers)
Kevan O'Leary May 31, 2002 from the myITforum SMS Email Discussion List.

Well, took the SP4 Plunge. No, not the Nestea plunge, the SP4 plunge. Basically I have 1 primary, 3 secondaries. I applied the SP on my primary site, and waited for it to finish. There was a brief delay at the SQL piece as other people have noted and then it finished fine. No errors. I then pushed the secondary sites simultaneously with the secondary site upgrade wizard. Again it took a while, but eventually worked fine with no errors. Finally I upgraded my SMS Admin Console and that went fine as well. When all else was done, I put back my backed up SMSDEF.mof. BTW, the version of your site if it completes successfully should be 2.00.1493.4012 when it's done.

I've been monitoring all this morning and so far so good.
Alecia Anderton May 30, 2002

I encountered a problem when I initially tried installing SP4. The install would die when creating program groups. I tried to install it 4 times.

Finally, I decided to download the software again from Microsoft and try one more time. This proved to be positive. The fresh software took care of the problem. The installation of SP4 didn't take long to install. It took all of 10 minutes to install. Afterwards, I rebooted the server and everything appears to be functioning okay.

1 SMS 2.0 NT server
SQL 7.0 SP4
933 clients
Ringler Stefan

Two days ago, I did the SP4 Upgrade in our Sites (2 primary and about 20 secondary sites). We have a W2k domain registered in all these sites and now the Default Domain Controller Policy is written new all 10 minutes. The SIDs from the last entries are always from SMS&_Server accounts to grant logon as a service permissions.

We probably don't know what to do, we are still searching for the cause.
Karen Hoyrup

Our company grants permissions to SMS Remote Control by using a global group. After upgrading to SP4 from SP3 yesterday afternoon, all users within that group lost the ability to remote control. The only way around this problem at present is to grant security rights to EACH individual account. Microsoft is now aware of the problem and has classified it as a bug in SP4.

I would caution anyone who uses global groups to grant permissions in SMS to be aware of this issue before upgrading to SP4.

Brian Barnhart June 5, 2002

We are using group base security, after seeing this string, I tested for the issue described below in our lab environment. I created 3 global groups and assigned those global groups specific SMS security rights in the administrator console. I tested the console using 3 test users that were members of one group each. I could not duplicate the problem described below. I made changes to the SMS security rights on the global groups and tested to ensure that the rights were enforced. SMS behaved like it was supposed to. Granted this was a test environment, but it killed my fears I had after seeing this string, as soon as we get the change record approved, we will be upgrading to SP 4. I do appreciate people posting things they
have found with SP 4. Hope this helps

Zubair Rajah June 5, 2002

I specifically tested this issue in our LAB, and after SP4 everything works fine.
Tommy Asplund, Manpower IT Service, Sweden

I've just deployed SP4 on my central site...
Tested it in my test lab for 1 day, yeah i know it's a bit short but i'm anxious to get a few things corrected, like Q271122 etc etc...

I don't trust "hot fixes" only apply them if i've got BIG problem's, SP's feel a bit safer... ; )

I got a bit worried that there where something wrong with the SQL server when the setup seemed to freeze at "Initializing SQL database tables"... it took about 10 minutes before it went into the next phase... and a few seconds later it was finished...

So now i've been running SP4 on my central site for 45 minutes.. So far so good... : )

I will drop you a mail if something weird happens...

I think i will wait until tomorrow to apply SP4 to the other primary sites...

Thanks for all the excellent info i've gotten from the web site!
Donnie Tayler, myITforum Columnist

Lessons Learned: My SP4 Upgrade
Norman Schulze from the myITforum SMS Email Discussion List

Yesterday i attempted to update my testsite from SP3 to SP4. Unfortunately it failed during updating the SMS DB. The DB is not hosted by the site server but is on a separate SQL2000 box, the SMS Provider is on the SQL box.

The SMSSetup-log says:

<05-16-2002 17:15:17> Upgrade database...
<05-16-2002 17:15:19> SQL Script: Creating indexes on SoftwareProduct
<05-16-2002 17:15:21> SQL Script: Creating indexes on SoftwareFile
<05-16-2002 17:15:22> SQL Script: Creating indexes on SoftwareFile
<05-16-2002 17:15:22> SQL Script: Creating indexes on SoftwareFile
<05-16-2002 17:15:23> SQL Script: Creating indexes on PackageLocations
<05-16-2002 17:15:23> SQL Script: Creating indexes on PkgStatus
<05-16-2002 17:15:23> SQL Script: Create SQL object sp_SMSDisplayOldClient
<05-16-2002 17:15:24> SQL Script: Create SQL object sp_SMSUpdateOldClient
<05-16-2002 17:15:24> SqlExecuteAsync < IF NOT EXISTS (select * from SupportedPlatforms where StringId = 5061) insert into SupportedPlatforms (DisplayText, ResourceDll, StringId, OSPlatform, OSName, OSMinVersion, OSMaxVersion) values ('x86 NT 4.0 Service Pack 6a Clients', 'baserc.dll', 5061, 'I386', 'Win NT', '4.00.1381.6', '4.00.1381.6') >

<05-16-2002 17:15:25> SqlExecuteAsync < IF NOT EXISTS (select * from SupportedPlatforms where StringId = 5062) insert into SupportedPlatforms (DisplayText, ResourceDll, StringId, OSPlatform, OSName, OSMinVersion, OSMaxVersion) values ('All x86 Windows XP Professional Clients', 'baserc.dll', 5062, 'I386', 'Win NT', '5.10.0000.0', '5.10.9999.9999') >

<05-16-2002 17:15:25> CSql::Execute failed, SQL error <General SQL Server error: Check messages from the SQL Server.
Attempt to initiate a new SQL Server operation with results pending.
Violation of PRIMARY KEY constraint 'SupportedPlatforms_PK'. Cannot insert duplicate key in object 'SupportedPlatforms'.

The statement has been terminated.

We had implemented the hotfix for supporting the XP-platform, it seems to me that this is causing trouble...

Unfortunately the site was left in an unstable state, I manually cleared the 2 rows stated above in the "SupportedPlatforms" Table and tried to install SP4 another time, but the setup did not succeed, the setup log stated:

<05-17-2002 08:51:00> Cannot start the site component manager. Reinstall it.

Also the console files were deleted.

All I can recommend to you is: BE CAREFUL WITH SP4 AND TEST IT IN THE LAB!
Chuck Young from the myITforum SMS Email Discussion List

Well it's 750am and I am about to start making plans to implement SMS SP4!

Here is the current plan:

  1. Go get sausage biscuit and 2 chocolate milks.
  2. Eat breakfast at desk.
  3. Make sure resume is up to date (just in case it bombs)
  4. Burn SP4 to CD.
  5. Sweep crumbs off desk and keyboard (see entry #1)
  6. Smoke a cigarette
  7. Take disk to server room and take a deep breath
  8. Start upgrade
  9. Light candles
  10. meditate (think about beer)
  11. insert disk
  12. begin laughing uncontrollably (anxiety attack)
  13. Clap hands, (lights go out)
  14. Disappear
  15. Lights back on,
  16. Reappear as SMSMAN (wearing nothing but a thong)
  17. Begin the setup.
  18. Hit next, next, next, next, next
  19. Big patch!
  20. UH OH! Error Message, “SMSsetup is unable to stop SMS Network Discovery Manager” Ignore, Retry, Ignore All, Exit”
  21. Retry, GOOD!
  22. Continue with upgrade
  23. Complete
  24. Stand up, (as SMSMAN) with hands on hips say “Nothing to it, people”
  25. Throw Flash Grenade
  26. Disappear\ Reappear as Chuck, humble sms admin
  27. Act confused, smile and rejoice that the upgrade with so smoothly
  28. Return to work, think about more beer.

And there you have it my friends, single site upgrade to SP4, currently my caps and other site systems are reinstalling their components as expected.

Brief over view of size of site:

  • 3 Caps
  • 1 SQL 7sp4 server
  • 1 SMS2.0 SP4 site server
  • 3 License metering servers
  • 723 clients
  • Clients: 10 Win95
    95 Win98
    59 NT4.0
    511 Win2k
    11 Win2k Servers
    32 NT4.0 Servers

Well the rest is all about time!

uh uh I mean
Brian Roberson

Upgrade went flawless. The upgrade did pause at the initializing SQL - made me think it was going to fail. Upgrade went well - all machines have been upgraded to SP4. MS PS (Rene) was helping us with a RC hotfix at the time that was included in SP4 -- the upgrade included this hotfix. Our remote control is fixed and the site appears to be in very good shape. Very happy with the upgrade.

Some stats:

  • 5 CAPs
  • 1 SQL 7sp4 server
  • 1 SMS2.0 SP4 site server
  • 734 clients or so


  • 23 95 Win98
  • 28 NT4.0
  • 646 Win2k (serv and ws)

David Jaffe from the myITforum SMS Email Discussion List

I had no problems with a fresh install of SMS 2.0 w/SP2 to SP4.The upgrade was as smooth as any other service pack. I installed Web reports afterwards and no problems have occurred thus far. I implemented the Monster MOF and other additions without any known problems occurring. I will let the list know if any issues come up.

Thanks to everybody who had contributed to my knowledge of SMS. The install and configuration would not have gone this easy without all of you.

Compaq ProLiant
Windows 2000 w/SP2
SQL 2000 w/SP2
SMS 2.0 w/SP2
Elkana Porag from the myITforum SMS Email Discussion List

Servers = win 2000 in native mode

Clients = 300 (win 4 , 2000)

One sms server in single site configuration = win2000-sp2, sql-sp3 , sms-sp3

before the upgrade I backed up my custom Stored procedure - there was no need, they are still there

the procedure took about 15 minutes

no need to restart

for about 3 minutes it gave hell to the cpu but afterward it relaxed

the console looks like it's working

the web reports including all my custom modifications are working too

all looks fine :-)
Dave Edwards

We've had very good success with our SP4 upgrade as we did not experience any problems (1 central, 4 primaries). Overall, I'd say SP4 has been an easy upgrade (I didn't have the pleasure of experiencing 1.2 to 2.0 but I've heard stories!!).
Jo Verbrugghe

I just finished upgrading the central site of our hierarchy to SP4. (was SP3). I first installed it on a testsite and a site below it. No problems whatsoever, but when I tried the same on our production server, Setup behaved the same as described by Norman Schulze (but this time with Windows ME instead of XP)

<05-21-2002 14:24:44> SqlExecuteAsync < IF NOT EXISTS (select * from SupportedPlatforms where StringId = 5062) insert into SupportedPlatforms (DisplayText, ResourceDll, StringId, OSPlatform, OSName, OSMinVersion, OSMaxVersion) values ('All x86 Windows XP Professional Clients', 'baserc.dll', 5062, 'I386', 'Win NT', '5.10.0000.0', '5.10.9999.9999') > <05-21-2002 14:24:44> SqlExecuteAsync < IF NOT EXISTS (select * from SupportedPlatforms where StringId = 5063) insert into SupportedPlatforms (DisplayText, ResourceDll, StringId, OSPlatform, OSName, OSMinVersion, OSMaxVersion) values ('All Windows ME Clients', 'baserc.dll', 5063, 'I386', 'Win 9x', '4.90.3000.0', '4.90.9999.9999') > <05-21-2002 14:24:44> CSql::Execute failed, SQL error <General SQL Server error: Check messages from the SQL Server. Attempt to initiate a new SQL Server operation with results pending. Violation of PRIMARY KEY constraint 'SupportedPlatforms_PK'. Cannot insert duplicate key in object 'SupportedPlatforms'. The statement has been terminated.
<05-21-2002 14:24:44> Cannot execute sql command IF NOT EXISTS (select * from SupportedPlatforms where StringId = 5063) insert into SupportedPlatforms (DisplayText, ResourceDll, StringId, OSPlatform, OSName, OSMinVersion, OSMaxVersion) values ('All Windows ME Clients', 'baserc.dll', 5063, 'I386', 'Win 9x', '4.90.3000.0', '4.90.9999.9999')

The statement has been terminated.

What's different in our story : We DIDN'T implement the hotfix for supporting the XP-platform. We also didn't add new supported platforms.

Meanwhile I found the article written by Phillip Kent, Custom Supported Platforms and SMS 2.0 SP4 issues and solutions.

I removed the list of supported platforms described in his article. (removed them directly from the SQL table 'SupportedPlatforms', because CIM Studio didn't return usefull data to work with). !!!!! In my case SP4 setup didn't recreate all the supported platforms listed in the article.

(Copy-Paste from smssetup.log)
These were recreated:
+ x86 NT 4.0 Service Pack 6a Clients
+ All x86 Windows XP Professional Clients
+ All Windows ME Clients
+ Win 98 original release clients
+ Win 98 SE clients
+ x86 Windows 2000 original release clients
+ x86 Windows 2000 Service Pack 1 clients
+ x86 Windows 2000 Service Pack 2 clients

Were NOT recreated:
- Win95, original release clients
- Win95 OSR2 clients
- All x86 NT 5.0 Clients

Second try :

The service SMS_SITE_COMPONENT_MANAGER was removed in the first step, so this message appeared in smssetup.log!

<05-21-2002 16:20:17> Cannot start the site component manager. Reinstall it.

Didn't like the sound of that! But (on the screen) the setup didn't show an error msg. and after 5 minutes this message appeared and setup continued! <05-21-2002 16:25:19> Cannot start the site component manager. Stop any other servers that might still be here.

Alas, further on Setup failed on this statement
Delete From StatusMessageInsStrs Where RecordID Not in(Select RecordID from StatusMessages). When I retried this from the Query Analyzer, I got the error code (SQL ran out of locks). Apparently this is a long running query : Increasing the available memory for SQL solved this. Make sure you got lots of space and transaction log on AUTOGROW (mine grew to > 1 Gb. during this query).

Third try :

After that, the installation of SP4 finished succesfully.
Had to restart SMS_SITE_COMPONENT_MANAGER manually, but now everything looks OK.

My recommendations :

  • Follow the progress in the smssetup.log
  • Be patient! Don't conclude to quickly that setup hangs.
  • Consider waiting for a Microsoft KB article that describes this behaviour and a workaround.

Gert Van Gorp

We have installed the SP4 with some problems. I installed the SP with the param "/dontstartsitecomp" (see readme.htm) so the services do not start ofter the upgrade. I used this because I wanted to copy our modified SMS_DEF.MOF back before SMS started. After I copied the file I tried to start the SMS Services via SMS Service Manager and I got the message that there was a communication error with the SMS_Executive service. When I looked in the Services I could not find the SMS_Executice Service. I tried to reapply the SP4 but with no success. After the reboot of the server everything became OK

We have SMS SP4, SQL 2000 SP2 on a NT4SP6a server. 1 site and 1000 clients moost are W2K Workstations.
*************************************** ©2010 | Legal | Privacy