Re: Office Installation Not Syncing to AIP

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Eric,

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.security.baseline_analyzer/browse_thread/thread/e4728093a7f2d0ed/82647449e48f31a1?lnk=st&q=&rnum=11#82647449e48f31a1

http://groups.google.com/group/microsoft.public.softwareupdatesvcs/browse_thread/thread/8b6404d2830377a2/
(Doug Neal's response)

http://support.microsoft.com/kb/903773


On Jul 30, 9:32 am, Eric A. <Er...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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.

--
Eric Palm
MSFT Office Setup



"Eric A." wrote:
Hi Aaron...

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.

Thanks
--
Eric Palm
MSFT Office Setup

"Aaron Wright" wrote:

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}.

Thanks again!
Aaron

On Jul 24, 2:52 pm, Eric A. <Er...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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 the necessary steps to update the clients (see the "The SP-1, SP-2,
and SP3 Administrative Updates" section later in this white paper for more
information). If the admin point has been updated, do not install client
updates on the client computer.
-or-
7 Use client updates to upgrade the client computer (see the
"The SP-1, SP-2, and SP3 Client Updates" section for more information) and do
not update the source admin installation point with admin updates.
Many issues may occur if you mix admin and client updates. The following
list describes the two most common issues.
7 When you install a client update, you receive the following
error message:
Error 1328. Error applying patch to file file name.
It has probably been updated by other means,
and can no longer be modified by this update.
For more information contact your update vendor.
This issue occurs when the binary client update tries to update a file that
is at a different binary structure than the binary diff requires. If the
admin installation point has been updated with an admin update, the update
updates the same file that the client update is trying to update, and the
build of the file on the client computer has also been updated (possibly by
another client update or from an updated admin point), the 1328 error may
occur. When the installer accesses the admin point to try to obtain the
original file, the file it obtains from the source is also at a different
binary structure than the binary diff requires. Because the installer cannot
obtain the necessary file, it generates the 1328 error message.
After you perform a reinstall/recache from an updated admin installation
point, the files on the client computer are not updated. This may occur if
there is a client update on the computer that overwrites the information in
the updated installer database from the admin point. Client update transforms
are dynamically applied to the cached installer database, and these upgrades
take precedence over updates that were made directly to the installer
database.

I can validate for you whether or not the machine is in a mixed state.
If you want me to do that for you, let me know.

--
Eric Palm
MSFT Office Setup

"Aaron Wright" wrote:
Update, I checked the version of Windows Installer on the computer.
It is the most recent version. msi.dll = 3.1.4000.4039

On Jul 19, 4:41 pm, Aaron Wright <wright...@xxxxxxxxx> wrote:
Hello Everyone,

I have an administrative installation point (AIP) of Office XP and
2003 on one of our servers. To patch our client PCs I run the
following on each: msiexec.exe /i \\LocalAIPServer\OfficeXP\pro.msi
REINSTALL=ALL REINSTALLMODE=vomu /q

This had worked in the past, but has recently stopped working, and I
don't know why. For example, Word XP. I checked winword.exe on the
AIP, and it has the version 10.0.6829.0. I ran the above command
manually on a client PC, but after it finished the version of
winword.exe on the client PC was still 10.0.6826.0

I'm not sure what the problem is. Does anyone have any ideas?

Thanks for your help!
Aaron- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -


.

Relevant Pages

  • Re: Office Installation Not Syncing to AIP
    ... I created a new AIP, and then I applied SP3 to it. ... I ran another recaching command on a client, ... Is there any way to tell how the two patches got deployed to this ... When the installer accesses the admin point to try to obtain the ...
    (microsoft.public.officeupdate)
  • Re: Office Installation Not Syncing to AIP
    ... Please manually download one of the problem patches to your machine. ... client machines or they have been installed directly on the clients. ... Microsoft strongly recommends that you do not mix admin and client updates. ... When the installer accesses the admin point to try to obtain the ...
    (microsoft.public.officeupdate)
  • Re: Office Installation Not Syncing to AIP
    ... client machines or they have been installed directly on the clients. ... This is a classic example of what we call a "mixed state". ... Microsoft strongly recommends that you do not mix admin and client updates. ... When the installer accesses the admin point to try to obtain the ...
    (microsoft.public.officeupdate)
  • Re: Office Installation Not Syncing to AIP
    ... if you wouldn't mind verifing that these machines are in a mixed ... client machines or they have been installed directly on the clients. ... Microsoft strongly recommends that you do not mix admin and client updates. ... When the installer accesses the admin point to try to obtain the ...
    (microsoft.public.officeupdate)
  • Re: Office Installation Not Syncing to AIP
    ... client machines or they have been installed directly on the clients. ... This is a classic example of what we call a "mixed state". ... not update the source admin installation point with admin updates. ... When the installer accesses the admin point to try to obtain the ...
    (microsoft.public.officeupdate)