MU vs WU - Audit your machines
Gerry Hickman
As you probably know the Windows Update Agent can use at least three
different patch detection services
WSUS.CAB - so called "off line" scan
WU - Windows Update for o/s patches
MU - Microsoft Update Service for Office and other application patches
There is also a Windows Service called "Automatic Updates" which will
download and install the security patches, hotfixes, and so-called "critical
updates" found to be missing.
In theory, a newly built Win2k/XP computer with WUA 2.0 will only be
registered with WU and therefore would only report and/or update the o/s
patches. If you wanted to register this computer with MU, the official line
from Lawrence Garvin (MVP) is that you'd have to visit the Microsoft Update
web site and agree to some legal mumbo-jumbo. We assume this means using
Microsoft's proprietary browser with ActiveX enabled and having Admin
rights?
However, when I did an audit of my network I found that 90% of the machines
were already registered with MU even though no interactive user has ever
logged in and visited the Microsoft Update site or agreed to anything!
I thought maybe it's my own network, (some SpyWare changed my settings?), so
I went to the office block over the road and tested theirs - same result,
nearly all machines are registered for MU!
I'd like to find out what is causing this change in registration. At first I
thought it was MBSA 2.0 and it certainly has the capability to make this
change, but running some quick tests indicates it leaves the machines in the
state it found them. Maybe some other patch or update from Microsoft is
making this change?
Anyway if you run a big network and want to check your machine's WU vs MU
registration I have prepared a script to do this. You must use CSCRIPT to
run it like this
cscript wuaservice.js
You need a network with properly configured DCOM, WUA 2.0 Agent on all
machines, and you need to be a Domain Admin to run it as below, but it's
easy to adjust it for other scenarios. To run against hundreds of machines,
just use a loop to insert all the computer names for strCmp e.g. from Active
Directory.
// wuaservice.js
// Audit machines for WU vs MU registration
var strCmp = "WS665";
var oUpdateServiceManager = new
ActiveXObject("Microsoft.Update.ServiceManager", strCmp);
var cServices = oUpdateServiceManager.Services;
var e = new Enumerator(cServices);
for(; !e.atEnd(); e.moveNext()) {
var oService = e.item();
var bIsRegisteredWithAU = oService.IsRegisteredWithAU;
var strMsg = oService.ServiceID + " : ";
strMsg += oService.Name + " : ";
strMsg += bIsRegisteredWithAU.toString();
WScript.Echo(strMsg);
}
It will list the "update" services on your machine and say true or false to
show if they are registered for Automatic Updates. I've tested it on Win2k
and XPSP2.
--
Gerry Hickman - (London UK)
sanskrit
I've read on MSFN about integrating Microsoft Update into my XP
Professional install CD.
Though, maybe you, like a lot of people, use Norton Ghost instead?
Gerry Hickman
> What are you doing to handle new deployments? I haven't tried out what
> I've read on MSFN about integrating Microsoft Update into my XP
> Professional install CD.
You mean this thread:
http://www.msfn.org/board/lofiversion/index.php/t50194.html
I see those guys like to over-complicate everything. Surely the goal is to
avoid ActiveX and legal mumbo-jumbo alltogether? Anyway I'll try to answer
some of what you asked in this thread and also the new thread you started on
softwareupdatesvcs.
1. New deployments - this is how I noticed something was wrong in the first
place - I'm finding new deployments (with WUA 2.0) are only registered with
Windows Update. Older machines have been registered with MU but certainly
not by users visiting the site with IE and accepting an ActiveX control. How
did they end up registered with MU - I don't know but see #2.
2. The thread above cites two important considerations a) MU does not work
properly with Administrative MSI installs of Office 2003 as used in large
corporations. In my view this means it's not fit for purpose, BUT ... b) The
thread says MU is going to be forced on everyone anyway as part of IE7. So
if this is true, there's not much point trying to use Windows Update. It's
also possible the "forced upgrade" has already started and this is why I'm
finding 90% of machines registered with MU even though they never actually
went to the site via IE and accepted an ActiveX control.
So it's a case of deciding what you want. In terms of slip-streaming it's
probably not possible right now (unless you rum a command as part of the
install process), but with IE7 it may be forced as soon as you slipstream
IE7 - so that solves that? For other scenarios I guess the best option would
be to run a script after installing WUA, that tells it to install and
register your desired service. Trouble is, if stuff is changing stuff at
random (which it is at the moment) you'd need to audit machines on a regular
basis.
In summary:
It's another ill-conceived and badly documented part of Microsoft's
so-called security "strategy" who's roots were obviously being thoiught of
in terms of users on stand-alone computers logged in with Admin rights using
proprietary ActiveX via an interative browsing session in a flawed browser
that's part of the underlying o/s! It's no wonder there are so many security
flaws, this so-called "strategy" breaks every rule of best practice in the
book and it's all still there in Vista - unbelievable!
> Though, maybe you, like a lot of people, use Norton Ghost instead?
No, I don't use Ghost, but it can be a good choice.
Lawrence Garvin (MVP)
news:e9PCr50y...@TK2MSFTNGP04.phx.gbl...
> a) MU does not work
> properly with Administrative MSI installs of Office 2003 as used in large
> corporations. In my view this means it's not fit for purpose
This is actually an issue and limitation of the Windows Update Agent, not
Microsoft Update, and it is being actively worked for resolution.
--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
....
Lawrence Garvin (MVP)
news:e9PCr50y...@TK2MSFTNGP04.phx.gbl...
> b) The thread says MU is going to be forced on everyone anyway as part of
> IE7.
The points being:
(a) Windows Update is deprecated, and will be retired at some point in
the future, and
(b) Most likely users of IE7 will be automatically directed to MU, as a
result of the coding of the 'link' in IE7 (but I've not personally tested
this, so I may be mistaken on my presumption wrt this point).
Doug Neal [MSFT]
MVPs provide every time they post to newsgroups.
I want to clarify the issue of Office installations performed from
Administrative Installation Points (AIPs). Microsoft Update technologies -
which include WSUS Server, MBSA 2.0, SMS w/ITMU - do not support detection
and deployment to AIPs. This isn't a problem that will be resolved since
this is a design and support decision made by the Office team.
You can obtain additional information on this point from KB 903773, which
describes that detection support is no longer provided for AIP
installations. You may also want to review KB 902349, which provides
guidance on how customers should update their Office AIP installations to
standard installations that can be supported by WSUS/MU detection instead.
AIP installations will not be supported going forward, and we encourage all
customers to update their AIP installations per the guidance in KB 902349.
I understand this may not be what valued customers may want to hear, but I
would rather provide the facts to help customers best decide how to manage
Microsoft products in their environments.
I hope that helps...
--
Doug Neal [MSFT]
du...@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.
If newsgroup discussion with experts and MVPs is unable to solve a problem
to your satisfaction, feel free to contact PSS for support on the Microsoft
Baseline
Security Analyzer (MBSA). Information is available at the following link:
http://support.microsoft.com/default.aspx
This e-mail address does not receive e-mail, but is used for newsgroup
postings only.
"Lawrence Garvin (MVP)" <onsi...@news.postalias> wrote in message
news:eqYE1e7y...@TK2MSFTNGP06.phx.gbl...
Gerry Hickman
> > a) MU does not work
> > properly with Administrative MSI installs of Office 2003 as used in
large
> > corporations. In my view this means it's not fit for purpose
>
> This is actually an issue and limitation of the Windows Update Agent, not
> Microsoft Update, and it is being actively worked for resolution.
Thanks for the help, but I'm beginning to wonder where you get your
information? First you said the /ONLY/ way to install and enable MU on a
Windows machine was to "visit" the Microsoft Update website and "opt in" to
some legal nonsense, now you are saying the issue with Office Administrative
installations is a "limitation" of the "Agent"?
What exact limitation do you refer to within the Agent, who told you it was
"limited", and who told you it was being "actively" worked for resolution?
I don't see why scanning Office should be any different to scanning anything
else, however the lack of ability to scan the AIP raises other issues of how
accurate and reliable the detection technology in WU and MU actually is? If
they are detecting what they think are installed patches according to the
MSI database (or looking at the registry) this is COMPLETELY flawed, because
we all know the only reliable way to scan a machine is to check the file
manifest itself (as done by Shavlik for all products and done by MBSA 1.2.1
for o/s only)
MBSA 1.2.1 used the Office detection tool (Office Inventory tool) whereas
MBSA 2.0, MU and WU use the Windows "Catalog".
Doug Neal [MSFT]
Perhaps this may help explain part of the issue: WSUS technologies (which
are consumed by WU, MU, WSUS Server, SMS w/ITMU, and MBSA 2.0) are a
combination of detection and deployment technologies that are inseparable.
That means that once a WSUS-based technology determines the need for a
patch, it triggers the deployment of a single, specific patch for that
machine with the problem.
Since detection and deployment are tied together, the logic used to
determine whether a patch is needed also includes the download link and
package name for the patch specific to the affected platform, component or
product. Even though a vulnerability can be accurately detected on an AIP
client, there's no way to apply the appropriate client patch to an
installation that originated from a server-based AIP. The problem now
becomes the MSI update and repair functionality.
Even if detection is accurate, by applying a client-side MSI patch, the MSI
repair/update functionality would be frustrated by forcing a client-side
patch for a server-installed MSI product (Office, in this case) with GUIDs
and pointers to the AIP.
In fact, we're updating the title of KB 903773
(http://support.microsoft.com/kb/903773/) to correctly indicate that Office
Updates actually *will* display in SMS and MBSA, but that applying the
associated patch will not resolve the issue (the patch will continue to
report as needed).
I hope that helps describe the complexities and issues inherent in applying
client-side patches to AIP installations - which may have contributed to the
Office team's decision to discourage customers from deploying AIP installs
and migrate existing AIPs to non-AIPs.
I hope that helps...
--
Doug Neal [MSFT]
du...@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.
If newsgroup discussion with experts and MVPs is unable to solve a problem
to your satisfaction, feel free to contact PSS for support on the Microsoft
Baseline
Security Analyzer (MBSA). Information is available at the following link:
http://support.microsoft.com/default.aspx
This e-mail address does not receive e-mail, but is used for newsgroup
postings only.
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:uErH4wA...@TK2MSFTNGP05.phx.gbl...
Lawrence Garvin (MVP)
microsoft.public.windows.server.update_services, because the /WSUS/
administrators are the people who need to hear this message the most, aside
from the SUS and MBSA people, who have seen the whole thread 'til now.
"Doug Neal [MSFT]" <du...@online.microsoft.com> wrote in message
news:uik8LZ9y...@TK2MSFTNGP04.phx.gbl...
> I want to clarify the issue of Office installations performed from
> Administrative Installation Points (AIPs). Microsoft Update
> technologies - which include WSUS Server, MBSA 2.0, SMS w/ITMU - do not
> support detection and deployment to AIPs. This isn't a problem that will
> be resolved since this is a design and support decision made by the Office
> team.
Thank you, Doug, for this update, and clarification.
I must have been asleep at the wheel when MVPs were told that this issue
would never be resolved. I'll be sure to spread the word as this issue
continues to recur throughout eternity.
> You can obtain additional information on this point from KB 903773, which
> describes that detection support is no longer provided for AIP
> installations. You may also want to review KB 902349, which provides
> guidance on how customers should update their Office AIP installations to
> standard installations that can be supported by WSUS/MU detection instead.
>
> AIP installations will not be supported going forward, and we encourage
> all customers to update their AIP installations per the guidance in KB
> 902349.
>
> I understand this may not be what valued customers may want to hear, but I
> would rather provide the facts to help customers best decide how to manage
> Microsoft products in their environments.
I think you can count on this very feedback occuring.
The Office Team has a vested interest in spreading the use of AIPs in
Enterprise organizations, and to deny those Office Enterprise users the very
thing that WSUS is designed to enhance in the Microsoft arena (updating
/applications/ -- specifically Microsoft Office) will, no doubt, be met with
notable amounts of disappointment. In fact, one can historically measure the
dissatisfaction with the problems caused by those who attempted to use WSUS
with /patched/ AIPs.
The statement that AIPs will be totally unsupported in the WSUS/WUA
environment is even more challenging than merely not supporting /patched/
AIPs.
At least we can point the finger of disappointment at the /OFFICE/ team, and
not at the WSUS team. :-)
Lawrence Garvin (MVP)
> Thanks for the help, but I'm beginning to wonder where you get your
> information?
For the most part, I get my information right from the horse's mouth -- the
people who work on the development and support teams for MU, WSUS, and the
WUA. A secondary, but major, source is real-world information posted here by
people who encounter, and solve, real-world problems affecting WSUS and the
WUA.
> First you said the /ONLY/ way to install and enable MU on a
> Windows machine was to "visit" the Microsoft Update website and "opt in"
> to
> some legal nonsense, now you are saying the issue with Office
> Administrative
> installations is a "limitation" of the "Agent"?
Yeah... IT IS. Both statements are 100% true.
The point to understand is that ALL of the intelligence that affects the
detection, download, and installation of updates is performed by the Windows
Update Agent. Microsoft Update and Windows Server Update Services are merely
data and approvals repositories that are queried by the Windows Update
Agent. In the case of MU, all updates are permanently approved for the WUA.
In the case of WSUS, updates are approved on a case-by-case basis by the
WSUS Administrator. But ALL decision and actions are initiated and performed
by the Windows Update Agent.
> What exact limitation do you refer to within the Agent,
The "limitation" is that the WUA cannot accurately determine the need for an
Office Update when the Administrative Installation Point (AIP) contains
slipstreamed patches (or custom MSP transformations, as well). As is well
documented at http://www.wsuswiki.com/OfficeAIPs, the WUA can only
accurately detect the need to install an Office Update if the AIP contains
the RTM bits of Office XP or Office 2003.
> who told you it was "limited",
Uh.... fifteen months of real-world experiences posted to /this/
newsgroup???
Uh... http://www.wsuswiki.com/OfficeAIPs <???>
> and who told you it was being "actively" worked for resolution?
Well, the last any of us were informed of anything regarding this issue,
prior to Doug Neal's post last night was that it was being investigated.
I now know differently. It will /never/ be fixed.
> I don't see why scanning Office should be any different to scanning
> anything
> else,
I don't either, but apparently you need to take that complaint up with the
Office System Engineering team.
> however the lack of ability to scan the AIP raises other issues of how
> accurate and reliable the detection technology in WU and MU actually is?
Outside of this specific issue with /patched/ Office AIPs, the detection
technology in the Windows Update Agent (WUA), and its predecessor the AU 2.2
client, is well proven, and not in question at all -- except perhaps in your
mind. I'll do what I can to assuage your concerns in this area.
> If they are detecting what they think are installed patches according to
> the
> MSI database (or looking at the registry) this is COMPLETELY flawed,
Yet, that's exactly what they are NOT doing. What the WUA does is simply NOT
detect a NEEDED patch if the AIP contains any patches at all.
If the AIP is totally virgin RTM code, then the WUA will accurately detect
Office updates all day long.
> because we all know the only reliable way to scan a machine is to check
> the file
> manifest itself (as done by Shavlik for all products and done by MBSA
> 1.2.1
> for o/s only)
Your opinion is noted.
Question: Have you tested and observed what the WUA does if you overwrite
any ONE file of an update package installed on a client system?
Lawrence Garvin (MVP)
> Even though a vulnerability can be accurately detected on an AIP client,
> there's no way to apply the appropriate client patch to an installation
> that originated from a server-based AIP.
Doug.. empirical evidence bears the inaccuracy of this statement.
(a) The WUA does NOT detect the requirement to apply an update approved on a
WSUS server if the Office installation was performed from a /patched/ AIP.
(b) The WUA DOES detect the requirment to apply an update approved on a WSUS
server if the Office installation was performed from an /unpatched/ AIP.
These two facts are well documented. So, based on our real-world discussions
in this newsgroup:
A vulnerability CANNOT always be accurately detected on an AIP client.
There IS a way to apply the appropriate client patch to an installation that
originated from a server-based AIP, /IF/ the server-based AIP contains RTM
bits only.
See http://www.wsuswiki.com/OfficeAIPs for additional information.
Jason Gurtz
was planning on moving that direction here--given the past success!--but
I think I'll be reconsidering now. :)
I must add that given the environment we deal with today a conscious
decision to not support automatic updating of a certain install scenario
of office is perplexing to an enigmatic degree. Given this issue, I
sincerely hope they removed all support for AIPs in the office 2K7
product. If not, you can can bet office will be a product the black
hats will look at very closely since they'll know it will be less up to
date than others.
Just wait 'till this hits digg. ;)
~Jason
--
Dave Mills
apply the patches via WSUS anyway. I have a major issue with Office not being
able to be patched via WSUS from UNPATCHED AIP as well. This means I cannot
deploy Office via GPO and provide the License Key and other choices and still
automatically apply the patches.
If I am understanding this correctly then the Office team is saying those that
want to automate the installation of Office cannot also automate the patching of
office via WSUS.
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Gerry Hickman
Your post is very helpful, comments in-line.
> Perhaps this may help explain part of the issue: WSUS technologies (which
> are consumed by WU, MU, WSUS Server, SMS w/ITMU, and MBSA 2.0) are a
> combination of detection and deployment technologies that are inseparable.
I kow what you mean, but the searching, downloading and installation
interfaces provided by WUA, MU and WU can be called separately. This is how
MBSA 2.0 works - it's able to scan without actually downloading or
installing anything.
> Since detection and deployment are tied together, the logic used to
> determine whether a patch is needed also includes the download link and
> package name for the patch specific to the affected platform, component or
> product.
That's fine, let's say your client box has an Office 2003 AIP and is missing
patch MS06-048, the scanning and detection engine can note it as missing and
post a link to the patch, it doesn't have to actually install it. It can
post a warning if it wants to. This would work especailly well in MBSA where
you're using it as a scanning tool. If I remember correctly, MBSA 1.2.1
already had this capability with items in the XML marked as AdminInstall?
Shavlik also has this.
> Even though a vulnerability can be accurately detected on an AIP
> client, there's no way to apply the appropriate client patch to an
> installation that originated from a server-based AIP.
That's right, we don't want it to try and apply a client patch to an AIP!
> Even if detection is accurate, by applying a client-side MSI patch, the
MSI
> repair/update functionality would be frustrated by forcing a client-side
> patch for a server-installed MSI product (Office, in this case) with GUIDs
> and pointers to the AIP.
Yes, that would be very bad. There's confusion in other posts in this thread
and the KB articles you posted earlier. I am not suggesting that WU and MU
should start installing client patches to an AIP! That's crazy. People need
to decide whether they're using API deployment or client deployment using
LIS and OSE. Some users may decide to "revert" their installations and
switch to client patches, but that doesn't mean it's the correct strategy.
The KB articles are misleading in this context. Let's look at each
component:
1. Office 2003 - works perfectly for AIP deployment. The Office team have
done an excellent job authoring the MSI files and patches.
2. The AIP strategy - works perfectly. The MSI team have done an excellent
job making fast and efficient interfaces to deploy large complex
applications across the enterprise and manage the states of features and
components.
3. WUA, MU, MBSA and WU - do not work properly with AIP installations.
> I hope that helps describe the complexities and issues inherent in
applying
> client-side patches to AIP installations
But no one "in their right mind" would apply a client-side patch to an AIP!
> - which may have contributed to the
> Office team's decision to discourage customers from deploying AIP installs
> and migrate existing AIPs to non-AIPs.
The only KB articles I've seen about this relate to limitations of WU and
MU, can you point me to any article from the Office team that "discourages"
customers from deploying AIP installs? LIS and OSE are both flawed and LIS
is very inefficient. There's also the problem of leaving unpatched binaries
in the CAB files and this is a SECURITY risk! The AIP fixes this.
Anyway let's forget the deployment part for a minute. The scanning part
should be fixed so as not to show patches as "missing" on a fully patched
AIP (you already said this is possible). That would fix MBSA 2.0 and
scanning with WU and MU making these technologies again useful on big
networks. Fixing the deployment side is easy too, we'd just need to agree on
the details.
None of this would affect home users because they'd be installing from CDs
etc.
Gerry Hickman
> The "limitation" is that the WUA cannot accurately determine the need for
an
> Office Update when the Administrative Installation Point (AIP) contains
> slipstreamed patches (or custom MSP transformations, as well). As is well
> documented at http://www.wsuswiki.com/OfficeAIPs,
Are you sure the article has not been superseded?
This article describes the exact opposite of the problem I'm seeing and it's
a year old! It states
"No Microsoft Office updates are displayed"
whereas I'm seeing lots of updates displayed, even though they're already
installed! The article is more focused on WSUS detection, but does mention
Micorosft Update not being able to "update" such an installation. It doesn't
actually say Microsoft Update will not list a bunch of missing patches. Two
different things...
What I'm seeing is this;
If I deploy Office 2003 SP2 plus all post-SP2 patches from an AIP to a
client machine, MBSA 2.0 and Microsoft Update will list all post SP2 patches
as "missing".
Lawrence Garvin (MVP)
> Hi Lawrence,
>
>> The "limitation" is that the WUA cannot accurately determine the need for
> an
>> Office Update when the Administrative Installation Point (AIP) contains
>> slipstreamed patches (or custom MSP transformations, as well). As is well
>> documented at http://www.wsuswiki.com/OfficeAIPs,
>
> Are you sure the article has not been superseded?
No, I'm not.
But consider this: There's only two places in the entire WSUS/WUA
architecture where an impact can be made on how the WUA detects the need for
an update. The first is the WUA itself. The only update to the WUA is the
update distributed via selfupdate of WSUS SP1. There's no documented changes
in the WUA concerning Office AIP detections in that WUA client. The other
place an impact can be made is in the metadata of the update, where
update-specific "detection logic" is contained. That would be a function of
changes implemented by the product team (Office SE) in this case.
> This article describes the exact opposite of the problem I'm seeing and
> it's
> a year old! It states
>
> "No Microsoft Office updates are displayed"
When a /PATCHED/ AIP is being used.... Yes.
> whereas I'm seeing lots of updates displayed, even though they're already
> installed!
Yes.. in fact, the behavior is unpredictable when a patched AIP is used,
because the detection engine is unable to accurately determine the status of
the client installation. It can also be affected by the patch level of the
AIP at the time the client was installed.
Bottom line, the WUA cannot be reliably used to update Office installations
using a patched AIP from WSUS or Microsoft Update. Those installations need
to either continue patching the AIP, or use Office Updates. The Office
Update site has it's own ActiveX detection control.
> The article is more focused on WSUS detection, but does mention
> Micorosft Update not being able to "update" such an installation.
I'm going to say this again.. hopefully very loudly and strongly, this time.
<g>
It does not matter what the /source/ of the updates are. ALL DETECTION is
performed by the "Windows Update Agent". The only thing the /source/
provides is the list of possible updates to be applied. In the case of
Microsoft Update, the list of possible updates is ALL updates. In the case
of WSUS, the list of possible updates is those specifically sychronized and
approved for detection at the WSUS server. It is the WUA that determined IF
an update is "Needed", "Installed", or "Not Needed". The WUA that installs
with WSUS v2 / WU / MU cannot accurately determine this information when a
patched AIP has been used to install Office on a client system.
> It doesn't
> actually say Microsoft Update will not list a bunch of missing patches.
> Two
> different things...
What is listed on the web page of Microsoft Update is directly determined by
the processing logic applied by the Windows Update Agent, and is based on
what the WUA determined is "Needed" for that system.
> If I deploy Office 2003 SP2 plus all post-SP2 patches from an AIP to a
> client machine, MBSA 2.0 and Microsoft Update will list all post SP2
> patches
> as "missing".
Not surprised at all. The WUA has no way to determine that those updates
have been installed on the client system, thus it reports them
(inaccurately) as 'missing'.
Here's an experiment for you to try:
Deploy Office 2003 SP1 from an AIP. Install a client. Perform a
detection.
Then apply SP2 to the AIP. Refresh the client. Perform a detection.
Gerry Hickman
The article you cited does not actually say there's a "limitation" in WUA.
If you look at the "cause" section, it doesn't actually give a cause, it
just tells us what we already knew - that the combination of technologies
don't work properly together.
You seem to have decided the fault must be in WUA as opposed to the data
held in MU or WSUS. You also said in an earlier post that the MSI database
and registry are NOT used when scanning for Office updates. So what is used,
and how does this limitation prevent accurate detection?
I'd like to see the detection data for Office 2003 so I can understand why
it's giving incorrect results - is this possible?
--
Gerry Hickman - (London UK)
"Lawrence Garvin (MVP)" <onsi...@news.postalias> wrote in message
news:uB7DMNC0...@TK2MSFTNGP04.phx.gbl...
Lawrence Garvin (MVP)
> Hi Lawrence,
>
> The article you cited does not actually say there's a "limitation" in WUA.
Ja ja ja...... do you want to argue the content of the article. or do you
want to discuss reality.
It really doesn't matter a bit what the article says, the FACT is that you
CANNOT update an Office installation that has been installed from a PATCHED
AIP, and that's never going to change, according to the word from the Office
team.
> If you look at the "cause" section, it doesn't actually give a cause, it
> just tells us what we already knew - that the combination of technologies
> don't work properly together.
Without trying to be snide, or arrogant.. consider the possibility that I
have conversations with the WSUS team and have information that's not
"published" on a non-Microsoft site. Consider the possibility that after
twenty months I've read and seen lots of behavioral scenarios that are not
'documented' anywhere outside of this newsgroup. Consider the possibility
that the purpose of the article on the WSUS Wiki was designed to be
prescriptive in nature, not an in-depth explanation of WHY.
> You seem to have decided the fault must be in WUA as opposed to the data
> held in MU or WSUS.
If the problem were in the /WSUS/ metadata, or in the MU catalog, then the
problem would only exist on ONE or the OTHER system. Furthermore, if the
problem were in the metadata or the catalog, it would be easily fixable..
and would not likely exist in ALL updates.
When a problem exists in ALL SYSTEMS --- WSUS, MU, and MBSA.. the ONLY
common factor is the Windows Update Agent.
> You also said in an earlier post that the MSI database
> and registry are NOT used when scanning for Office updates.
Would you please cite that statement back to me? I don't recall making any
statements concerning the MSI database and/or registry in any discussion.
> So what is used,
> and how does this limitation prevent accurate detection?
Does it really matter? It doesn't work and it's not going to work -- EVER --
according to the information we've now been provided.
Gerry Hickman
>> You also said in an earlier post that the MSI database
>> and registry are NOT used when scanning for Office updates.
>
> Would you please cite that statement back to me? I don't recall making any
> statements concerning the MSI database and/or registry in any discussion.
Here's the exact text from two days ago. The first bit is what I said,
the second bit is what you said.
> If they are detecting what they think are installed patches according to
> > the
> > MSI database (or looking at the registry) this is COMPLETELY flawed,
Yet, that's exactly what they are NOT doing. What the WUA does is simply
NOT
detect a NEEDED patch if the AIP contains any patches at all.
--
Gerry Hickman (London UK)
Lawrence Garvin (MVP)
Ahah.... I think the flaw is in your reading of my statement.
I did not, in fact, state anything about HOW the WUA detected whether an
update is needed or not, including what sources it may or may not use in
performing such detections.
What I DID say was that "The WUA does not detect a needed patch when the AIP
has been patched." There's nothing in that statement that says, infers,
suggests, insinuates, or even gives a hint of HOW the WUA does or does not
do what it does or does not do.
--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
....
>
>