Windows 2000 SP4 Update Rollup "Sticking"
Dave Hawley
It appeared to install correctly, but Windows Update is still telling me that
it needs to be installed! I installed it twice using Windows Update, and then
again using the downloaded standalone installation file, but the problem
still persists. The registry value at the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\Update
Rollup 1\ is "1" which I would have thought was correct. In another thread,
is was suggested that this value should be "2". I've tried changing it to "2"
but the update still won't disappear from the Windows Update Critical Updates
list! Does this mean that it isn't actually installing correctly?
Sheaffer@discussions.microsoft.com Mike Sheaffer
steps you did as well, but WU still prompts to install this update every
time. Have you found any solution?
Dave Hawley
I don't think we're the only ones having the problem either!
The MS MVPs seem to be very silent about this. I wonder why?
Dave Hawley
Thanks for that.
I have just tried again uninstalling and reinstalling the Rollup (using the
standalone installer), with all my virus scanners, firewalls, and webtraps
all switched off.
Exactly the same result as before, an apparently successful install, but
Windows Update still says I need to install it!
I have also downloaded and installed the MBSA tool.
That also tells me that the Rollup is missing, and I need to install it!
Any other ideas?
Thanks, Dave.
>
"Robert Aldwinckle" wrote:
> "Dave Hawley" <DaveH...@discussions.microsoft.com> wrote in message
> news:0F6673B6-7FA7-4B5B...@microsoft.com...
> It may mean that the final deferred copy step was not completed.
> Did you leave security programs enabled which could have interfered
> with this step? You could check the log to see which modules were
> involved in the update and the current versions of those modules.
> Check with the file manifest of the associated TechNet Bulletin
> if the log doesn't make the updating versions clear.
> Or you could use the MBSA to see what it thinks about the situation.
> If the MBSA doesn't report module discrepancies automatically
> you may still need to use the mbsacli.exe with its HfNetChk switches.
>
> <title>Microsoft Baseline Security Analyzer (MBSA) version 1.2.1 is available</title>
> http://support.microsoft.com/default.aspx?kbid=320454
>
>
> Hmm... it looks as if there is no separate bulletin for this update
> and hence no file manifest. There is a list of separate security
> updates which do have their individual bulletins and file manifests
> so that suggests that MBSA could still be used if only to tell you
> what it thinks in terms of that list.
>
> http://support.microsoft.com/kb/891861
>
> (MSN search for
> sp4 rollup
> )
>
>
> Note that doing that will just get you a better symptom description.
> E.g. identify which modules are regressed, etc.
>
>
> Another approach would be to try uninstalling the whole rollup
> and then try to reinstall it under more controlled conditions.
> The idea there would be that the uninstall would reinstall
> all the old versions of the modules which were present before
> the first time you installed the rollup package. Then the reinstall
> attempt would actually do some updating, hopefully more cleanly
> this time.
>
>
> HTH
>
> Robert Aldwinckle
> ---
>
>
>
Robert Aldwinckle
news:0F6673B6-7FA7-4B5B...@microsoft.com...
Robert Aldwinckle
> Hi Robert,
> Thanks for that.
> I have just tried again uninstalling and reinstalling the Rollup (using the
> standalone installer), with all my virus scanners, firewalls, and webtraps
> all switched off.
> Exactly the same result as before, an apparently successful install, but
> Windows Update still says I need to install it!
> I have also downloaded and installed the MBSA tool.
> That also tells me that the Rollup is missing, and I need to install it!
> Any other ideas?
If you need more help you are going to have to be more forthcoming
with the details I mentioned that you can find. If the uninstall-reinstall
idea didn't work, as I indicated I think you need to be able to express
your symptom in terms of regressed modules or incomplete
updates in order to be able to devise a repair procedure.
Did you find a log for the update? What was it called?
Is that how you determined that the update was "apparently successful"?
Did it show you a list of the modules which were copied? In particular
did it show you a list of modules which had to be "copied" by a reboot?
Did it show you any version information for those modules?
Have you verified that those modules still have that version?
I found that there *is* a TechNet Security Bulletin associated
with this update which hints that some of those modules may
have versions greater than the versions implied by the list of
patches it was composed of:
http://www.microsoft.com/technet/security/advisory/891861.mspx
(MSN search for
(891861 OR KB891861) site:microsoft.com
)
<quote>
Should I install Update Rollup 1 even if I have kept my
Windows 2000 SP4 systems up to date?
Yes. Update Rollup 1 contains additional important fixes
in files that have not previously been part of individual security updates,
as described in the Knowledge Base Article.
In addition, the Update Rollup 1 contains additional enhancements
that increase system security, reliability, reduce support costs,
and support the current generation of PC hardware.
In some cases, the individual binary files released
in previous individual security updates may have been updated
via individual hotfixes to address minor compatibility issues introduced
in those prior security updates that affected individual customers.
The latest versions of those files are included in the Update Rollup.
</quote>
So even though there is no manifest it should be possible
to create a list of modules which have greater version than
they would have if you had just installed each update separately.
Presumbably those modules will be what MBSA isn't finding
and which makes it think that your update is not installed.
Perhaps the MBSA mssecure.xml file can provide some insight
on this question. At one time the HfNetChk tool could do this type
of analysis on the installed modules (e.g. using switches such
as -v -z) I indicated that I wasn't sure if the latest MBSA
would give you that kind of detail report in its GUI mode
and mentioned the mbsacli.exe command-line alternative.
Perhaps you will have to resort to using it after all.
What exactly have you done with the MBSA so far
and what exactly did it show you?
HTH
Robert
---
Dave Hawley
I have looked at the Rollup install log, (which is called
UpdateRollupPack.log.)
I can see no obvious errors recorded other than an apparent failure to open
some registry keys, which may be the source of the problem of course!
I am just printing it out (18 pages!)
I use the Windows 98 System File Checker program to check for version
changes on system files, even on Windows 2000 (I have a dual boot system) and
always run it to check whenever I install an update, to see what files have
been changed.
The log from that will tell me what files were changed when the Rollup was
installed, and what the previous and new versions were.
I will crosscheck that with the Rollup installation log, and make sure that
all the files mentioned in that as having been changed were in fact changed
correctly.
This will take me a while, so I will come back to you when I have a result!
Thanks again for your help with this.
Cheers, Dave.
>
"Robert Aldwinckle" wrote:
> "Dave Hawley" <DaveH...@discussions.microsoft.com> wrote in message
Robert Aldwinckle
> Thanks again Robert.
> I have looked at the Rollup install log, (which is called
> UpdateRollupPack.log.)
> I can see no obvious errors recorded other than an apparent failure to open
> some registry keys, which may be the source of the problem of course!
You could give us those extracts to work with.
> I am just printing it out (18 pages!)
> I use the Windows 98 System File Checker program to check for version
> changes on system files, even on Windows 2000 (I have a dual boot system) and
> always run it to check whenever I install an update, to see what files have
> been changed.
Could you explain your procedure? There may be some NTx tools
you could use which would do just as good a job and be better understood
by others here.
For example, in XP there's msinfo32 which allows you to get full
version information on *loaded* modules. Does W2K have that too?
Or from the XP Support Tools I have command line tool filever
which would also be an improvement over manual checking.
> The log from that will tell me what files were changed when the Rollup was
> installed, and what the previous and new versions were.
> I will crosscheck that with the Rollup installation log, and make sure that
> all the files mentioned in that as having been changed were in fact changed
> correctly.
> This will take me a while, so I will come back to you when I have a result!
> Thanks again for your help with this.
You're welcome but let me repeat my last question because I still think
that using the MBSA or its command line tool might be the most
expeditious tack.
>> > I have also downloaded and installed the MBSA tool.
>> > That also tells me that the Rollup is missing, and I need to install it!
...
>> What exactly have you done with the MBSA so far
>> and what exactly did it show you?
Good luck
Robert
---
Dave Hawley
You're welcome to have the logs from the Rollup install and from the System
File Checker, but how would I get them to you?
I can't just copy and paste them into a message here as they are both huge!
I have been running the MBSA tool just using its graphical interface, and
after the first scan it told me that two critical installs were missing. One
was the Malicious Software Removal Tool (KB890830), and the other was the
Update Rollup of course.
I downloaded and ran the tool (the system was clean) and then did another
scan with MBSA. Only the Rollup was reported missing on the second scan, as I
expected.
I do have msinfo32, and have looked and found nothing unexpected.
I will only show modules that are actually loaded though won't it?
Any other dlls/exes which were part of the update but are not actually being
used by the system at that time will presumably not appear in the msinfo
listing.
I also have the filever utility.
The trouble is that we're not talking about a few files being changed here,
we're talking about hundreds!
I still think that my printout of the SFC log will give me the best chance
of making sure that the versions are what they now should be.
It is in an easy to read format, and gives the before and after file
versions and dates. I can always check the files individually if there is any
doubt about any of them.
I don't think that any of the command line utilities that you mention are
going to give me any more or any clearer information than what I already have.
I will let you know how I get on.............
Thanks again,
Dave.
>
"Robert Aldwinckle" wrote:
> ....
Robert Aldwinckle
> Hi again Robert,
> Sorry for the long delay in getting back to you.
> I have spent several happy hours going through several hundred files which
> should have been replaced by the Rollup, and as far as I can determine from
> the logs they were all successfully replaced. Whether they were replaced by
> the correct versions I cannot tell, as I don't know what the correct version
> now is!
Precisely why I thought that the MBSA command line tool might help.
Going through its detail reports can be tedious too but at least it's not
as bad as going through the mssecure.xml file manually. You assume
that mbsacli.exe has already done all that and all it is reporting to you
are discrepancies it has found. That's the list you want. In fact I think
that detailed reports from two scans, one after an uninstall of the Rollup
and one after an install attempt of the Rollup might be useful. The former
will be huge because it will be comparing against a completely updated
system. It would be nice if we could tell it to compare without the Rollup
but I guess you would need an older copy of mssecure.xml (i.e. pre-Rollup)
to do that.
> All those files recorded as having been replaced in the Rollup's
> install log do seem to have been replaced on the system, either with a
> different later version, or with the same version as before but with a
> different time stamp.
> I have tried un-installing and re-installing the Rollup a few more times for
> good measure. Every time it apparently installs correctly and is recorded
> correctly in the Windows Event Log and appears correctly in the Add/Remove
> program window.
> And still every time I go back to Windows Update (or now Microsoft Update)
> there it is staring me in the face telling me that it needs to be installed
> again!
> I'm running out of ideas now.
If the uninstall isn't creating a consistent baseline and assuming it is in fact
possible to install the Rollup cleanly, the only thing that I can think of is that
there was an inconsistency even in the original state which created the set
of modules for the uninstall but I can't quite imagine what it would be which
would also prevent the Rollup itself from installing cleanly.
> If I can get the install log to you somehow, do you think that it would give
> you the answer? If so, I could e-mail it to you if I could have an address.
> Thanks in anticipation. Dave.
My reply address is a valid webmail address. I don't mind taking a quick
look at it but I still think that getting a detail report out of mbsacli.exe
is the way to go. Notice that you can do two kinds of scans, one which
looks for lack of updates in the registry values. That I think used to be
the only one which MBSA did which made the HfNetChk tool essential.
The other scan is the one which the HfNetChk tool used to do, scan module
versions and compare them with expected versions according to both
the registry information and the mssecure.xml file information.
HTH
Robert
---
Dave Hawley
Could you tell me what command line switch(es) I should run mbsacli.exe with
to get the results that I need to analyse?
I've tried running it without any switches, and it just scans and then gives
me information about installed security updates and other supposed security
vulnerabilities.
Most of this is the same as I get with the GUI version.
It tells me that I have a few inconsequential potential security
vulnerabilities which I know about (e.g. not using NTFS) and it tells me that
all my updates are installed correctly, but I am missing an important
critical Service Pack or Security Rollup.
Guess which one!
I've looked at the possible command line switch options, and I can't see any
which would give me a list the file version or registry entry errors that you
mention.
Thanks, Dave.
Robert Aldwinckle
> Thanks again Robert,
> Could you tell me what command line switch(es) I should run mbsacli.exe with
> to get the results that I need to analyse?
Dave,
It looks as if I may have started a wild goose chase here with faulty
recollection and not staying current. Sorry. I just tried MBSA2.1
and got part of what I thought I was remembering with /hf -v -z MBSA2.0 has dropped any pretense of HFNetChk emulation at
all.
Shavlik seems to have dropped support for their free version too.
Even worse, MBSA2.0 has changed the database into something
completely unrecognizable. The closest that I could get to what
I remember mssecure.xml with its mbsacli was with its /xmlout
pointing /catalog at its wsusscan.cab. However, there was absolutely
no information in there about modules or versions which makes it useless
for our purposes as a diagnostic. OTOH I don't have any problems so
looking optimistically perhaps if there are problems it would tell you
something about them with greater detail. Hopefully someone with
more knowledge about the current state of MBSA technology will
jump in here with a factual comment.
From a brief scan of newsgroup discussion about this,
it looks as if we may have to turn ourselves into scripting experts
before we can take advantage of the new (perhaps equivalent)
support. Also it is unclear whether what Shavlik have left in
their HFNetChk Pro version would be sufficient for what you need.
BTW if you have sent your log to me I haven't seen it yet.
Robert
---
Dave Hawley
I have sent you an e-mail with the logs attatched.
Cheers,
Dave.
Robert Aldwinckle
> Thanks Robert.
> I have sent you an e-mail with the logs attatched.
Dave,
Since the uninstall-reinstall idea didn't work my guess is that there
was something wrong before the Rollup was first installed.
To check that out I tried to look at version information from your first
uninstall. Unfortunately we only get partial details from that log.
E.g. here is a summary of its layout:
1. a bunch of deletes of cached copies of modules.
No problem there I suppose that we don't see any version info.
2. a few deletes of supposedly operational files
3. a bunch of copies of supposedly operational files
but it's not clear what the source is; probably the the backup folder
the spuninst.exe program is being run from:
D:\WIN-NT\$NtUpdateRollupPackUninstall$
<example>
...
13.031: Deleted file: D:\WIN-NT\system32\dllcache\write32.wpc
13.031: Deleted file: D:\WIN-NT\system32\drivers\fltmgr.sys
13.031: Deleted file: D:\WIN-NT\system32\windows media\server\nscm.exe
13.031: Deleted file: D:\WIN-NT\system32\windows media\server\nsiislog.dll
13.031: Deleted file: D:\WIN-NT\system32\windows media\server\nsisapi.exe
13.047: Deleted file: D:\WIN-NT\system32\windows media\server\nspmon.exe
13.141: Copied file: D:\WIN-NT\system32\advapi32.dll
...
</example>
Some of the copies are explicitly "delayed" (i.e., pending reboot)
but there are more which involve .tmp names so I suspect that
some of the other operations which were expected to succeed
(e.g., either as deletions or as copy steps) failed and therefore
were dynamically given the same treatment. Unfortunately there
is no real proof of this. Worse, some of the ones which I suppose
were originally deletions have no more identification when they are
processed after the boot than their version numbers:
<example>
---- PendingFileRenameOperations After Uninstallation ------
70.766:
Source: D:\WIN-NT\system32\_000000_.tmp.dll
Version: 5.0.2195.7038
70.766:
Destination:
Version:
</example>
The copy steps at least are fully identified but as you say there are
a lot of them and there is no easy way of tying them to any particular
manifest to validate their regression. And what if some aren't regressions?
That might be what the installer was getting confused about and in that
case perhaps we could uninstall something, such as one of the updates
which the Rollup was supposed to be supplementing in order for the
Rollup to update to the version that it wants, so then the installer isn't
confused any more. Etc. (Who knows?)
Did you manually enter the spuninst.exe command or was there some
UI which did it for you? If you can enter the command manually there
are apparently some extra switches you could use which would force more
detailed diagnostics (e.g. hopefully some indication of why a copy or
delete is being done as well as more explicitly relating the .tmp files
to the modules being processed and the final version they should have.
In any case the option I think we want is /verbose as described in here:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/deployment/winupdte.mspx
HTH
Robert
---
Dave Hawley
I didn't manually run spuninst.exe to initiate the uninstalls of the Rollup.
I used the entry in "Add/Remove Programs", which I assume does that anyway.
If the uninstall can be run with a "verbose" option, I will try that and see
if it records any information which will give us a clue as to what's actually
happening.
I'll get back to you..........
Cheers, Dave.
>
"Robert Aldwinckle" wrote:
> "Dave Hawley" <DaveH...@discussions.microsoft.com> wrote in message
> news:9581723C-9146-4B40...@microsoft.com...
> > Thanks Robert.
> > I have sent you an e-mail with the logs attatched.
>
> Dave,
>
> Since the uninstall-reinstall idea didn't work my guess is that there
> was something wrong before the Rollup was first installed.
> To check that out I tried to look at version information from your first
> uninstall. Unfortunately we only get partial details from that log.
> E.g. here is a summary of its layout:
>
> 1. a bunch of deletes of cached copies of modules.
> No problem there I suppose that we don't see any version info.
> 2. a few deletes of supposedly operational files
> 3. a bunch of copies of supposedly operational files
> but it's not clear what the source is; probably the the backup folder
> the spuninst.exe program is being run from:
> D:\WIN-NT\$NtUpdateRollupPackUninstall$
>
> <example>
> ....
> 13.031: Deleted file: D:\WIN-NT\system32\dllcache\write32.wpc
> 13.031: Deleted file: D:\WIN-NT\system32\drivers\fltmgr.sys
> 13.031: Deleted file: D:\WIN-NT\system32\windows media\server\nscm.exe
> 13.031: Deleted file: D:\WIN-NT\system32\windows media\server\nsiislog.dll
> 13.031: Deleted file: D:\WIN-NT\system32\windows media\server\nsisapi.exe
> 13.047: Deleted file: D:\WIN-NT\system32\windows media\server\nspmon.exe
> 13.141: Copied file: D:\WIN-NT\system32\advapi32.dll
> ....
Dave Hawley
Well I've done some more tests.
I tried running the un-installer for the Rollup with a /verbose switch, as
you suggested, and all that popped up was a screen telling me what switches I
could use, and that wasn't one of them!
It did give me the option to make a log in a specified location, so I did do
that.
It's only the log it would have made anyway I suspect, but at least it's
separate and not appended to the other instances of the uninstall which make
the log very large.
I then went to Microsoft Update, and was told not surprisingly that I needed
to install the Rollup, plus several other high priority updates which
presumably had been included in the Rollup.
I re-installed just the Rollup.
This time it did download everything again, whereas on other previous
installs, it had said "update is downloaded and ready to install" so
presumably the downloaded files were being cached somewhere.
Anyway, it installed apparently successfully again, and disappeared from the
Automatic Updates taskbar pop-up window, but NOT from the main Microsoft
Update screen, where yet again when I scanned it was saying that the Rollup
needed to be installed!
This was something that maybe I should have mentioned before, as it may be
an important clue. When the Rollup is uninstalled, it then appears in the
Windows Automatic Updates notification pop-up window, as you would expect.
When it is installed, it does disappear from there, but NOT from the main
Windows/Microsoft Update IE page when you do a scan.
Why should it disappear from one and not the other? I always assumed that
they used the same criteria to decide if a critical update was needed or not!
Anyway, I installed the other two Updates which were still reported as
missing.
These were the Cumulative Security Update for Internet Explorer 6 Service
Pack 1 (KB883939), and the 814078: Security Update (Microsoft Jscript version
5.6, Windows 2000, Windows XP).
Why uninstalling the Rollup had broken those updates, and yet reinstalling
it didn't reinstate them again, I have no idea!
I have also e-mailed this to you, and attached the two logs, the most recent
uninstall and the most recent install.
They probably won't tell you anything new, but you never know!
Cheers, and thanks again,
Dave.
Robert Aldwinckle
> Hi Again Robert,
> Well I've done some more tests.
> I tried running the un-installer for the Rollup with a /verbose switch, as
> you suggested, and all that popped up was a screen telling me what switches I
> could use, and that wasn't one of them!
That's disappointing. FWIW here's the document which gave me the idea.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/deployment/winupdte.mspx
Notice that it also mentions "for compatibility with earlier versions
the /v option can be used". Perhaps you could try /v instead?
Also, I notice that there is the potential for a lot more logs than I was aware of.
I knew that the the location of logs and individual names was unpredictable.
That's why I usually suggest just doing a file find of all files which have changed
on the day of the update, sorting them by the Date Modified timestamp
and then scrolling through the particular set of minutes which the update took,
looking for potentially readable files. Drag such files to Notepad to confirm
your guesses.
> It did give me the option to make a log in a specified location, so I did do
> that.
> It's only the log it would have made anyway I suspect, but at least it's
> separate and not appended to the other instances of the uninstall which make
> the log very large.
>
> I then went to Microsoft Update, and was told not surprisingly that I needed
> to install the Rollup, plus several other high priority updates which
> presumably had been included in the Rollup.
>
> I re-installed just the Rollup.
If we can't get a /verbose (or /v from your spuninst.exe)
it might still be useful to get it from the update.exe (e.g. the install).
In fact depending on how the version checking is documented by /verbose
that might even be better than the log from an uninstall.
(I have never seen either; so I'm just hoping there is something
there in either option which makes it worth all this effort.)
Another alternative would be to use filever *.dll on the uninstall directory
after the install. However, I don't know what exactly is kept in there.
If they copy *all* modules which might have been used by the update,
regardless of version, that would be perfect for comparing with what the
update changed or for comparing with other users who have the update
but don't have your problem symptoms. E.g. you could use a for loop
on the module names and get an equivalent listing of the current installed
versions, then do a diff on those two listings to see at a glance what had
or hadn't changed. Etc.
Another option which I have never tried but which others in this newsgroup
have mentioned before is "The Belarc Advisor". Apparently it is freeware
for individual use. Try finding out what kind of report it gives regarding
version changes.
http://www.belarc.com/free_download.html
> This time it did download everything again, whereas on other previous
> installs, it had said "update is downloaded and ready to install" so
> presumably the downloaded files were being cached somewhere.
Yes. The SoftwareDistribution folder gets flushed periodically it seems.
>
> Anyway, it installed apparently successfully again, and disappeared from the
> Automatic Updates taskbar pop-up window, but NOT from the main Microsoft
> Update screen, where yet again when I scanned it was saying that the Rollup
> needed to be installed!
If we could just get a trace of that scan...
>
> This was something that maybe I should have mentioned before, as it may be
> an important clue. When the Rollup is uninstalled, it then appears in the
> Windows Automatic Updates notification pop-up window, as you would expect.
> When it is installed, it does disappear from there, but NOT from the main
> Windows/Microsoft Update IE page when you do a scan.
> Why should it disappear from one and not the other? I always assumed that
> they used the same criteria to decide if a critical update was needed or not!
That is a problem which I used to have the WUv4 and AU.
Sometimes AU would keep offering an update until I either
downloaded it and installed it manually or installed it from WU.
I'd forgotten about that since it hadn't happened with WUv5
or (yet) with WUv6.
>
> Anyway, I installed the other two Updates which were still reported as
> missing.
> These were the Cumulative Security Update for Internet Explorer 6 Service
> Pack 1 (KB883939), and the 814078: Security Update (Microsoft Jscript version
> 5.6, Windows 2000, Windows XP).
> Why uninstalling the Rollup had broken those updates, and yet reinstalling
> it didn't reinstate them again, I have no idea!
Again, I suspect it will depend on what is kept in that uninstall directory
and what regressions are allowed when it is used. So I think that would
explain the first query. As for the second point how many ways have you
tried reinstalling it? E.g. if you are only installing it via AU perhaps a manual
reinstall would work.
Also, is 890859 part of the Rollup? Ramesh *speculatively* pointed
out that there is another install option available which might help force it on:
I'd still like to see exactly what the problem is before suggesting something
to do about it but I thought I should at least point out other possibilities.
>
> I have also e-mailed this to you, and attached the two logs, the most recent
> uninstall and the most recent install.
> They probably won't tell you anything new, but you never know!
You're right. More compact but no more detail than the last ones.
>
> Cheers, and thanks again,
> Dave.
You're welcome.
Good luck
Robert
---
Dave Hawley
>Notice that it also mentions "for compatibility with earlier versions
>the /v option can be used". Perhaps you could try /v instead?
Sadly that doesn't work either!
>Also, I notice that there is the potential for a lot more logs than I was aware of.
>I knew that the the location of logs and individual names was unpredictable.
>That's why I usually suggest just doing a file find of all files which have changed
>on the day of the update, sorting them by the Date Modified timestamp
>and then scrolling through the particular set of minutes which the update took,
>looking for potentially readable files. Drag such files to Notepad to confirm
>your guesses.
Unfortunately I have uninstalled and reinstalled all these updates so many
times,
I can't believe that checking timestamps and making comparisons would really
be
meaningful now.
>Another option which I have never tried but which others in this newsgroup
>have mentioned before is "The Belarc Advisor". Apparently it is freeware
>for individual use. Try finding out what kind of report it gives regarding
>version changes.
I have tried the Belarc Advisor.
It gives a very impressive amount of detail about the whole system.
It also says that all my Microsoft Updates are present and installed
correctly!
It looks therefore as if the only applications which are mis-reporting the
Rollup
as missing are the Baseline Security Analyzer, and Windows/Microsoft Update
itself!
I suspect that is because they both use the same criteria to make their
judgements
on the status of updates, which would make sense as they're both from
Microsoft!
As you say, we need a trace of those scans!
>....how many ways have you tried reinstalling it?
>E.g. if you are only installing it via AU perhaps a manual reinstall would work.
I've installed using every method (some several times!)
Windows Update (v4), Microsoft Update (v6), Automatic Updates, and the
standalone
installer package. Same result every time........
>Also, is 890859 part of the Rollup?
Yes it is.
I will try doing a standalone installation of that update.
If others have had trouble getting it to "stick", well, you never know!
>I'd still like to see exactly what the problem is before suggesting something
>to do about it but I thought I should at least point out other possibilities.
Of course. Thanks for sticking with this Robert. I really appreciate it.
Strange no-one else has come in and said anything, as I know I'm not the
only one
with this issue. No word from any of the MS MVPs either (assuming you're not
one!)
I wonder why..........?
Dave Hawley
I downloaded and installed MBSA version 1.2.1, which is still available.
This scanned and told me that two components of Windows were out of date.
These were MS Data Access Components 2.8, which needed to be upgraded to
SP1, and MSXML 4.0, which needed to be upgraded to SP2.
MBSA 2.0 had not caught this at all!
I installed the updates, and the problem has gone away!
In fact MSXML 4.0 has updated to SP7, which was only issued today.
MBSA 1.2.1 now says that it needs to be SP5, which it says is the latest
version!
Go figure! I guess the database hasn't been updated yet.......
Anyway, at last Microsoft Updates (and MBSA 2.0) no longer tell me that the
Update Rollup needs to be installed all the time!
Finally, after such a long time, it was as simple as that.
I cannot thank Robert Aldwinckle enough for his patience and perseverance in
helping me with this issue. I hope that my experience will help others with
the same problem.
It just shows that using the latest version of a utility isn't always the
best!
Cheers, Dave.
Robert Aldwinckle
...
Hi Dave,
> Well, finally fixed it!
Good news!
> I downloaded and installed MBSA version 1.2.1, which is still available.
> This scanned and told me that two components of Windows were out of date.
> These were MS Data Access Components 2.8, which needed to be upgraded to
> SP1, and MSXML 4.0, which needed to be upgraded to SP2.
> MBSA 2.0 had not caught this at all!
> I installed the updates, and the problem has gone away!
Well done!
Sorry to say I actually considered telling you that there are checkers
available for both those components. I'm really not sure now why
I didn't at least mention it. It wouldn't have been a complete check
for the rollup but evidently it could have shifted focus usefully and reduced
some of the complexity that you were faced with.
>
> In fact MSXML 4.0 has updated to SP7, which was only issued today.
> MBSA 1.2.1 now says that it needs to be SP5, which it says is the latest
> version!
> Go figure! I guess the database hasn't been updated yet.......
>
> Anyway, at last Microsoft Updates (and MBSA 2.0) no longer tell me that the
> Update Rollup needs to be installed all the time!
> Finally, after such a long time, it was as simple as that.
> I cannot thank Robert Aldwinckle enough for his patience and perseverance in
> helping me with this issue. I hope that my experience will help others with
> the same problem.
You're welcome. Happy to help.
BTW your experience may already by helping others.
Notice my reply to Scuzzy today, for example. ;)
Robert
---
sbrobert
I had the exact same problem, with the Update Rollup installing, but not
being recognized as installed by Update.
I downloaded and ran MBSA 1.2.1 and then downloaded and installed each
component. I needed to install the Office Service Pack 3 before some others
would install.
After this, Windows Update no longer says I need any updates! Thanks!
Best wishes,
Robert Bernstein
Santa Barbara, CA