Hi Aaron,
Happy Friday! ïŠ
You are not going to like this….
The reason that the machine that you ran the VAMU re-cache on and you are
finding that the Excel.exe and Winword.exe files are still at higher
versions, is because that machine has it’s own different cached client
patches installed. Specifically two patches that are applied to it are the
Excel and word patches that upgrade them to higher versions..
From the log file from that machine…
Here are the cached client patches.
{66D08203-FB46-4D27-A609-FFE9A77FAA1F} Client Office XP
Hotfix;FP5AUTL.FPCUTL;6747;Optimized;ALL;;
{DA256408-A2E7-41A5-8AD6-62ACB86A0FD7} Admin Office XP
Hotfix;MAINSP3.MSGR2PB.MSSP3KO.OFFFILT.EXCEL.FM20.FP5AUTL.FPCUTL.FRONTPG.GRAPHFLT.GRAPH.MAINSP2.FP5_DLL.MAINSP1.MSACCESS.MSOSTYLE.MSPUB.MSSP3FR.MSSP3GE.MSSP3IT.MSSP3NL.MSSPELL.MSTH3FR.MSTORE.OLKINTL.OUTLOOK.OWC10.POWERPNT.SHARED.WINWORD.EUROTOOL.MSDAIPP.OLAPPT.OUTLCM.OUTLCTL.OUTLMIME.PSTPRX32.PUBINTL.MSONSEXT.MSQRY32.RICHED20.MSCONV.OWSCLT.SHRDINTL.SNAPVIEW.VBE6;6626;FullFile;ENG;;
{BE898464-0D40-4794-AB7D-6AF9DB730211} Client Office XP
Hotfix;WINWORD;6764;FullFile;ALL
{151BDDD6-8453-483C-8864-8BE5459BF4F4} Client Office XP
Hotfix;EXCEL;6832;FullFile;ALL
Notice that the bottom two patches update Winword to 6764 and Excel to 6832
respectively.
Also from the log..
MSI (s) (34
8) [19:45:46:885]: Executing op:
FileCopy(SourceName=EXCEL.EXE,SourceCabKey=EXCEL.EXE,DestName=EXCEL.EXE,Attributes=5633,FileSize=9360728,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=10.0.6832.0,Language=0,InstallMode=96468992,,,,,,,)
MSI (s) (34
8) [19:45:47:026]: File: C:\Program Files\Microsoft
Office\Office10\EXCEL.EXE; Overwrite; Won't patch; REINSTALLMODE specifies
all files to be overwritten
MSI (s) (34
8) [19:45:47:026]: Source for file 'EXCEL.EXE' is compressed
MSI (s) (34
8) [19:45:47:026]: Re-applying security from existing file.
And..
MSI (s) (34
8) [19:45:48:245]: Executing op:
FileCopy(SourceName=WINWORD.EXE,SourceCabKey=WINWORD.EXE,DestName=WINWORD.EXE,Attributes=5633,FileSize=10635976,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=10.0.6764.0,Language=0,InstallMode=96468992,,,,,,,)
MSI (s) (34
8) [19:45:49:136]: File: C:\Program Files\Microsoft
Office\Office10\WINWORD.EXE; Overwrite; Won't patch; REINSTALLMODE specifies
all files to be overwritten
MSI (s) (34
8) [19:45:49:136]: Source for file 'WINWORD.EXE' is compressed
MSI (s) (34
8) [19:45:49:136]: Re-applying security from existing file.
This basically says that is does the file copy of the new excel and winword
files but then “MSI (s) (34
8) [19:45:49:136]: Re-applying security from
existing file†Means that it is re-applying the two cached patches from above
and thus updating them to the newer versions, causing it to be out of sync
with the AIP.
This adds a new wrench to the whole problem. This shows us that this machine
has different cached patches then the one we were originally working on.
{BE898464-0D40-4794-AB7D-6AF9DB730211} Client Office XP
Hotfix;WINWORD;6764;FullFile;ALL
{151BDDD6-8453-483C-8864-8BE5459BF4F4} Client Office XP
Hotfix;EXCEL;6832;FullFile;ALL
If you have other machines that have even more different client patches
installed that we are unaware of then you will experience this issue on them
as well. It would be one thing if all the machines had the same two original
cached patches on them. In that scenario we could just push out the reg
delete commands, blow away those 2 patches on all the boxes and recache to
the new source. But if each box has different and independent patches on them
then we wouldn’t have the ability to know what patches are cached on every
machine unless we queried them all individually and sent out separate reg
delete commands for all the possible cached patches..
With this new information you have new choices.
#1. Rather than send out a command to blow away the references to the cached
patches (which now seems impossible since it appears that they all may have
different cached patches) we could send out a MSIzap command to wipe out all
references to all patches and the office installs and then re-cache to the
new source.
Or
#2. Move to the method previously discussed where the AIP stays at baseline
and all patches are pushed to the clients. If this method is chose then no
further work is needed besides re-caching the new source.
Again I would recommend that this convinces you to move to option 2, as it
is just another example of not having control over the clients. If they don’t
get successfully locked down and clients install random patches then the
issue will start all over again in the future.
Of course the choice is yours. If you want to use MSIzap, let me know and I
will send you instructions on this new method.
--
Eric Palm
MSFT Office Setup
Aaron Wright said:
Good point Eric, I should have thought to try the VAMU.
Good news, it worked for one machine. Bad news, it didn't work on a
second machine I tested it on. I'm going to test it on a few other
machines after I get all those patches applied.
Is it alright if I send you the log from the machine that didn't
change after using VAMU?
Thanks for your help!
OK...
Here is the reason why. It's my fault. I was having you use
msiexec.exe /i Aipshare\filename.msi REINSTALLMODE=VOMU REINSTALL=ALL
The problem is the "O" in the VOMU. The O indicates to replace older files.
We want to replace all files since we are reaching to a brand new AIP.
Please use this command instead.
msiexec.exe /i Aipshare\filename.msi REINSTALLMODE=VAMU REINSTALL=ALL
The "A" in VAMU will force it to replace all files with the new AIP versions
even if they are older versions.
This is documented in the MSDN article..
http://msdn2.microsoft.com/EN-US/library/aa367988.aspx
/f [p|o|e|d|c|a|u|m|s|v] Package|ProductCode Repairs a product.. This option
ignores any property values entered on the command line. The default argument
list for this option is 'omus.' This option shares the same argument list as
the REINSTALLMODE property.
p - Reinstalls only if file is missing.
o - Reinstalls if file is missing or an older version is installed.
e - Reinstalls if file is missing or an equal or older version is installed.
d - Reinstalls if file is missing or a different version is installed.
c - Reinstalls if file is missing or the stored checksum does not match the
calculated value. Only repairs files that have msidbFileAttributesChecksum in
the Attributes column of the File table.
a - Forces all files to be reinstalled.
u - Rewrites all required user-specific registry entries.
m - Rewrites all required computer-specific registry entries.
s - Overwrites all existing shortcuts.
v - Runs from source and re-caches the local package. Do not use the v
reinstall option for the first installation of an application or feature.
To answer your question about whether or not you can tell how the client
patches got installed. No you can't.
--
Eric Palm
MSFT Office Setup
Aaron Wright said:
I created a new AIP, and then I applied SP3 to it. I didn't apply all
the patches since SP3 because there are 36 of them and I don't want to
take the time yet.
I ran another recaching command on a client, but the version numbers
didn't update at all. The new AIP I just created has excel.exe
version 10.0.6501. After running the recaching command the client
still has version 10.0.6832. Same thing with powerpnt.exe,
winword.exe, mso.dll, and so on.
What now? Would you like the log file from the recaching?
No problem! Any comment on the patch detection issue I brought up?
Is there any way to tell how the two patches got deployed to this
client directly? We use a mix of WSUS and SMS, with SMS simply
sending out an msiexec command to sync the clients to the AIP.
MS07-036 is not approved in WSUS, so I'm not sure how the PC got it.
About half of our PCs are having this same problem, but I can't say
with 100% certainty that they're all in a mixed state. But I assume
they are...
I'm going to work on setting up a fresh AIP and apply the patches
again. It will take some time, but I will let you know the outcome.
The post about KB936514 was a misclick... it was ment for someone elses
post... Dont follow those instructions as they are for installing patches
directly on the client and that is not what you want to do.
sorry for the confusion...
Thank you for your reply! I will try what you suggested to solve the
problem. Though I don't understand how it will change anything. If I
create a new AIP and get it patched with SP3 and up-to-date as of
MS07-036 then it should be exactly the same as the current AIP I have
set up. How is recaching the client to that new AIP going to get me
any different results from recaching it to my current one?
Regardless, I know enough to know how little I know, so I will try
this and let you know the results.
I will also try what you suggested in your last post regarding
KB936514. I will post the results here when I finish.
Last, I'd like your opinion/input on something, and your reply may
benefit others watching this list/post as well. I'm referencing the
information in the 3 links I've pasted below. Basically, MBSA 2.0/
WSUS/SMS w/ ITMU don't support the detection of applicable security
updates for Office products installed via an AIP. In the back of my
mind I'm hoping you'll tell me there is some kind of work-around for
this. But Doug Neal said in his post "AIP installations will not be
supported going forward..." I'm not sure when this policy change
started, but I deployed our company's office installations via AIP
because it was a method recommended in Office Resource Kit book. Now
I'm stuck with no way to detect applicable security updates unless I
convert my clients to OBS and patch manually, which is quite a lot of
effort to go through and I haven't had time for. What are your
thoughts and comments on this?
Thanks again!
Aaron
http://groups.google.com/group/microsoft.public.softwareupdatesvcs/br....
(Doug Neal's response)
Please manually download one of the problem patches to your machine.. Lets try
KB936514 for example.
Extract the contents of KB936514 out of the exe using winzip.
You will have many text files and a file named xlconv.msp.
For ease of this conversation place xlconv.msp in the root of c:\
Then open a command prompt window and use this command..
msiexec /p c:\xlconv.msp /l*v c:\Update.txt /qn
After it fails you will have a log file in the root of c:\ named update.txt.
Please paste the contents on the forum so we can tell you why it failed.
I don't think those errors are relevent.. if you captured a verbose log
could you please paste the entire contents here?
I have a script that I can run on the file that will tell me where it thinks
it got all of its patches from.
That's so much for your reply! Sorry I didn't check back sooner.
Yes, if you wouldn't mind verifing that these machines are in a mixed
state, I would appreciate it. What information do you need from me to
do this?
I've been troubleshooting the problem the last few days. I turned on
verbose logging, and I'm seeing a lot of error similar to the ones
below. I did some searching around and these are possibly caused by
different language versions? But I'm not sure how this could be,
we've always been English only.
DEBUG: Error 2746: Transform 1TTo1U invalid for package C:\WINDOWS
\Installer\176d92b.msi. Expected product
{90150804-6000-11D3-8CFE-0050048383C9}, found product
{90110409-6000-11D3-8CFE-0050048383C9}.
DEBUG: Error 2746: Transform 2TTo2U invalid for package C:\WINDOWS
\Installer\176d92b.msi. Expected product
{90150405-6000-11D3-8CFE-0050048383C9}, found product
{90110409-6000-11D3-8CFE-0050048383C9}.
DEBUG: Error 2746: Transform 3TTo3U invalid for package C:\WINDOWS
\Installer\176d92b.msi. Expected product
{90150406-6000-11D3-8CFE-0050048383C9}, found product
{90110409-6000-11D3-8CFE-0050048383C9}.
Yes...
More than likely the reason this is happening is because your install is in
a "mixed state".
I am assuming that you have applied most of your patches, or even all of
your office patches to the AIP and then have run the re-cache command to
update the clients.
I would bet that at some point one or more patches were either pushed to the
client machines or they have been installed directly on the clients.
This is a classic example of what we call a "mixed state".. Patches have been
installed on the machine locally, and also have been installed on the AIP and
re-cached to the client machines.
If the installation is in a "mixed state" the symptom that you usually see
is that you will try to apply an update and it says the update was
successful, but if you try to validate file versions/size etc from what the
KB says it should be it will not be correct.
This is discussed in the Office Xp whitepaper.
http://support.microsoft.com/kb/330043
Here is a snippet..
Microsoft strongly recommends that you do not mix admin and client updates.
Instead:
7 Apply admin updates to admin installation points and then
perform
...
read more ;- Hide quoted text -
- Show quoted text -
